Going fast & keeping track of releases  

It’s important in our world to release as often as possible to production. This means we get to move quickly, try new things, and then get results for the business quickly.

One of the issues with moving quickly can be that, with increased automation, there can be more reliance on tools and it’s easy to forget to approve a production deployment.

We use a pipeline that looks something like this:

We’re doing Continuous Integration and Delivery, but not quite Continuous Deployment. We continuously deploy to our lower environments, but not production quite yet. As you might expect, our master branch is deployed to our development and pre-production environment automatically, but can sometimes get stuck at the manual approval step.

In order to check where we’re at, I’ve written and Open Sourced a quick script that will check how far behind production is on each repository. Take a look here: https://github.com/florx/github-check-prod-releases

On my current project we follow a fairly strict, “if it’s on master - it should be in production, unless there’s a problem” rule. Coupled with tagging our repositories when we release to any given environment - this allows us to check easily the status of any given repository.

If the master branch on any repo is behind production by even 1 commit, then we should look to release it. We also do squash merges, so also we know that each commit is 1 pull request of content.

Good luck!