De-coupling releases from deploymentJul 11th, 2015 | By raja shankar kolluru | Category: Featured, management, organization design, process, technology
IT industry is all about change. Functionality needs to constantly evolve. You need more content, more products, more promotions and what not. In fact, a static web site is not very interesting in the eyes of its users. It gives the impression that the founders have gone fishing and have left the users to their own devices.
Hence software releases are a part and parcel of the lives of all folks involved with IT. In most enterprises, releases are mega affairs. They need planning and a non trivial amount of co-ordination between multiple groups. All teams need to deploy their latest code. The QA folks need to line up their test cases. The operations folks need to be ready. Business users need to get ready to change their ways of working. The product owners must polish their trumpets to blow them for the great show. Once the ducks get lined up, the grand spectacle unfolds. Is this going to be a show of triumph or a debacle? Lots of bated breaths. Finally, the whole spectacle ends. The fever passes and lives return to a semblance of normalcy. People get to relax. Until the next release!
This whole charade recurs at periodic intervals much to the dread of all the participants. For anyone who has been in any kind of enterprise, all this will sound very familiar.
The release planning process is itself quite complicated. Typically, multiple features get planned to be released at the same time. All software systems that need to change to implement the features then get identified. The teams are asked to plan their deployment to coincide on the grand day. Testing needs to be planned accordingly. People accept this as part of their lives.
But does it have to be this hard? Why are software releases such a nightmare?
The answer is simple. Releases are hard because they have been used as instruments for not only enterprise change but also IT change. This approach combines too many responsibilities and hence increases the number of potential sources of failure. A release can fail if any of the software systems that it touches fails to change gracefully.Or, if the business is not ready. Or, if the QA is not ready to test the changes. etc. etc. All for the want of a horseshoe nail!
The solution to the problem must be to simplify. This can only be done by rethinking the way we do releases. Releases must not be viewed as conduits of IT change. Which begs the question – What is IT change? IT Change is inextricably linked to deploying new versions of the software. So to simplify releases, we need to de-link the two.
Model for a Software Release
The model for a typical software release is shown below:
Look at 15.1,15.2 etc. which represent Enterprise Releases. The features F2,F1,F4 and F3 respectively are being released in these timelines. All systems that need to be changed (system 1, system 2 etc.) need to ensure that these features are made ready during the exact day of the release. Quite clearly, this is a formidable proposition.
Instead, consider an alternative model which is shown below.
In this model, the release timeline is completely skewed. Each product has its own timeline to implement features. Some features can even be combined into one deployment. (e.g. System 3 implemented features F2 and F3 into one deployment). Some other features can be delivered out of sequence. For example system 1 delivered the orange feature before it delivered the dark blue feature while the other systems delivered the blue feature first. Quite clearly, in this model each system is able to deliver features at its own pace.
But this will only work if the systems are able to track dependencies between each other and can be deployed and tested independent of each other. In this way, there are no ducks to line up. Each system is delivering its own features in its own timeline. There is not much of a tension for each team since no one is waiting for them to deliver anything. Each product is in its own timeline. Some of these features can even be hidden with a feature flag and “go dark” in the deployment.
Software Release vs. Business Release
In this context, what is a release? When do we say that Feature F1 has been delivered for instance? The astute reader would look at the Autonomous deployment model above and state that F1 (in light blue) would be ready between 5 ’15 and 8 ’15 – somewhere in the neighborhood of 7 ’15. (after System 3 which is the last system to implement feature F1 deploys it in production) So the Product owner now can “advertise” Feature F1 during that time to end users.
Feature F1 may possibly be “turned on” with some feature toggle. During that time, the business teams would start getting ready to make relevant business changes that might be required by feature F1. In short, we would have de-coupled deployment from release. Release would become a conduit for business change not a software IT construct.
This change would be so subtle that hardly anyone notices it. Teams would not even think of it as a big deal anymore. We have effectively de-coupled business timelines from IT timelines. All of a sudden, the release fever would become a thing of the past. No more sleepless nights! Seriously! A’int that cool?
Raja has been blogging in this forum since 2006. He loves a technical discussion any day. He finds life incomplete without a handy whiteboard and a marker.