Deployment Process

Release to staging

1. Ensure that your work has been pushed to GitHub.

2. On your local machine, check out the branch that you wish to deploy.

3. By default, the develop branch is deployed to staging (regardless of which branch you’ve checked out locally). If you wish to deploy a different branch, you will need to edit your local copy of conf/pillar/staging.sls to use a different branch name.

4. Run the deploy:

   fab staging deploy
   

Reset staging environment

These steps will restore the production database and code states to the staging environment.

1. Copy the production database to staging:

   fab prod_db_to_staging
   

2. On your local machine, check out the master branch:

   git checkout master
   

3. Edit your local copy of conf/pillar/staging.sls to specify the master branch for deployment.

4. Deploy the master branch to staging:

   fab staging deploy
   

5. Undo the change to conf/pillar/staging.sls.

Release to production

1. Before merging changes to master, the complete deployment process should be tested on staging.

   • Restore production data, media, and code to the staging machine.

   • Check out the develop branch locally and deploy it to staging:

     fab staging deploy
     

     NOTE: If you are deploying a hotfix branch, you will need to edit your local copy of conf/pillar/staging.sls accordingly.

   • Confirm that changes are behaving as expected, and troubleshoot the deploy process until you are confident.

2. Finalize the release number.

   • Update the version number according to semantic versioning, and change the version state to "final". Version must be updated in tracpro/__init__.py and docs/source/conf.py.

     • The micro version is incremented with backwards-compatible bugfixes.
     • The minor version is incremented with backwards-compatible features.
     • The major version is incremented with incompatible changes.

   • Update the release notes (including notes about one-off deployment requirements, if needed) and add the current date as the release date.

   • Commit these changes and push to GitHub.

3. Merge all changes to the master branch, ensure that these changes are pushed to GitHub, and confirm that the Travis build has passed.

4. Check out the updated master branch locally, and create a release tag:

   git tag -a vX.Y.Z -m "Released YYYY-MM-DD" && git push origin --tags
   

5. Copy the release notes to the GitHub releases interface.

6. Run the production deploy:

   fab production deploy
   

7. Merge the master branch into develop:

   git checkout develop
   git merge origin/master
   git push origin develop
   

8. On the develop branch, increment the micro version and change the code state to "dev". Commit these changes and push to GitHub.

9. Run ReadTheDocs builds for the new release & the latest develop.