If automating you software deployment process is a ‘no-brainer’, why isn’t everyone doing it?

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:

  1. 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.
  2. 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.
  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 have been assembled to do and what they enjoy; creating great software.
  4. 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.
  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 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 – and yes, Deployment Manager is one of those – 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.

Note: This article was also posted on thefutureofdeployment.com. Check out that site for Continuous Delivery goodness and product updates for Red Gate’s automated deployment tool – Deployment Manager.

Create tangible retrospective actions

In my view, the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement.

It’s an idea that got me hugely excited and engaged in the subject when I first came across it in 2005. This essence of this is that ‘we will always know more about the project in the future than we do right now’. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding of the domain, technology, codebase, processes, practices and team.

In my head this is always represented with the following diagram. Where the blue dotted line indicates the original direction we thought was going to be right for the project (or codebase, or process, etc), the black dots represent reflection points, and the green lines represent the course corrections that were taken to improve things. At the end of the project, we ended up with a product or a way of working that we would never have envisaged at the start.

Inspect and adapt

Inspect and adapt

This is why I am such an advocate of having regular, frequent retrospective meetings throughout the course of a project, as they provide these important points of reflection and course correction. However, Retrospectives are only as valuable as the improvements they instigate. Sometimes, even though a team may have identified the right area of their project/process/codebase to improve, the corrective actions they decide on may fail to have a discernible effect. For example, a team may want to introduce a weekly customer support rota because the entire group is feeling impeded by the number of support requests being received.  This rota is drawn up and is respected for the first week, so things start to seem better. Beyond that first week though, there’s a good chance the rota will start to get forgotten and the problem will return.

Corrective actions that are destined to succeed often have a tangible effect on, or introduce a new artifact to, a team’s day-to-day life.  In my example, the support rota is much more likely to become entrenched if there is a visual token reminding people every day that it exists and is something they agreed to do. In my team we’ve done this by placing a big picture of an ogre on the desk of the person on rota duty.

The Support Princess

The Support Princess

When a support request comes in, there is no debate about who’s responsibility it is to ensure the request is handled.  More importantly, the fact that our ‘Support Princess’ token is so big and unappealing means that when a team member’s turn on the support rota is over, they are very quick to hand the duty onto the next person, and the rota cycle continues.

Plus, there is something strangely satisfying about placing a silly picture of an ogre on your colleagues desk.

Releasing your software shouldn’t feel like visiting the dentist [Part 2]

In my previous post, I explained how leaving an extended period between releases of your software is just as risky an approach as forgoing regular dental check-ups.

So if you bought that argument, it seems sensible to deploy pretty often, right? The problem is, and where the dental metaphor decays (sorry), is that software development teams feel that releasing is harder than visiting the dentist. Deployment processes can be a significant overhead, especially when compared with dialing a phone number and turning up at your local dental surgery. There are code reviews to undertake, test plans to execute, documentation to write, numerous environments to update and administrative tasks to complete. Development teams would be forgiven for dreading a deployment process that consumes days of their life and invariably raises difficult questions and forces uncomfortable decisions.

Really, releasing should be less onerous, easier, cheaper and quicker than going to the dentist.  In order to achieve this state, software development teams need to do three things:

  1. Automate their deployment mechanisms,
  2. Re-evaluate and streamline their administrative practices and processes,
  3. Explicitly focus on delivering valuable, incremental features to their users.

Doing all that at once can seem daunting, so the best thing that a software development team can do is to start to make things better ‘now’. Even if they can only automate a small part of their deployment mechanism at the moment, or cut out a small section of their release documentation, or decide not to test an underused area of the application. As they chip away at the overhead of deploying, the closer they’ll get to the benefits of regular user validation and risk mitigation outweighing the time and effort cost. Plus, once you start deploying often, everyone will start to focus on removing the remaining overhead.

Release CadenceWe’ve been making a concerted effort to apply an agile software development approach at Red Gate since mid-2008, but it was only 2012 that we explicitly challenged our development teams to release more frequently. In our efforts to meet this challenge we’ve made some mistakes and we deployed some releases that we shouldn’t have. However, we made incremental improvements, we removed or worked around bottlenecks in our deployment process and we added mechanisms that allowed us to spot problem releases.

It is worth mentioning that the single most important improvement we made was giving every team the power to release their software at the press of a button.  Red Gate’s excellent DevOps team delivered a bespoke automated deployment tool that allowed us to do this. It involved significant investment on Red Gate’s part but it was worth it, as it means that my team can deploy our product as often as they like. In effect, we are only limited by our ability to break work into discrete, valuable chunks and our users’ tolerance of software updates.

