Squeaky가 스테이징 환경을 쓰지 않는 이유
(squeaky.ai)스테이징의 문제
- pre-live는 프로덕션과 동일하지 않음
- 릴리즈 큐가 생김
- 릴리즈가 너무 커짐
- 변경에 대한 오너십이 부족
- 프로세스가 책임을 대신 지도록 내버려둠
Squeaky가 Ship하는 방법
- 라이브 가능한 것만 머지 : 변경에 대해 로컬 개발환경에서 충분한 테스트를 거침
- 플랫 브랜칭 전략을 사용 : 피쳐를 머지할 준비가 되면, 리베이스 하고 테스팅. 문제발생시 롤 포워드
- 고위험 피쳐 들은 항상 피쳐 플래그 이용
- 수작업 배포 : 변경후 지속적으로 모니터링. 모니터링/로깅/알람이 전반적으로 적용. 블루/그린 배포
결론
- 진정한 CI/CD를 위해서 스테이징 환경을 포기하면, 소프트웨어를 Shipping 하는 다른 사고 방식을 만들 수 있음
- 변경이 라이브되기전 버퍼가 없다면, 변경들이 프로덕션에 적합한지 확신이 있어야 함
- 자신이 한 모든 변경에 다한 오너십을 가지고, 주의를 기울여야 함
- 인프라 비용과 복잡성이 줄어들고, 개발 라이프사이클을 간소화 하고 가속할 수 있게 됨
조직 내에서 스테이징 환경을 구축하면서 느꼈던 안정감을 생각하면 공감은 잘 안되네요.
그럼에도 배포가 밀린다거나 변경 내용이 많아지는 단점은 공감이 됩니다.
스테이징 환경이 존재한다는 점만으로도 다른 환경으로 배포할 수 있고, 복제할 수 있는 소프트웨어의 본질?을 만족하는지 확인할 수 있어서 의미가 있다고 생각합니다.
글쎄여 "오너쉽" / "주의" 가 불완전한 사람에게 기댈 일인지 모르겠네요 최소한 시킨 대로는 완벽하게 작동하는 컴퓨터에게 도움을 받는 것이 컴퓨터 프로그래머라면 해야 되는 일이 아닌가요
그리고 개념을 확장에서
스테이징 = 최종 승인용 (우리가 이야기 했던 스팩이랑 최종적으로 같은지 프덕트 데이터를 넣었더니 생각보다 보기 싫다 등등 같은 점검용)
데브 = 개발자 등 인원과 피쳐에 관한 토론용 (데모용)
으로 사용 중인데요
음.. 저는 이런 문제는 어떤 서비스를 개발하고 있는가에 따라 다른거라고 생각하긴 합니다.
아무리 테스트해도 문제는 생길 수 있고, 그거를 사용자가 받아들일 수 있는가를 따져봐야죠.
페이스북 처럼 오동작 해도 그런가 보다 하는 소프트웨어는 이런 방식이 가능한거고,
미션 크리티컬한 인프라나, 유료서비스라면 문제가 생기지 않게 만전을 기해야 할 것 같아요.