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 be skipped or run less frequently during development.
- We will keep software deployable throughout its lifecycle and prioritize 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 abstrations and/or feature branching where appropriate.
- We use a single trunk based CI build as the begining of our pipline.
- 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.
- The Bermondsey project and John Lewis Ventures are very close to a full automated release. 1jl and Apigee have a couple of manual gates.
- Amazon / Netflix are at the expert level.
- Team Disco mitigate risk will a fully automated pipeline (build, test and deploy), they alert in production when metrics deviate from their expectations. This allows for easier rollbacks.
Points for discussion
- Are you doing it? Are you using a CI tool?
- What manual gates are in place?
- Can you release straight to production?
- Are you using trunk based development with feature flags as necessary?
- Are branches short lived?