Reliability Engineering
posts (7)
- Deployment Strategies: Why They Exist6/6
Shadow Traffic: Testing Without Responding to the User
Shadow traffic sends a copy of a request to the new version, but the user receives the old version's response. It tests behavior without taking over traffic.
- Deployment Strategies: Why They Exist5/6
Feature Flags: Deploy Is Not Release
A feature flag lets you deploy code without enabling behavior. It shortens feature rollback, but creates debt if flags are not removed.
- Deployment Strategies: Why They Exist4/6
Targeted Rollout: A/B Tests, Rings, and Segments
Canary splits traffic by percentage. Targeted rollout chooses specific users, rings, or segments, so it answers a different question.
- Deployment Strategies: Why They Exist3/6
Canary Deployment: The New Version Gets Part of the Traffic
Canary limits blast radius by using a small percentage of real traffic. Without metrics, it is only a slower rollout.
- Deployment Strategies: Why They Exist2/6
Blue-Green Deployment: Two Versions, One Traffic Path
Blue-green separates deploying from switching traffic. Rollback can be fast, but data does not move back with routing.
- Deployment Strategies: Why They Exist1/6
Rolling Update: Replacing Pieces Gradually
Rolling update removes downtime during version replacement, but it only works safely when old and new versions can live together for a while.
- series · 6 parts
Deployment Strategies: Why They Exist
Deployment strategies did not appear to make pipelines look serious. They appeared because replacing a version became a moment of risk.