Slack의 Deploy 프로세스

- 모든 PR은 코드리뷰와 테스트 통과 필요
- 머지된 코드는 북미 업무시간에만 디플로이 됨 (문제 발생시 해결위해)
- 하루에 약 12번 정기배포
- 각 배포당 배포담당자가 지정됨
1. 릴리즈 브랜치 생성
2. 스테이징에 배포하고 매뉴얼 테스트
3. 내부 슬랙(개밥먹기 티어)에 배포 후, Canary 배포 ( 전체 트래픽의 2% 만 라우트 되는 )
4. 10,25,50,75,100 퍼센트까지 단계별 배포 진행
리스크 관리를 위해 배포담당자를 훈련시키고 모든 단계를 감독 하고 커뮤니케이션을 담당하게 함
문제를 최대한 빨리 잡아내서, 원인 PR을 확인하고, 빼낸다음 새 빌드 배포.
프로덕션까지 가는동안 찾아내지 못하는 문제가 발생했다면 조사전에 일단 원상복구 부터 진행.

회사 초기에 10개의 EC2인스턴스만 운영했을때의 배포는 단순히 rsync 하는 것이었음.
프로덕션 배포전에 Staging 한 단계만 존재했고, 테스트후 바로 배포를 진행.
점점 고객이 늘면서 rsync 만으로 어려워짐.

→ Full parallel pull-based 시스템으로 변경

새 빌드를 서버에 스크립트로 넣는게 아니라, 각 서버들이 Consul 키 변경으로 신호를 받을때 동시에 빌드를 받아오게 함

→ Hot/Cold 폴더로 분리한 Atomic Deploy

배포시 새 코드를 사용하지 않는 Cold 디렉토리에 복사, 기존 서비스는 Hot 디렉토리가 서빙.
서버에 활성프로세스가 없을때 Hot/Cold 디렉토리를 서로 교환하여 새코드가 즉시 서빙.

[xguru]

Consul by Hashicorp https://www.consul.io/

슬랙 백엔드가 HHVM에서 돌아가는 PHP/Hacklang 이라서 저 Hot/Cold 교환이 가능한듯
https://www.quora.com/What-is-the-tech-stack-behind-Slack