Etsy lieferte Dutzende Male täglich Code aus, sodass keine einzelne Veröffentlichung die Website zum Absturz bringen konnte

In den 2000er-Jahren war die Veröffentlichung einer neuen Version einer Website ein Ereignis: Engineering-Teams bündelten wochenlange Änderungen in einem einzigen Push, planten dafür Ausfallzeiten ein und betrachteten den Deployment-Tag als den Moment, in dem alles auf einmal kaputtgehen konnte. Etsy arbeitete ebenso, mit einem eigenen Deployment-Team als Gatekeeper und späten Nächten, wann immer ein gebündeltes Release schiefging, weil niemand sagen konnte, welche der Dutzenden gleichzeitigen Änderungen den Fehler verursacht hatte.

Die übliche Lösung für fragile Releases war mehr Prozess vor der Veröffentlichung – längere QA-Zyklen, mehr Freigaben, größere Staging-Umgebungen –, was Verzögerung hinzufügte, ohne das eigentliche Risiko zu beseitigen: Ein Release lieferte weiterhin vierzig Features auf einmal aus, sodass ein einzelner Bug die Ingenieure weiterhin zwang, entweder alles zurückzurollen oder unter Druck den gesamten Stapel zu durchsuchen, um die eine fehlerhafte Zeile zu finden.

Kontinuierliches Deployment: Dutzende kleine Produktions-Deploys pro Tag, jeder mühelos zuzuordnen und rückgängig zu machen, als Ersatz für gefürchtete Release-Nächte.

Es verkleinerte die Release-Stapelgröße auf eine oder wenige Änderungen pro Deploy, wodurch jeder Fehler mühelos zuzuordnen und kostengünstig rückgängig zu machen war, statt mehr Prozess vor der Veröffentlichung hinzuzufügen.

Große gebündelte Releases vergraben jeden einzelnen Bug unter Dutzenden Änderungen, wodurch die Zuordnung langsam und kostspielig wird.

Kleine Stapel bedeuten, dass jeder Deploy höchstens eine plausible Ursache hat, sodass Fehler sofort nachvollziehbar sind.

Kleine Änderungen sind einzeln rückgängig zu machen, sodass ein fehlerhafter Deploy rückgängig gemacht werden kann, ohne alles zurückzurollen.

Häufige kleine Deploys verteilen das Risiko auf viele Ereignisse mit geringem Einsatz, verringern die Angst und ermutigen zu noch kleineren Stapeln.

Wenn Fehler schwer zu diagnostizieren sind, verkleinere die Stapelgröße, statt mehr Prozess vor der Veröffentlichung hinzuzufügen.

Bis Mitte 2010 berichtete Etsys eigene Engineering-Leitung von etwa 200 Produktions-Deployments pro Monat mit steigender Tendenz („204 Produktions-Deployments im Juli, etwa 30 % mehr als im Juni“), jedes klein genug, um es einem einzelnen Ingenieur zuzuordnen; bis 2014 nannte das Unternehmen öffentlich etwa 30 Deploys pro Tag.