Deployment Automation

Alex Knight

OK, multiple days in a row about the same book “Accelerate: Building and Scaling High Performing Technology Organizations“. So far my personal challenge is working out … but this is day 2 of 24 so I will control my self-congratulations until later.

Today’s topic? Deployment Automation.

You might think that this is a no-brainer, that deployment automation has to improve the quality of an application.  But that’s not always the case.

It’s not enough to automate deployments, you need to understand what you are automating and why you are automating it.  If you have a poor process for deploying code then automating that isn’t going to help you much.  Oh, it will help you, make no mistake.  Finding out that you have a problem with the deployment in 30 seconds is always better than 30 minutes.

But you still have a problem.

If every application you build, every service you write, requires a customized deployment process then you have a bigger problem than just automation.  Developers/architects have spent too much time on trying to be different than they spent on determining if they are different.

I was watching a video last year (darned if I can find it now) about how Amazon does automated deployments.  They essentially have seven patterns.  Seven uniquely different ways that an application / service can be deployed.  Amazon is a fairly complex entity, probably more complex than the applications that you and your team support.  You don’t need a customized deployment for every application, you need to standardize your deployments.

Why do you want to standardize?

Here’s the interesting part:  automating the automation.  If you have standard processes, standard methodologies for deploying applications and services, you can then automate the creation of the workflow for that piece of code.  If you improve the process you can re-create the workflow merely by regenerating it and then everyone can take advantage of the improvements.

Deployment automation extends not only to the individual piece of code, but the piece of code that deploys that piece of code.  Kind of like a Mandelbrot set.  The more you automate the more you can automate.

By automating deployments you

  • reduce the number of errors when compared to a manual deployment
  • are more likely to have standardized deployment processes
  • increase the frequency of deployments allowing for “Continuous Delivery”
  • minimize the effort needed to deploy a release so that it becomes inconsequential to release

Check-in the latest changes?  Deploy to development.  It’s as simple as that.

About five years ago I made the push for automated deployments.  Many people were reluctant to embrace the idea, but I pushed.  At that time my team did 5000 manual deployments per year.  In the past 12 months we’ve done 4000 manual deployments and over 27,000 automated deployments.  That’s going from 20 changes per day to over 120 changes per day.  And the rate of automated deployments is increasing rapidly with a 70% year-over-year increase in automated deployments.

70%.

And we’re not even close to being done with the automating.  The fact that almost every study out there shows that with an increased deployment rate the quality goes up emphasizes the point that automating deployments is a good thing.  If you want to be a high performing organization you must implement automated deployments.  It’s as simple as that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.