Deploying to the live site

written by @zofrex



Deployment to the live sites is controlled via branches:

  • deploy-phm for publichappinessmovement
  • deploy-btm for brightertomorrowmap

Travis will watch those branches for changes and automatically deploy if they are updated.

Promoting a change to production

If for example you want to deploy what’s on the current master branch to publichappinessmovement, you would do:

$ git branch -f deploy-phm master
$ git push origin deploy-phm

This updates deploy-phm to point at the same commit master is pointed at, and then pushes the update to deploy-phm to Github. (This is no different to doing a fast-forward merge on that branch, but commit -f saves you the extra step of checking the branch out.)

You can also deploy any other commit either by passing in the commit hash or the name of a branch pointing at it:

$ git branch -f deploy-phm 2f87a4b3
$ git push origin deploy-phm
$ git branch -f deploy-phm some-testing-branch
$ git push origin deploy-phm

If the update is not a fast-forward from the deploy branch’s previous state, you will need to force push.

Adding / changing production environments

Deployment configurations for each website/environment are contained in subdirectories here, e.g. ./brightertomorrowmap/.

The mapping of branch name to directory is handled by and you can change mappings by changing that file.

To add a new website, create a new subdirectory, put its deployment configurations in it, and add the mapping from your desired deployment branch name to You will also need to add the branch to the list in .travis.yml to make Travis deploy from it.

How does this fit in with the Development branch/server you’re building @zofrex?

Should devs make a PR to both branches for now (unless its a change in the i18n folder)?

Making PRs to both branches is the system we moved away from as one inevitably gets missed out and falls behind. The third development branch you talked about would be good as then any changes missed could be pushed later and wouldn’t create any conflicts as the rest of the code would be identical.

I would recommend merging all PRs to master, unless you have some reason (emergency fix?) to promote commits directly to a production server without first deploying them to the testing server.

When you want to deploy changes that have reached master you can use the git branch -f commands as above to update one or both deployment branches, either to the latest master, or any “known good” commit you want to promote.

I would recommend only ever pointing the deploy branches either at the master branch’s HEAD, or at a commit that is in the master branch’s history, to avoid creating a confusing situation or ending up back in the situation where you have a different branch for each website.

If you do ever commit something directly to a deployment branch (e.g. for an emergency hotfix) I would recommend merging that deployment branch into the master branch afterwards to bring everything together again.

cool. so Master branch is fixed and should be the main one now?

we’ve had a few PRs into the live branches today as i didn’t think Master was ready to be used

Update on Deployment:


Testing Server → Master → Live Sites
(sandbox) → (staging area) → (individual site branches)

When a change is stable it moves to the Master branch. After checks by original author and review/approval from level 3 or 4 team members, changes are immediately pushed to live sites.

Testing Server

  • to be created

Staging Server

Live deployment needs to be created

Master Branch




Projects with teams waiting to join our eco-system:

Site 3 (codename eco)

  • Needs to be setup

Site 4 (codename wigg)

  • Needs to be setup

Site 5 (codename jobs)

  • Needs to be setup

Site 6 (codename dogf)

  • Needs to be setup