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:
- Automate their deployment mechanisms,
- Re-evaluate and streamline their administrative practices and processes,
- 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.
We’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.
Leading Agile Teams 
Leave a Reply