One of the biggest problems with a lengthy release cycle for a software system is that you build up an inventory of changes which, if released more quickly, could have yielded some return on investment sooner. By introducing a continuous delivery process which allows teams to release changes as soon as they’re ready there is potential for ROI benefits but also some other, less tangible, benefits.
Imagine a 12-week release cycle with many features created during six weeks of development which is then followed by six weeks of testing before the whole lot is released in one go.
If one of the features which was part of the release required only one week to develop and one week to test but has the potential to increase revenue by £10,000 per week.
Then the 12 week release cycle means a potential loss of £100,000 versus the continuous delivery model where the feature could have been release after two weeks.
One of the key other benefits, beside releasing value, is reducing friction. When you target a single release a long way off and many features are being developed in parallel there is large possibility for buggy changes to interact badly before they stabilise. This can result in wasted effort debugging and chasing shadows due to what amounts to building on a moving foundation.
Effort can also be wasted during the testing phase where a bug fix required to one of the features results in all the other features needing to be retested to ensure they aren’t adversely affected.
Continuous delivery has many benefits, it makes teams more efficient and releases the value of changes faster. In future posts we’ll look at our model for continuous delivery at trainline and how we successfully migrated a key part of our system from a long release cycle to continuous delivery.