Skip to content

Branching and Deployment

Edward Hibbert edited this page Feb 22, 2021 · 15 revisions

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 REP-1234, following by an underscore, following by short text reasonably indicative of which issue it relates to, in plain English.
    • e.g. REP-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

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

This assumes you've already done something like:

git remote add live ssh://restarters/var/repo/repairdirectory.git

git checkout production
git merge master
cp fixometer/config/config.dist.php fixometer/config/config.php
composer install --no-dev
npm install
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/repairdirectory/
php artisan doctrine:migrations:migrate # type 'yes' when prompted
  • translations

There is no internationalisation of the Repair Directory Admin, so there's nothing to do.

Smoke test

Check that these pages load:

On map.restarters.net:

  • Check you can do a location/category search
  • Check you can log in to the admin section

Tidying up

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

git checkout develop
git merge master
Clone this wiki locally