Laws of Software Engineering · Principle
Principle
Continuous Delivery
Keep software in a state where it could be released to users at any moment, by anyone, with confidence.
How to use it. Treat every change as if it will ship today. That means automated tests, automated deployment, trunk-based development, and small batches. The pressure of "could ship now" exposes every weakness in the delivery pipeline that batch releases hide.
How it gets misused. Confused with continuous deployment, which ships every change automatically. Continuous Delivery means a change could ship, and the business decides whether it does. Mixing them up tangles the argument about pace with the argument about readiness.
Related
- Practice Continuous Integration Every change is merged to a shared trunk at least daily, with automated verification.
- Practice Trunk-Based Development Everyone works on a single shared branch. Features ship behind flags until ready. Branches last hours rather than days.
- Framework The Three Ways A way of seeing DevOps as a whole. Optimise flow from idea to production. Amplify feedback from production back to development. Build a culture of continuous experimentation and learning.