Etsyは1日に何十回もコードを出荷し、単一のリリースでサイトが沈むことはなかった

2000年代を通じて、ウェブサイトの新バージョンのリリースは一大イベントだった。エンジニアリングチームは数週間分の変更を1回のプッシュにまとめ、そのためにダウンタイムを予定し、デプロイ当日をすべてが一度に壊れうる瞬間として扱った。Etsyも同じやり方で運営しており、専任のデプロイチームがゲートキーパーを務め、まとめたリリースがうまくいかないときは深夜まで対応した。なぜなら、同時に行われた何十もの変更のうちどれが障害を引き起こしたのか、誰にも分からなかったからだ。

壊れやすいリリースに対する標準的な解決策は、リリース前のプロセスを増やすことだった。より長いQAサイクル、より多くの承認、より大きなステージング環境である。しかしこれらは遅延を加えるだけで、実際のリスクは取り除かなかった。リリースは依然として40の機能を一度に出荷するため、1つのバグが生じれば、エンジニアはすべてをロールバックするか、プレッシャーの中でバッチ全体を探し回って原因の1行を見つけるかを強いられた。

継続的デプロイとは、1日に何十回もの小さな本番デプロイであり、それぞれがきわめて追跡可能で可逆であり、恐れられていたリリースの夜を置き換えるものである。

リリース前のプロセスを増やす代わりに、リリースのバッチサイズを1デプロイあたり1つまたは少数の変更に縮小し、各障害をきわめて追跡可能で取り消しやすくした。

大きなまとめリリースは、何十もの変更の中に単一のバグを埋もれさせ、原因の特定を遅く高コストにする。

小さなバッチでは、各デプロイにせいぜい1つのもっともらしい原因しかないため、障害は即座に追跡できる。

小さな変更は個別に可逆であるため、悪いデプロイをすべてロールバックせずに取り消せる。

頻繁な小さなデプロイはリスクを多くの低リスクな出来事に分散させ、恐れを減らし、さらに小さなバッチを促す。

障害の診断が難しいときは、リリース前にプロセスを増やすのではなく、バッチサイズを縮小せよ。

2010年半ばまでに、Etsy自身のエンジニアリングリーダーシップは月におよそ200回の本番デプロイを行い、増加中であると報告した（「7月に204回の本番デプロイ、6月より約30%多い」）。それぞれは1人のエンジニアまで追跡できるほど小さかった。2014年までに、同社は1日約30回のデプロイを公に挙げていた。