I’ve heard people say that the decision regarding whether to automate software deployments is a ‘no-brainer’; “Every software development team should have a fully automated deployment process”. It’s not even a debate. It’s a declaration.
It’s all well and good making that bold statement, but in actual fact there are only a relatively small percentage of software development teams who have a ‘one-click’, totally hands-off, fully automated deployment process. Many teams have a partially manual deployment process and many more have an entirely manual process.
Why?
So, if automating you software deployment process is a ‘no-brainer’, why isn’t everyone doing it?
My theory is that development teams are not doing it because they feel that the overhead of creating, setting-up, configuring and maintaining an automated deployment mechanism is not worth the potential short-term benefits. Often, teams can often only consider the short-term benefits of what they spend their time on. This is because of the pressures placed on them by the business and customers; deadlines are looming, bugs need to be fixed and features need to be delivered.
The overhead of setting-up automated deployment is perceived to steal time from developing the actual software these teams have been assembled to create. Perhaps it also drains energy from the developers who would rather be solving business problems and not “writing scripts to copy files across a network”. This 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 – “the deployment process has so many moving parts, how do I even begin to automate it?”
One way of starting to overcome this obstacle is being very clear on what the benefits of automated deployments are.
The benefits of automated deployments
So, here are my five reasons why you should always automate your deployments:
- Deployments are less error-prone and repeatable
Manual deployments are error prone. This is because it involves humans doing stuff, so is governed by Murphy’s Law. At some point, anything that can go wrong, will go wrong. Important steps in a release can be accidently 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 this 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 100th time. - Anyone in the team can deploy software
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.
With an automated deployment process, the knowledge of how to release your software is captured in the system, not in an individual’s brain. Anyone who has access to the “Deploy” button can initiate a release. - 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 have been assembled to do and what they enjoy; creating great software. - Deploying to somewhere new is not a headache
Automated deployments are not only repeatable, but they are configurable too. So although the underlying release process is permanent, the target environments and machines being released to can be changed.
What this means is 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 small. It is simply a case of configuring your existing set-up and relying on the tried and tested release automation to get the job done. - 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 as big as you fear.
You do not need to write your own automated deployment systems. You don’t need to pay for a team of consultants to come into your business, agree some requirements and deliver a behemoth system designed to get your product out the door.
There are a number of good automated software deployment tools out there, like Octopus Deploy, that can be tailored to your needs, 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.
Leading Agile Teams 
Leave a Reply