We’ve been working hard to make releases as smooth as the iterations and be able to reach production even sooner than the once-in-a-month releases we do. Our releases usually occur once the board of stakeholders has given a Go for a release, in a Go-NoGo meeting where we report the status of regression, performance, and new features from a staging environment.

Essentially we have succeeded in making the Development and Testing of new features fit well within an iteration through continuous testing in smaller batches and relying on a good deal of automation too, unit tests and system tests that run through Maven Builds, and automated functional tests that run through selenium plus some of our own homegrown tools for other testing purposes such as performance.

Having said that we still had releases running in a waterfall-phased (albeit small) manner, for example, we perform UAT on a dedicated UAT environment where we release once in 2 weeks. Also, every alternate sprint development team are expected to keep a buffer for release support which if left unused can be picked up for adding stories if needed. And that’s a big If, to know exactly when to pick up a user story because you won’t be possibly needed for release support, it has contributed its own confusion and late night work because we had picked up a story and then came release support in staging (as always unexpected) so we had left the story halfway and work on the support, but since we have added it into a sprint we cannot leave it unfinished. Phew!

So we set on the journey to make this UAT and Staging release activities more “Continuous” than they were, my earlier blog posts of DBCI or release when ready were when we were embarking on that journey. Half a year later we had a good deal of automation in place; E2E tests, system tests whatever you want to call them, continuous performance tests and an automation suite for functional or new features, and homegrown tools to automate Non-functional requirements and make them a part of these continuous in small batch cycles. So the jigsaw was falling in place and our search of how to make it a well-oiled machine led us to Jez Humble talking about Continuous Delivery.

We got intrigued, the idea is that releases should be a non-event, which means the bulk of the effort that goes into moving an application from “the newer things work” to “it works well enough to release” should happen in an industrialised small batches manner which would make things as easy as a click of a button perhaps.

This is a revolutionary concept nonetheless as it brings the concept of small batches in continuous iteration to release management as well. So If I put it in simpler terms, we’re moving everything (UAT, performance testing and Regression) from phases to continuous cycles and as much as possible do it within a sprint. Some of the early adopters have seen benefits already in terms of man-hour efforts in release management, deployment duration and success rates themselves.

There are more interesting concepts over there, it’s not just about release automation, we also look at how we develop and deliver features. The idea is to concentrate on the fact the only worthwhile thing to deliver in a software project is working features, and then design systems which can support this high-paced modular delivery of the features In cases where you can’t just put all of it in one go we could use feature toggles, something our team here has used to great effect already.

Originally published at anadimisra.com on December 10, 2010.