Software development teams should deploy as often as they can. Every month. Every sprint. Even every day, if your users would be happy with that. Reducing the gap between deployments reduces the amount of unproven changes that have not been validated by your users and lowers the risk of a single release having a plethora of pointy-fanged bugs ready to eat your time. Also, it means deployments will stop feeling like trips to sit in the dentist’s chair.

Note: This article was first posted on thefutureofdeployment.com

Releasing your software shouldn’t feel like visiting the dentist [Part 1]

As a project manager, the process of releasing software can be fraught with anxiety and dread. I can think about numerous times in my career where, in the shadow of an approaching release deadline, the thought of having to ship our application was akin to contemplating an imminent visit to the dentist. In fact, even the mechanism for getting our ‘awesome new features’ into the hands of our users felt like pulling teeth.

The Project Manager's Nightmare

The temptation is to release as infrequently as possible, just as the temptation is to visit the dentist as rarely as you can get away with it. You know you ought to go more regularly but you fear it’s going to be really painful. You may even have a haunting memory of a previous visit that ended up with your pearly whites on the receiving end of the dental drill. Personally, my teeth ache just thinking about it.

Instead of visiting the dentist regularly, maybe at six monthly intervals, you might find yourself making excuses and putting it off. As a result, you never get around to that check-up and only drag yourself into the dental surgery two years later, when you’ve got a cavity the size of the Grand Canyon. I know I’ve done this, fully aware of the risk that it might happen and have subsequently chastised myself when it does. Ironically, the resultant marathon stint in the dentist’s chair contributes to the haunting memories that compelled me to avoid check-ups in the first place.

In the software development world, leaving an extended period between releases of your software is just as risky an approach as forgoing regular dental check-ups. The bigger the gap between deployments, the larger the amount of work – code changes, database schema modifications, configuration alterations – that have not been validated by your customers. The greater the functionality and code delta between deployments, the more likely the new release has broken something serious, unleashing a horde of pointy-fanged bugs that are going to eat your time and leave your plan for the next development iteration in tatters.

Instead of worrying about the huge list of changes you’ve built up between releases, you can feel better by simply assuming that you got your decisions right. You can assume that you made a good call regarding which new features to add, how to design the user interface so it is ‘easy to use’ and whether the user is going to like it more when it’s drawn in mauve. However, you can only prove you got that stuff right by giving it to your users. The bigger the gap between releases, the more development effort you are gambling has gone ‘right’. When the release is finally out, your users are going to tell you if you got it right through sales figures, raised bugs, direct feedback and even social media. So, if you got that decision on drawing it in mauve wrong, that’s when the pain really starts.

Back in the dentist’s chair, the longer the gap between check-ups, the more food you’ve eaten between visits and the more unchecked bacteria builds up on your teeth.  You’re assuming that you are brushing your teeth right and that your reticence to floss has not impacted too much on your dental hygiene. However, if you got that wrong, that’s when things get painful.

The story continues in part 2…

Be deliberate: why this blog exists

Welcome to my blog.

My name is Chris, a agile project manager, development manager and agile coach based in Cambridge, United Kingdom. I work for a software company called Redgate – a purveyor of ingeniously simple software tools and services. My job is to lead agile software development teams; helping them to solve their own problems and do the best work of their lives.

Why have I decided that the internet needs yet another team leader-y type blogging self-importantly about how agile software development should be done? Well, I haven’t. The internet would probably cope without me. Probably.

Instead, I’ve decided that I’d like to clarify what I actually think about the processes, practices and skills I use in my role as a leader of agile software development teams. I hope that by analysing my thoughts and opinions, and then consolidating them into short articles, I’ll be a more insightful, consistent and effective leader.

Before I started this blog, I’d written a few posts for a blog sponsored by my employer and found that I really enjoy the writing process (although I make it a slower process than I’d like). The exercise also encourages me to decide what I think, rather than simply rely on instinct or past behaviour. Subsequently, I’ve found that I have been able to contribute much more insight in conversations I have had about the subjects on which I have blogged.

I try encourage myself and my team to be deliberate; to set out what we mean to do before (hopefully) doing it, rather than react to a given situation, opportunity or problem in whichever way took our fancy in that instant. In that spirit, and for my reference later, here’s what I want to achieve with this blog:

  • Decide what I think
  • Improve as a writer
  • Have fun

So… that’s why this blog exists.

What do I think?

What do I think?