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).
Here are the benefits stated in the diagram in text form:
- Immediate start after check-in: no wasted time
- One new change per new pipeline: transparent debugging
- Parallel execution: faster feedback
- All stages e.g. code analysis used as enforceable gates: easy to enforce quality controls
- Can include infrastructure / environment build as well as application deployment: predictable and consistent behaviour
- Visible project status: easy to understand current stage of delivery execution
- If a stage fails, the committer of the change can be immediately notified: efficient communication
- Fully automated: predictable outcomes and minimised manual effort
- Consistently executed automated test harness: high visibility of code quality and automated test stability
- Easy to drill down to cause of failure: faster debugging
- Highly visible historic information: can extract trends which inform planning decisions
- Tested build package re-used: predictable and consistent behaviour
- Environments are recreated from version control so no need to limit: efficient debugging
- Infrastructure resources recycled: efficient use of cloud services
- Some stages may only be triggered manually: compatible with release management approval processes
- 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.