Continuous delivery gives the capability to identify a requirement, code a solution, test it, and release it within a few hours. As I see it continuous delivery will become the norm amongst software companies. I think the trend is inevitable.
I’ve been in software development for over 30 years and I’ve watched an steady trend towards shorter development cycles.
Waterfall commonly involved the development team going away for a few months or years and coming back with a, supposedly, finished system.
People still do waterfall with big bang releases but it is now far from common. Lean-Agile is now mainstream. However even within Lean-Agile there has been a trend to shorter cycle times.
Barry Boehm’s (1986) Spiral Model was the first of the high profile iterative development methods. The Spiral Method assumed iterations between 6 months and 2 years. Very slow by more recent standards but snappy given that this method was envisaged for projects spanning several years.
About 2000 the main agile methods – Scrum and Extreme Programming (XP) – hit the headlines. Scrum advocated one month iterations (Schwaber & Beedle, 2002) and Scrum gurus still seem keen on this. In contrast XP assumed timeboxes of 1 to 4 weeks (Beck, 2000). My impression is that 3 weeks was popular 5-10 years ago but there has been a general trend to 2 weeks and many teams go for 1 week iterations.
Lean and Kanban abandoned timeboxes and introduced the concept of continuous flow (Anderson, 2010). Work items flow through the system and the software is released when the item pops out the end of the development pipeline.
A related concept, and the one that I think is most exciting, is Continuous Delivery (Humble & Farley, 2010). Continuous delivery technology means the software is already packaged for deployment to live after a successful check-in.
With continuous flow and continuous delivery the cycle time potentially drops to a matter of minutes, but comes with the assurance that all of the appropriate quality checks have taken place. It is worth remembering that continuous delivery is not the same as continuous deployment. Just because you can deploy to live doesn’t mean you are going to. There might be organisational reasons why you want to retain a schedule of releases, for example, my current programme fought hard to get a weekly release slot and more frequent releases are culturally unacceptable. The thing about continuous delivery is that if you need a shorter release cycle you have the capability for one.
The Lean-Agile movement came out of a desire for more responsive software development. That demand will remain until the software arrives faster and more often than the organisation can use it. Continuous delivery is the logical conclusion of that drive.
I think with continuous delivery the software game has changed forever. Wide spread adoption will take time, as it did with Lean-Agile, but I believe continuous delivery will become the norm within a few years. I for one can’t imagine leading a team that wasn’t at least trying to do it.
References
Anderson, D. (2010). Kanban: Successful Evolutionary Change for your Technology Business. Blue Hole Press.
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.
Boehm B, “A Spiral Model of Software Development and Enhancement”, ACM SIGSOFT Software Engineering Notes”, “ACM”, 11(4):14-24, August 1986
Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum. Prentice Hall.
Takeuchi, H., & Nonaka, I. (January-February 1986). "The New New Product Development Game" (PDF). Harvard Business Review
Stack, P. (2012, 3 Aug). continuous delivery is not the same as continuous deployment. Adventures of a Wannabe Geek.