Practical Benefits of Continuous Delivery

As I’ve discussed previously, I believe that Continuous Delivery is a practice that no software delivery organization should ignore.

Fundamental to implementing continuous delivery is building a delivery pipeline.  I drew up the following diagram of a delivery pipeline because I’ve found it useful for articulating the practical benefits of Continuous Delivery and highlighting where they are realized in the software delivery lifecycle.

I’m posting here in case it is of use to others (click to enlarge).

Benefits of a delivery pipeline

Here are the benefits stated in the diagram in text form:

  1. Immediate start after check-in: no wasted time
  2. One new change per new pipeline: transparent debugging
  3. Parallel execution: faster feedback
  4. All stages e.g. code analysis used as enforceable gates: easy to enforce quality controls
  5. Can include infrastructure / environment build as well as application deployment: predictable and consistent behaviour
  6. Visible project status: easy to understand current stage of delivery execution
  7. If a stage fails, the committer of the change can be immediately notified: efficient communication
  8. Fully automated: predictable outcomes and minimised manual effort
  9. Consistently executed automated test harness: high visibility of code quality and automated test stability
  10. Easy to drill down to cause of failure: faster debugging
  11. Highly visible historic information: can extract trends which inform planning decisions
  12. Tested build package re-used: predictable and consistent behaviour
  13. Environments are recreated from version control so no need to limit: efficient debugging
  14. Infrastructure resources recycled: efficient use of cloud services
  15. Some stages may only be triggered manually: compatible with release management approval processes
  16. The pipeline runs successively slower and more expensive quality gates: ensures optimised fast feedback


The pipeline in the diagram is for a single independent software component.  I will describe how to handle multiple components in a future post.

The imagery is inspired by the build pipeline plugin for the Jenkins tool.