Skip to content
This repository has been archived by the owner on Sep 6, 2023. It is now read-only.

Production Deployment

Eric Wu edited this page Mar 27, 2015 · 12 revisions

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 locally that does not have ongoing work. It should lag behind upstream and should be up-to-date only with the previous release. As the release process does not need the developer fork, the local repository can be cloned directly from the Sage-Bionetworks remote repository git clone https://github.com/Sage-Bionetworks/BridgePF.git release.
  2. Make sure the local branch checked out is develop.
  3. Sync with the remote git pull origin develop. (Note origin here is the Sage-Bionetworks remot repository.)
  4. Tag the commit, git tag <your-release-tag> [commit]. Again, make sure you are on the develop branch.
    • 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 origin <your-release-tag>. Note as there is no code changes, we push directly to origin, which for the release is the Sage Bionetworks remote repository.

Now that a release candidate has been tagged, it is ready to be pushed to the next stage.

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 origin prod git pull origin prod.
  4. Fetch a specific release tag, for example, git fetch origin 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 origin prod --tags.

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

Rollback

There are a couple of ways to roll back. The easiest is via Heroku. Go to the Heroku website. On the Heroku dashboard for the app, click the Activity tab to see the list of activities. Each deployment activity has a commit id and a button "Roll back". Click the commit id to compare the deployed commit with the previously deployed commit. Click the rollback button to roll back to this deployment activity.

Alternatively, can use the Travis build history to roll back. Find the previous successful build on the prod branch. Restart the Travis build should rebuild and redeploy the previous release and we are done.

If roll back to a unreleased commit (not recommended), do the following:

  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. So this is discouraged.

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.