• 원하는 환경에서 실행하기 위해 설계하고 구현하며 테스트하는 방법을 묶어서 살펴봄

이전에 다뤘던 컨퍼런스 시스템 사례연구를 다시 생각해보자

• 이 시스템은 하나의 사용자 인터페이스와 서버 측 애플리케이션으로 구현됨
• 즉, 서버나 사용자 인터페이스의 업그레이드를 배포한다는 것은 어느 정도의 다운타임이 발생한다는 것을 의미
• 배포와 릴리스 행위가 강하게 결합되어 따로 분리할 수 없을 가능성도 높음
• 게다가 배포에 문제가 생겨서 변경사항을 롤백하는 데도 시간이 걸릴 것

우선은 레거시 컨퍼런스 시스템의 UI와 서버 컴포넌트의 결합도를 낮춰서 더 다양한 방식으로 배포와 릴리스가 가능하도록 한 후 어떤 방식이 가능한지 보자.

트래픽 관리를 도입하면 배포와 릴리스를 분리할 수 있게됨

이 장에서는 이 부분을 좀 더 살펴보고 컨퍼런스 시스템의 변경사항을 롤아웃하는 옵션도 살펴봄. 그러자면 API 버저닝이 컨퍼런스 시스템의 릴리스 모델링 옵션에 어떤 영향을 미칠 수 있는지도 고려

롤아웃에 있어 중요하게 고려해야할 점

→ 변경사항이 성공적인지 아닌지를 이해하는 것.

API 아키텍처는 본질적으로 분리되어 있으며 성공적인 릴리스를 수행하기 위해서는 올바른 지표, 로그, 추적을 갖추는 것이 중요함.

• 지표는 어떤 식으로 고려해야 하는지 살펴본 후 이를 릴리스와 장애 관리/트러블슈팅에 활용하는 방법도 알아봄
• 마지막으로, 최종적 일관성이 변경사항에 어떤 영향을 미치는지 그리고 애플리케이션 수준에서 어디에 문제가 발생할 수 있는지 설명함.
• 인프라스트럭처에 프록시 같은 추가 계층을 도입하려면 캐싱 및 헤더 전파에 대한 결정이 필요함
• 이런 고려사항과 규약형 플랫폼을 선택해야 하는 이유에 대해 살펴보자