The delivery strategy determines how changes of all kinds are staged into production.
Clone this repo and document your delivery strategy here:
Content
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
The goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.
See:
-
Align the Delivery strategy with application architecture and rollback- and testing-strategy
-
Progressively expose new features to a wider audience to reduce blast radius of problems
-
Decouple deployment from release (user rings, feature flags)
-
Focus on reducing batch (new features) size
-
Optimize for resilience
Classic model. Phases new releases through permanent test, acceptance and production environments (development is always the developer’s local environment)
Creates on-demand temporary environment for different stages, production is the only permanent environment
Only has Development and Production environments. Uses coded and configured mechanisms (feature flags, user rings, canary deployments) that allow for testing-in-production
Large modular systems (s.a. microservices architectures) are difficult to continuously deliver using ‘classic DTAP’ and testing-strategies. Non-production environments are often not representative for tests either. The solution is Testing-in-Operation. Techniques includes:
- Feature flags
- Ring deployments
- Dark launches
- Blue Green