Production Deployment

Create a Release Tag

The develop stack should be kept in sync with the develop branch. Make sure the current develop stack is validated. Once the develop stack is validated, tag the current commit on the develop branch as a release candidate:

1. Go to a local repository dedicated to releases. This repository should be a separate repository that does not have ongoing work. It should lag behind upstream and should be up-to-date only with the previous release.
2. Make sure the local branch checked out is develop.
3. Sync with the remote git pull upstream develop. (Note upstream here is the team repository.)
4. Tag the commit, git tag <your-release-tag> [commit].
   • If not released right away, should use annotated tag, for example, git tag -a release-20140715 -m "Fully tested; no issues.".
   • To be safe, run git log to lists the commits and git tag <your-release-tag> <commit> to tag only the commit that's validated on the develop stack.
5. Push the tag git push upstream <your-release-tag>. Note no code changes, we can push directly to upstream.

Now that a release candidate has been tagged, it could be released at a later time.

Release Forward by Merging a Release Tag

A decision should have been made about which release tag to release. Now merge the release tag to the prod branch:

1. Go to the same local repository dedicated to releases.
2. Make sure the local branch checked out is prod, not develop.
3. Sync with upstream prod git pull upstream prod.
4. Fetch a specific release tag, for example, git fetch upstream tag release-20140715.
5. Merge up to the release tag, for example, git merge --ff-only release-20140715.
6. Push the tag to prod git push upstream prod --tags.

The last command should trigger a Travis build and a subsequent deploy to the prod stack.

Rollback

Look at the Travis build history. Find the previous successful build on the prod branch. Restart the Travis build should rebuild and redeploy the previous release and we are done. The steps below can be skipped.

If roll back to a unreleased commit (not recommended):

1. Tag it first:

   1. git log lists the commits
   2. git tag <tag> <commit> tags the commit to roll back to
   3. git push upstream <tag>

2. Fork a temporary rollback branch at the rollback point, git checkout -b <rollback-branch-name> <previous-release-tag>, for example, git checkout -b rollback-20140718 release-20140718.

3. Edit the .travis.yml file to point the new rollback branch to the prod stack:

   ...
   app:
     develop: bridge-develop
     rollback-branch: bridge-prod
   

4. Push the branch to upstream git push upstream <rollback-branch>.

5. When the rollback branch is not deployed any more, it can be safely removed git push upstream :<rollback-branch>. We keep only two branches longterm wise: develop and prod.

6. Alternatively, rollback may be done by resetting the prod branch to a previous release and do a forced push to upstream. But we'd like to keep the prod branch always moving forward.

Patch

1. Do the patch work on the branch that is currently deployed to the prod stack. This usually is the prod branch but could also be a rollback branch.
2. Merge back to the develop branch and do a push to test the patch on the develop stack.
3. Push the change to the deployed branch to deploy the patch.