Continuous Delivery

Have you been working on a software project where your momentum seems to be slowing down? It tends to happen as features are added, because it requires time and effort to maintain and verify existing features with each and every release. Without automated tests, momentum slows, or worse, you end up shipping broken software from time to time.

A book titled Continuous Delivery enumerates changes and improvements that organizations can adopt to increase momentum. The business case seems compelling, with the promise of:

  1. Faster reaction times (for the business, for new features, for bugfixes)
  2. Reduced risk via earlier feedback
  3. Flexibility in releasing (dormant features, enabled with a feature switch)
  4. Reduced development costs

The authors have an informative website, and others, including Atlassian, have written on the topic of Continuous Delivery in an informative series of blog posts called “A skeptic’s guide to continuous delivery”, split into parts one, two, three, four and five. In the first installment, they say “CD fundamentally requires some amount of cultural rewiring because the core structure of CD is a delivery pipeline through which changes flow”.

I like the vision of Continuous Delivery, and if large and small companies have used it to increase their agility in achieving business objectives, then it’s possible for others to do the same.