Etsy는 하루에 수십 번 코드를 배포하여 단일 릴리스가 사이트를 침몰시킬 수 없도록 했다

2000년대 내내 웹사이트의 새 버전을 릴리스하는 일은 하나의 이벤트였다. 엔지니어링 팀은 몇 주 분량의 변경 사항을 하나의 푸시로 묶고, 이를 위해 다운타임을 예약했으며, 배포일을 모든 것이 한꺼번에 망가질 수 있는 순간으로 여겼다. Etsy도 같은 방식으로 운영되었는데, 전담 배포 팀이 게이트키퍼 역할을 했고, 묶음 릴리스가 잘못될 때마다 야근이 이어졌다. 동시에 이루어진 수십 개의 변경 중 무엇이 실패를 일으켰는지 아무도 알 수 없었기 때문이다.

취약한 릴리스에 대한 표준 해법은 릴리스 전에 더 많은 프로세스를 두는 것이었다. 더 긴 QA 주기, 더 많은 승인, 더 큰 스테이징 환경이 그것이었는데, 이는 지연만 더할 뿐 실제 위험은 제거하지 못했다. 릴리스는 여전히 40개의 기능을 한꺼번에 내보냈고, 따라서 단 하나의 버그만으로도 엔지니어들은 모든 것을 롤백하거나 압박 속에서 전체 묶음을 뒤져 문제의 한 줄을 찾아야 했다.

지속적 배포: 하루 수십 번의 작은 프로덕션 배포로, 각각을 쉽게 귀속시키고 되돌릴 수 있게 하여 두려움의 대상이던 릴리스의 밤을 대체했다.

릴리스 전 프로세스를 더 추가하는 대신, 배포당 릴리스 묶음 크기를 하나 또는 몇 개의 변경으로 줄여 각 실패를 쉽게 귀속시키고 저렴하게 되돌릴 수 있게 했다.

대규모 묶음 릴리스는 수십 개의 변경 속에 단일 버그를 묻어버려 귀속을 느리고 비용이 많이 들게 만든다.

작은 묶음은 각 배포에 기껏해야 하나의 그럴듯한 원인만 있게 하므로, 실패를 즉시 추적할 수 있다.

작은 변경은 개별적으로 되돌릴 수 있으므로, 잘못된 배포를 모든 것을 롤백하지 않고도 취소할 수 있다.

빈번한 소규모 배포는 위험을 많은 저부담 이벤트에 분산시켜 두려움을 줄이고 더 작은 묶음을 장려한다.

실패를 진단하기 어려울 때는 릴리스 전에 프로세스를 더 추가하는 대신 묶음 크기를 줄여라.

2010년 중반까지 Etsy의 자체 엔지니어링 리더십은 월 약 200건의 프로덕션 배포를 보고했으며 이는 증가 추세였다("7월에 204건의 프로덕션 배포, 6월보다 약 30% 많음"). 각 배포는 한 명의 엔지니어까지 추적할 수 있을 만큼 작았다. 2014년까지 회사는 하루 약 30건의 배포를 공개적으로 언급했다.