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, new features from a staging environment. Essentially we have succeeded in making Development and Testing of new features fit well within an iteration through continuous testing in smaller batches and relying on good deal of automation too, units 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 teams 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 it’s own confusions and late night works because we had picked up a story and then came release support in staging (as always unexpected) so we had the leavthe story half way 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 what they were, my earlier blog posts of DBCI or release when ready where when we were embarking on that journey. Half a year later we had 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, also 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 make it a well oiled machine led us to Jez Humble talking about Continuous Delivery.
And we got intrigued, the idea is that releases should be a non event, which means 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 click of a button perhaps.
This is a revolutionary concept none-the less as it bring 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 adapters 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 delivery 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.
It’s all too early for us to say how well this will work or how far we can go for that matter, but it is indeed reassuring to know there are others trying to solve same problems as we are; and teams are willing to do away with Release Management processes which do not really work well with Agile Development.