Continuous Delivery – The New Way to Develop Software


As you are probably aware, there is a new development methodology called “Continuous Delivery (CD)” that is becoming very popular these days. It can be considered as taking Agile to the next level. The majority of Software as a Service (SaaS) companies have adopted CD as a way to handle the multiple updates to websites created every day. However, in a recent survey*, even with non-SaaS companies, 51% of have adopted CD and 65% have migrated one or more projects to CD.  That’s an amazing transition in only few years.

So why is CD so popular?

The driving factor is that it is a fast-moving world out there, and companies need CD to quickly, efficiently, and reliably adapt their software product to meet the needs of user feedback, and ever-changing shifts in market needs and business strategy. Said another way, it allows large companies to operate much more like startups.

In addition, companies gain several internal and external benefits by moving to CD.

Internal Benefits:

  • Engineering productivity: Productivity improves in two major ways:
    • Without good customer feedback, some percentage of the features developed by your Engineering team will not be valuable to your customer. If your Engineering team build only what the customer/market wants, then they are, by definition, much more productive. The continuous customer feedback loop gives you that opportunity to find out what is and is not being used in your product so that you can focus your efforts accordingly.
    • In most organizations, there is a bifurcation between the Engineering teams creating the new functionality and the Engineering Services (ES) team responsible for final build, test, and delivery to customer. The handoffs and iterations between these two teams are usually quite inefficient. Secondly, the ES team is typically providing a service to multiple Engineering teams and resource bottlenecks are common. How often has your product release been held up in ES because they were busy finishing off some other product release? A better model is to have ES develop a “self-serve” infrastructure for build, test, and delivery that product teams can use by themselves. This way, all bottlenecks are removed and product teams are free to release when and how often they wish.
  • Efficient Build, Test, and Delivery: Most companies still use a number of manual steps in order to get product out to the customer. However, it’s inefficient and error prone to depend on humans for such repetitive tasks. By fully automating build, test, and delivery you can:
    • Reduce the amount of headcount needed to manage builds, tests, and delivery and/or move existing headcount up into higher-value projects that depend on human creativity and involvement.
    • Fundamentally change the way you release product. Limited only by compute power, you can release much more frequently – multiple times a day if desired. This doesn’t always make sense for new functionality since customers can only absorb a certain amount of change, but it changes the paradigm on support and availability of bug fixes.
  • Improved Product Quality: With the focus on test automation, product quality improves, reducing your in-house support costs and increasing customer satisfaction.

Customer Benefits:

  • Building the right product versus building the product right: First-and-foremost, customers get the right product from you – the one they most want to use (and purchase).
  • Early access and feedback: For the early adopters out there, they get a chance to try out new functionality that is hot off the press. In addition they get to influence product direction by providing early feedback on that functionality.
  • Customers see higher quality product: Both in terms of reliability as well as functionality
  • More frequent bug fixes: The ease of creating releases encourages a more frequent stream of bug fixes so your customers don’t have to wait until the next “Service Pack” release to get access to the fix.

In the next article, I’ll go into more detail on how best to implement Continuous Delivery within your organization.


*Footnote: Survey data gathered from a Perforce-sponsored survey

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>