For many organizations these days, Continuous Delivery is an important process. The ability to ship functionality to end-users as quickly as possible is a noble goal, but for enterprises that currently ship new versions of their software monthly, quarterly, or even annually, continuous delivery can seem like an impossible task. I once thought the same way. “Frequent releases?! Here?! That’ll never happen.” But I quickly learned that by taking baby steps towards continuous delivery, an organization can quickly reap the benefits of frequent, low risk, higher quality software releases.
At first, frequent releases can seem counterintuitive, especially for an operations team. In many organizations, a release of a new version of an application can be a terrifying event from the deployment process itself to the first time a user starts the new version of the application. The operations group is holding its breath, standing by for a rollback; the developers are staying late, hovering about in case something blows up. Why would anyone want to go through all that stress MORE frequently?
But stop and think about it: why are those releases are so terrifying? Typically it always boils down to the amount of time since the last release. More time between releases means:
- More changes happened to the software
- A larger testing surface area was created (and more than likely not exercised thoroughly)
- The rollout/rollback process itself is likely to be cumbersome
- And thus, the risk of a failed software release goes up
Therefore it only makes sense to REDUCE the amount of time between releases. By reducing the amount of time between releases you limit the number of and scope of software changes, which shrinks the testing surface area and can simplify the rollback process, and in the end makes the entire release process a much lower risk event.
But as they say, “you have to crawl before you walk”. We accomplished this in a two pronged approach:
- The development team and the operations team talked to each other and the development group listened to the needs of operations from a deployment perspective. This was treated just like a normal requirements gathering/design/implementation exercise, just like a typical end-user requested feature.
- The operations team also looked at how to streamline their own procedures through judicious application of automation and improved communication.
The goal for both teams was to push towards a consistent deployment process first, and automation second.
Next, we bucketed applications into related groups, i.e. applications that made sense to release together. We called these buckets “trains”, and we scheduled the trains for once a week deployments. Developers had to get their changes committed to source control at least 2 business days prior to a train’s scheduled release, or those changes would have to wait for the next week’s train. Of course the operations team was flexible for bug fixes, emergencies, etc. but all feature development followed the train schedule.
Then, we actually tried it. And of course, as with most new procedures, the first few runs were miserable and difficult. But since we had buy in from all involved in IT management, we kept trying it and kept improving the process iteratively, just like typical software feature development. And after a few cycles of each deployment train, we got into a rhythm: developers, operations, and the Devopelers in between knew exactly what to do and what to expect. Soon, we were deploying a few dozen Windows services and desktop applications in hundreds of instances across hundreds of servers and workstations every week. And neither the development team nor the operations team broke a sweat.
While we never quite reached a truly continuous deployment process during my time at that organization, our weekly release process was light years ahead of our old infrequent release schedules. Software deployments became mundane and routine instead of infrequent and terrifying.
So if you’re thinking ways to reduce the risks and problems with your current software release process, just start taking baby steps towards continuous deployments and your organization will quickly reap the rewards.
