46 Releases in February

a continuous delivery example

My team at Emsi has been improving its testing and release process for a couple of years, and the return on that investment is becoming clear: in February, we deployed to production 46 separate times — on average, more than twice a day (February is a short month).

I know that pales in comparison to some dev shops, but it's exciting for us:

Screen Shot 2021-05-25 at 12.28.42 PM.png

The chart looks like an example of compounding interest, and the experience has been similar. I wouldn't expect this growth to continue forever — a team of 10 can only deploy so often, after all — but we'll ride the wave as far as we can.

How did that happen?

During the Summer of 2015, we began building out an automated test system that has grown to cover most core functionality. It can finish a full run in about 20 minutes. Doing that much testing by hand would take more than two days for one developer, but now we have the same test coverage on every code change we make — and we make quite a few. If you're interested in continuous integration, ThoughWorks has produced some great content on the subject.

The real power of continuous integration (integrating and testing every code change you make) is unlocked when combined with continuous delivery (the ability to deploy those changes with the push of a button). It's only within the last few months that we've automated our deployment process and given any team member the ability to execute the process.

Why does it matter?

  1. More output. Regular product updates, however small, build trust with customers. And, with much of our busy work automated, we spend more time building cool new things.
  2. More valuable output. When coupled with a sprint cycle, continuous delivery gives us the ability to change direction quickly. Because our releases don't need to be planned weeks in advance, we can work on today's top priorities, not last quarter's.
  3. Mistakes are easier to fix. Now that deployment isn't a momentous ordeal, we routinely fix bugs hours after they are introduced instead of weeks.
  4. Reduces knowledge silos. When a critical team member goes on vacation, output doesn't grind to a halt. By handing the keys to all team members, we will continue to function even if our most senior team members get hit by a bus.

I'll be following up on this post with more details about our CI/CD work and the benefits we see — once I'm done celebrating this milestone.