Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. Systems will be structured to enable fast, automated feedback on quality and correctness.
Continuous Integration usually refers to integrating, building, and testing code within the development environment. Continuous Delivery builds on this, dealing with the final stages required for production deployment. This is done to reduce deployment risk, show believable progress, and reduce the time to get feedback from real users.
Failures identified very soon after the cause are easiest to fix; details of the change will still be fresh in the engineer's mind. Slow-running tests will tend to be skipped or run less frequently during development.
- We will keep software deployable throughout its lifecycle and prioritise keeping the software deployable over working on new features through constant investment.
- Fast feedback is required both on an engineer's machine for a specific component for production readiness, and in context with other components/applications as part of a continuous delivery pipeline.
- Delivery approach should be informed by risk and risk appetite in order to focus mitigation approaches. Risk can be mitigated through a combination of automated checks, deployment and release processes and exploratory testing.
- We can perform push-button deployments of any version of the software to any environment on demand
- We use trunk based development, mixing in branching by abstraction and/or feature flags where appropriate.
- We use a single trunk based CI build as the beginning of our pipeline.
- Applications and systems should be broken down into smaller components, each of which can be built and tested quickly.
- Applications should be capable of being built via a single command where possible.