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:
Release CI Pipeline.png

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!

 
0
Kudos
 
0
Kudos

Now read this

Thoughts on a Hackathon

So I took part in my first Hackathon at the weekend, I wasn’t sure what to expect but I thoroughly enjoyed it - enough to write down a few thoughts. The whole event started on Friday, where we were reintroduced to the challenges and have... Continue →