Agile Zone is brought to you in partnership with:

Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

The Holy Trinity of Continuous Deployment, Integration & Incremental Delivery

03.30.2011
| 1894 views |
  • submit to reddit

There has been increasing buzz around the concept of Continuous Deployment - the practice of continually pushing out small, incremental changes into production rather than having “big bang” releases.

To me, Continuous Deployment is really only the natural extension of four very important concepts, at least two of which should be familiar to most who have worked in proper Agile environments:

  • The Agile concept of Incremental Delivery of value and (rarely followed) discipline of constantly delivery production quality code, not just after a lengthy spell of “code hardening” and bugfixing. 
  • If anything, Continuous Deployment is the absolute natural extension of Continuous Integration. It is Continuous Integration taken to its natural and logical conclusion.
  • The Lean concept of Flow, in many ways similar to Incremental Delivery, but without artificial time-boxes or batches of work.
  • the business concept of Minimum Viable Product - a method of quickly reaching market with the least amount of functionality that makes a product.

In a way, Continuous Deployment and these four concepts are mutually reinforcing in a reflexive relationship: Continuous Deployment enforces discipline to adhere to these four very valuable concepts, and the concepts themselves almost necessitate maintaining a system that is amenable to Continuous Deployment.

Time-to-Market & The Business Aspect of Continuous Deployment
Without Continuous Deployment, organizations are constantly tempted to not pull the trigger, to not try to define a Minimally Viable Product, but instead wait to “perfect” a product that is never released, because they do not have the mindset or practice that leads them down the path of thinking in terms of flow and MVP. In my opinion and experience, many IT projects fail, not because of technical incapability to deliver, but due to a combination of analysis-paralysis in terms of scope and size of releases and the misguided wish from business stakeholders to try to release a “perfect” product/solution some time in the distant future, rather than receive useful market feedback from a minimally viable product that is released into the market with a short cycle time and iterate from there.

Continuous Deployment is an enabler and driver to create the mindset of Minimally Viable Product definition and an urgency to get to market.

Batched Releases Breed Complacency & Unaccountability
Without Continuous Deployment, development organizations, even with the best of intentions work to distant batch release deadlines, even though they may formally speak of “Sprints”. These distants deadlines further undermine the technical capability of incremental delivery of an MVP, and they undermine the psychology of the organization itself when it comes to the quality delivered. This in turn means that deliveries become large “batches” rather than a natural flow of incremental value. These batches require lengthy verification by teams of testers, which in turn results in lengthy durations of developers “hardening” and bug fixing code, rather than delivering value.

Removing the batching up of value into big bang releases, the problems described above become more manageable: a single defect that creeps in with a single new feature is easier to discover and squash quickly, than if you find hundreds of defects in the weeks running up to a big bang release. Further, the incremental delivery likely means that the organization will be more in the mindset of trying to build in quality and design out defects before they are created and released, rather than being relaxed about them until a few weeks before a release. In effect, the developers are more accountable to the quality they create, hence they will take on a bigger role in quality assuring their own code through automated testing than what they would naturally do in a batch release environment - the result is fewer defects created and earlier discovery of those that do manage to slip by the developers.

Continuous Deployment Is Here To Stay
Continuous Deployment is no silver bullet, it’s not going to make all your problems go away. But it is the natural extension of a number of other good practices mentioned in this post, and a practice that will likely reinforce those other practices. In a sense, talking of Continuous Integration and Incremental Delivery of value without doing Continuous Deployment is almost ridiculous - they are three parts of a trinity that makes up the whole, without one of it’s constituent parts, the remaining practices are if not rendered entirely moot, at least severely weakened.

References
Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)