Etsy: Continuous Deployment — Shipping Code 50 Times a Day
How Etsy engineered a culture and technical pipeline that allowed any engineer to deploy code to production dozens of times per day, safely.
The challenge
By 2009, Etsy's deployment process involved a small operations team manually pushing code changes in large, infrequent batches — a process that made every deployment risky, since dozens of unrelated changes shipped together made it hard to identify which change caused any problem that appeared. Engineers were often afraid to deploy, since a botched release was a stressful, all-hands event.
The strategy
Etsy's engineering leadership made a controversial cultural and technical bet: rather than deploying less frequently to reduce risk, they would deploy far more frequently — dozens of times daily — in small, individually attributable changes. The theory was that small, frequent deployments are inherently lower risk than large, infrequent ones, since problems are easier to isolate and roll back.
Want the full story, outcome and quiz?
Read how Etsy executed it, the results, key lessons and test yourself with a quiz. Free on CaseLearn.
Try the full case free →Key lessons (preview)
- Counterintuitively, deploying more frequently in smaller batches can be safer than deploying less frequently in large batches.
- Feature flags allow code to ship to production before it's fully enabled, decoupling deployment from release.
- Removing the operations-team gatekeeper and letting engineers deploy their own code increases both speed and accountability.