1089555 - Use git branches for stage/prod deployment, rather than master

Status: RESOLVED FIXED

(Tree Management :: Treeherder: Infrastructure, defect, P2)

Description

[Ed Morley [:emorley]]

Currently, when deploying to prod (and presumably also the case for stage, once bug 1064438 is complete) we tell Chief to pull HEAD of the master branch of both the treeherder-ui and treeherder-service repos.

Whilst this is simple, it has a few issues:
1) There is no way to specify a revision other than HEAD, given that passing a SHA value to Chief wouldn't work, since the same value is used for both repos, and the commit wouldn't exist in both. ie: we can't deploy the service repo and the ui repo separately.
2) There is no way to fast-track a hotfix needed for prod, when dev is currently not in a fit state to deploy.
3) It's hard to keep track of what changes are deployed, when only looking at the repo. You can look at https://treeherder.mozilla.org/media/revision, however that only lists the treeeherder-service revision and not treeherder-ui.

Proposal:
1) Create a new branch, perhaps named "production".
2) treeherder-dev continues to track master, stage and prod use the new "production" branch.
3) When we wish to deploy changes, we merge the desired commit on master (typically HEAD, but we can use an earlier commit if needed) to the "production" branch, for both ui and service repos. We then perform a Chief deploy as before.
4) We can then fasttrack fixes by cherrypicking them from master to production (or landing directly on production and merging back the other way).
5) We can easily see what changes are deployed by looking at the production branch.
6) As a bonus, in the future, perhaps we can set stage to automatically update from the production branch every N mins, similar to what we need to do for dev (bug 1047385).

TBD: At what point do we run the grunt build? If we're going to deploy HEAD of master, then I guess we grunt build on master, but if we're cherrypicking, I guess we have to grunt build on the production branch.

Comment 1

[Ed Morley [:emorley]]

Having to merge to a production branch might also remind us to perform the grunt build.

We can also script the merging to make the added workflow complexity less noticeable.

Comment 2

[Mauro Doglio [:mdoglio]]

For the UI I suggest we keep a production branch to do the cherrypicking and a production-dist that only contains the dist directory. Production-dist will be the only branch actually deployed. 
In this way we can keep the git history on master and prod completely independent from the build history. 
We can write a grunt task to help us with this workflow, or use a grunt plugin like https://www.npmjs.org/package/grunt-gh-pages. Of course the same applies to stage/stage-dist

Comment 3

[Ed Morley [:emorley]]

Note: Much of my comment 0 needs updating, since it was written when we had the UI repo + also had dev.