Chris Smith

26 March 2015

1 Comment

The 5 big benefits of automated deployment

“Every software development team should have a fully automated deployment process.” That’s according to pretty much everyone I meet at conferences and events.

It’s not even a debate. It’s a declaration.

In actual fact there are only a small number of software development teams who have a ‘one-click’, totally hands-off approach. In Redgate’s latest State of Database DevOps Report, for example, only 16% of respondents reported they had a fully automated process in place. For everyone else, it’s either a partially manual deployment process or an entirely manual process.

Why aren’t you doing it?

If automating software deployment process is such a ‘no-brainer’, why aren’t more people doing it? My theory is that development teams are not doing it because they perceive the overhead of creating, setting-up, configuring and maintaining an automated deployment mechanism to not be worth the potential short-term benefits…

“Setting-up automated deployment will take forever! It’ll steal time from developing the actual software my team has been assembled to create!”

“Our deployment process has so many moving parts, how do I even begin to automate it?”

“It’ll just drain energy from our developers – who would rather be solving business problems and not writing scripts to copy files across a network.”

You’ve probably heard colleagues (or yourself) say something along these lines. This perceived overhead can become quite a sinister obstacle. It may seem so large and insurmountable, that the development team don’t really know where to start when tackling it.

One way of overcoming this is being very clear on what the benefits of doing so are. So, without further ado, here are the 5 big benefits of deployment automation that we’ve seen in our team since automating our processes.

The 5 Big Benefits

#1: Deployments become much less error-prone and much more repeatable

Manual deployments are error prone. This is because it involves humans doing stuff, so is governed by Murphy’s Law: if anything can go wrong, it will go wrong. Important steps in a release can be accidentally missed, faults that occur during release may not be spotted, the incorrect versions of software can be shipped and broken software ends up going live. If you are lucky, you’ll be able to recover from this quickly. If you are unlucky, well… it’s pretty embarrassing at best.

Automated deployments don’t suffer from variability. Once configured, the process is set, and will be the same every time a release is initiated. If it works the first time you deploy your software into a given environment, it’ll work the 100^th time.

#2: Anyone in the team can deploy software

With an automated deployment process, the knowledge of how to release your software is captured in the system, not in an individual’s brain.

Performing manual or partially-automated deployments are often the responsibility of a small subset of people in an organisation. In fact, it’s not uncommon for this duty to fall to a single person in given project team. If that person is off ill or otherwise unavailable at short notice, releasing can become a nightmare. Now, anyone who has access to the “Deploy” button can initiate a release.

#3: Engineers spend their time developing software

Performing and validating a manual deployment process is often a time-consuming, thankless task. This job can fall to developers and testers in a development team who would otherwise be spending their time producing the next set of awesome features and improvements to the software.

The time taken to initiate a fully automated deployment is counted in seconds. Validation of those deployments happens behind the scenes and team members may only need to spend further time on a deployment if something has actually gone wrong. As a result, the team get to spend more time doing what they enjoy and have been assembled to do; create great software.

#4: Deploying to somewhere new is not a headache

Automated deployments are not only repeatable, but they are configurable too. Although the underlying release process is permanent, the target environments and machines can be changed easily.

This means that if software needs to be deployed to a new test environment or if a new client installation needs to be created, the overhead of deploying to that additional target is negligible. It is simply a case of configuring your existing set-up and relying on your tried and tested release automation to get the job done.

#5: You can release more frequently

A single deployment performed by an automated deployment mechanism has a low overhead. A release process with a low overhead is one that can be repeated frequently. As I’ve discussed on this blog in the past, frequent releases are desirable for many reasons, but the crux of the matter is that frequent releases promote truly agile software development.

Teams that release frequently can deliver valuable features to their users more often and in incremental steps. In doing so they can gather continuous feedback from these users on the software they are creating and adapt their approach as a result. This feedback can be the difference between a product delighting its target audience or missing them completely.

Debunking the overhead myth

These benefits sound pretty desirable, but remember that sinister set-up overhead that is discouraging many teams from automating deployments? That overhead is really just time. More accurately, it is your estimation of the amount of time required to create an automated deployment mechanism.

The good news is that this overhead isn’t anywhere as big as you fear. There are a number of good automated software deployment tools out there that can be tailored to your needs fairly quickly – for instance, I’d give Octopus Deploy a go if you’ve never tried it as it’s pretty awesome. Octopus Deploy and other release management tools also integrate with Redgate ReadyRoll to help you automate database deployments to pre-production and production. These kind of tools can be integrated into your existing infrastructure and will reduce the overhead of setting up an automated deployment process to an hour or two. Leaving your team with a ‘one-click’, totally hands-off, fully automated deployment process that is, apparently, a no-brainer.