Branching and Deployment

This repository is for the Repair Directory server and admin section. There is a separate repository here for the public facing client. These are typically deployed in parallel.

We are currently using a Git Feature Branch Workflow that is almost but not quite Git Flow. We will most likely move to Git Flow proper, for consistency, and we want to make better use of releases and git-flow covers this.

master is always kept in a state that is ready for merging to production and pushing live.

Development

Features and non-urgent bugs

Features and bug fixes are worked on on branches, and submitted via pull requests.

Internal

If you have write access to the repo.

• Developer creates a branch off of the develop branch.
• Naming
  • begins with the name of the story in Jira, e.g RP-1234, following by an underscore, following by short text reasonably indicative of which issue it relates to, in plain English.
  • e.g. RP-1346_safari-timepicker
• Can push the branch to restarters.dev, and check out to that branch for someone to feature test
• Regularly (e.g. daily) merge develop in to the feature branch
• Once first round of dev is complete, a pull request is created against develop from the feature branch
  • Code review discussion takes place on the PR.
  • Review requested from relevant other dev
• When code review complete, merged in to the develop branch

External

• via fork and pull request - see Forking Workflow.

Urgent bugs

We use hotfix branches off of master for this.

• when done, merged into master and develop
• and push to production too, if critical

Releases/Deployment

The code on the live server is deployed by pushing to a "live" repo which lives on the live server under /var/repo/repairdirectory.git. You'll need to have set that up as a remote if you're doing this for the first time.

Preparing the release

• changes completed and signed off in develop go into a release branch for the sprint
  • named release/X.X.X
  • this is created just before the end of the sprint, e.g. end of Monday before sprint finishes
  • only bug fixes and things related to release management done on this branch

git checkout develop
git pull
git checkout -b release/X.X.X
git push --set-upstream origin release/X.X.X

• when release/X.X.X branch is ready, merge it in to master
  • tag it with with the version number
  • then delete the release/X.X.X branch
  • master merged in to develop (to pick up any changes that were made only on the release branch)

git checkout master
git merge release/X.X.X
git tag -a vX.X.X -m "Tagging vX.X.X"
git push origin vX.X.X
git push origin master

Pushing to production

From local machine

git checkout production
git merge master
npm run prod
git add public resources 
# Note: next step may fail with 'nothing to commit, working tree clean' if npm run prod didn't produce any changes
git commit -m "Build assets" 
git push origin production
git push live production

On server

• run migrations

cd /srv/users/serverpilot/apps/restarters/
php artisan migrate # type 'yes' when prompted

• translations

Import newly added translations to the translation manager:

php artisan translations:import

Smoke test

Check top level sections look OK. (i.e. click through Fixometer, Events, Groups sections), and anything relevant to the specific release that might need an extra look at.

Tidying up

Make sure develop has latest changes from master for our new sprint:

git checkout develop
git merge master

• although git flow doesn't say anything about pushing to production, it would appear as if deployments are from from master

  • production exists because it is currently the only place where we check in changes to the built assets (e.g. via npm build / composer installs)
  • ideally we remove production, but only after we have entirely removed built assets from the source tree

• production branch is pushed to live environment via a git push to the live remote. See Server & Deployment details for more info.