Find My Team

How We Deploy At TeamSnap

Image of engineering blog author: Rand GirardRand Girard

Deploying code is traditionally an annoying process in any company. At TeamSnap, we have made several strides to streamline this process and remove unnecessary hurdles. Removing these obstacles not only improves how often we can deploy and how quickly, but decreases the time a developer is involved in the deployment, increasing productivity and overall happiness.

There have been many improvements to this process over the last year and a half. First we automated away most of the tedious tasks involved in deploying code, such as asset compilation and database migrations. Then we improved the time in which it took for our test suites to run, effectively allowing us to deploy more often and more quickly. Next we completely changed the way in which the deployments actually happen, significantly speeding them up in most cases.. We are now onto the next improvement that should decrease deployment/wait time even further!

Here are the steps to deploying at TeamSnap:

  1. Submit pull request and get code review.

  2. Get thumbsup on this and rebase branch to ensure it's up-to-date and mergeable.

  3. Branch will be built and tested on the CI server. Once green, deploy your branch:

  4. Jarvis, our internal #chatops bot, will respond once your deployment is complete:

  5. Verify the update on the server. Check error logs, metrics, etc. If there are no issues, you can then deploy master by merging and deploying:

  6. Jarvis will respond again with the result. Unlocking the environment for the next developer to deploy:

  7. If you attempt to deploy while another developer has the environment locked, Jarvis will let you know:

This may look like a lot of work, but in reality, its going to increase how often and how quickly we can deploy by removing the bottleneck of retesting the production branches after every merge, since these were just tested after a rebase of the branch on top of production.

We can also avoid the nasty commit history involved with multiple reverts of reverts that happen if we are engaged in a branch deployment. Master is assumed to be stable and so we just redeploy it.

Thank you!

  • Randy