스테이징의 문제
- pre-live는 프로덕션과 동일하지 않음
- 릴리즈 큐가 생김
- 릴리즈가 너무 커짐
- 변경에 대한 오너십이 부족
- 프로세스가 책임을 대신 지도록 내버려둠
Squeaky가 Ship하는 방법
- 라이브 가능한 것만 머지 : 변경에 대해 로컬 개발환경에서 충분한 테스트를 거침
- 플랫 브랜칭 전략을 사용 : 피쳐를 머지할 준비가 되면, 리베이스 하고 테스팅. 문제발생시 롤 포워드
- 고위험 피쳐 들은 항상 피쳐 플래그 이용
- 수작업 배포 : 변경후 지속적으로 모니터링. 모니터링/로깅/알람이 전반적으로 적용. 블루/그린 배포
결론
- 진정한 CI/CD를 위해서 스테이징 환경을 포기하면, 소프트웨어를 Shipping 하는 다른 사고 방식을 만들 수 있음
- 변경이 라이브되기전 버퍼가 없다면, 변경들이 프로덕션에 적합한지 확신이 있어야 함
- 자신이 한 모든 변경에 다한 오너십을 가지고, 주의를 기울여야 함
- 인프라 비용과 복잡성이 줄어들고, 개발 라이프사이클을 간소화 하고 가속할 수 있게 됨