#541 2010 · Etsy · Software
Etsy shipped code dozens of times a day so no single release could sink the site
the problem
Big launches broke production every time
background
Through the 2000s, releasing a new version of a website was an event: engineering teams bundled weeks of changes into a single push, scheduled downtime for it, and treated deploy day as the moment everything could break at once. Etsy ran this way too, with a dedicated deployment team acting as gatekeeper and late nights whenever a bundled release went wrong, because nobody could tell which of dozens of simultaneous changes had caused the failure.
The standard fix for fragile releases was more process before the release — longer QA cycles, more sign-offs, bigger staging environments — which added delay without removing the actual risk: a release still shipped forty features at once, so a single bug still forced engineers to either roll back everything or hunt through the whole batch under pressure to find the one line at fault.
what everyone would do
Add more process before release — longer QA cycles, more sign-offs, bigger staging environments. It fails because it adds delay without removing the actual risk: a release still bundles dozens of changes together, so a single bug still forces engineers to either roll back everything or hunt through the whole batch under pressure to find the one line at fault.
what they saw
Etsy saw that the real problem wasn't insufficient vetting before release, it was batch size — bundling weeks of changes into one push meant any single failure was buried among dozens of others, making it slow to attribute and expensive to fix. Shrinking the batch to one or a few changes per deploy, rather than hardening the batch with more process, made each individual failure trivially traceable and cheap to undo.
the move
Continuous deployment: tens of small production deploys a day, each trivially attributable and reversible, replacing feared release nights.
why it works
A large bundled release contains many simultaneous changes, so when something breaks, the cause could be any of them, and finding it means searching the whole batch under pressure. Deploying small batches instead means each release has at most one plausible cause if something breaks, making attribution nearly instant, and because each change is individually small, a bad deploy can be reverted on its own rather than forcing a choice between rolling back an entire multi-feature release or debugging live. Deploying far more frequently spreads risk across many small, low-stakes events instead of concentrating it in rare, high-stakes ones, which is why elite engineering teams that deploy most often were later found to have the lowest change-failure rates, not the highest — smaller, safer deploys reduced the fear around shipping, which encouraged even more frequent, even smaller deploys.
the payoff
By mid-2010 Etsy's own engineering leadership reported roughly 200 production deployments a month and rising ("204 production deployments in July, about 30% more than June"), each small enough to trace to one engineer; by 2014 the company was publicly citing about 30 deploys a day.
where it breaks
The approach only works when the underlying system and organization actually support fast, automated, low-friction deployment — a team without automated testing, monitoring and rollback infrastructure trying to deploy in small batches just multiplies the manual overhead of each release instead of reducing risk. It also depends on being able to genuinely decompose work into small, independently deployable units; some changes, like a database schema migration or a major architectural shift, are inherently large and can't be meaningfully split without real engineering effort to make them incremental. And it requires a culture that tolerates and quickly responds to the small failures that will inevitably occur — a small-batch strategy assumes failures happen constantly but stay individually cheap, and an organization that punishes any failure regardless of size undermines the psychological safety that makes engineers comfortable shipping frequently in the first place.
what came after
Etsy's Code as Craft blog, launched in 2010 to document the practice, became one of the founding texts of the DevOps movement; the small-batch, individually-attributable deploy became industry orthodoxy, later validated at scale by the DORA research program, which found that elite-performing engineering teams deploy most often and have the lowest change-failure rates, not the highest.
references
- [1]Scaling startupsChad Dickerson (Etsy CTO, personal engineering blog), 2010blog.chaddickerson.com
- [2]The Future Workplace Is Now: How Etsy Makes 30 Innovations Per DayForbes, 2014forbes.com