Decouple deployment from release — and choose the pattern that fits
A deployment is a technical act (push code to an environment); a release is a business act (make the change visible to customers). Treating them as the same thing makes every release a high-stakes event. Decoupling them is what makes daily deploys safe.
Technical: ship the bits to an environment. Happens many times a day. Tested, automated, rehearsable. No customer visibility required.
Business: make the new behavior visible to customers (or a subset). Happens on a marketing calendar, a flag flip, an A/B ramp. Reversible without re-deploying.
Environment-based
Application-based
Two identical production environments — blue (live) and green (next). Deploy the new version to green, run smoke tests, then flip a load balancer / DNS / service-mesh route to send traffic to green. Roll back = flip back to blue.
Database changes are the hard part. Two patterns:
- — Two databases (blue and green) with a sync mechanism. Heavy.
- — Decouple DB changes from application changes: deploy schema migrations independently in a backward-compatible way; only then deploy code that uses the new schema. Preferred — it's how big sites actually do it.
// case · dixons retail used blue-green for point-of-sale rollouts in 2008.
download Case study · Dixons Blue-Green (2008) · PDF ~290 KBRoll out to successively larger and more critical groups, checking acceptance criteria between each. From the tradition of coal miners bringing canaries to detect toxic gas before it hit them.
Production servers serving internal employees only.
A small slice of real customers, after A1 criteria are met.
Full fleet, after A2 criteria are met.
Cluster immune system extends canary by tying production monitoring to the release process: if user-facing metrics drop outside the expected range (e.g., conversion drops below the historical 15–20%), automatically roll back. Catches the bugs tests can't — like a CSS change that hides a critical button.
A feature toggle is a runtime switch around code. The new code is in production; the toggle controls whether it runs. What toggles enable:
- — Roll back easily — flip the flag instead of redeploying.
- — Gracefully degrade — turn off expensive features under load.
- — Resilience via SOA — fail a downstream call gracefully when a dependency is down.
- — A/B testing — show different behavior to different cohorts and measure.
// your automated acceptance tests should run with all toggles ON. and test the toggle system itself.
Deploy the new feature's backend code to production weeks before the UI is exposed. Run real production load against it (simulated user actions, shadow traffic from the existing system) to stress-test scaling, monitoring, and edge cases. By the time the feature is announced, the infrastructure has been proven under real prod conditions.
Classic case: Facebook Chat (2008). The chat backend ran in production for months before any user saw it — Facebook's pages silently sent ghost requests to the chat servers so the team could observe behavior under real load. By launch day, the system was already battle-tested.
download Case study · Facebook Chat Dark Launch (2008) · PDF ~340 KBModules 01–06 are the technical practices of the First Way (Flow). You now have the org shape (M03), the substrate (M04), the test discipline (M05), and the release patterns (M06) to move from monthly painful releases to daily, low-risk, business-controlled rollouts. Apply this to one value stream in your own org and watch what changes.
Marketing wants to announce a new feature on Monday but the code is not fully tested yet. Engineering wants more time. What does decoupling deployment from release allow?
// pick one to verify
A team uses Blue-Green deploys but shares a single live database with both colors. They deploy a schema change with the green release. What's the predictable problem?
// pick one to verify