배포와 배포를 분리하는 방법은 무엇입니까?

연속 배포의 한 가지 방법은 배포와 릴리스를 분리하는 것입니다. 즉, 변경 사항을 즉시 활성화하지 않고 업데이트를 배포합니다.

나는 알고 기능이 토글 이 사용할 수 있습니다,하지만 난 "비 기능"에 대한 다른 방법이 있는지 궁금하네요.

예를 들어, 버그 수정을위한 기능 토글을 작성 하시겠습니까? 아마도 버그 픽스는 더 나아질 수 있기 때문에 가능한 빨리 배포해야한다고 주장 할 수 있습니다. 그리고 버그 수정이 릴리스 된 후에는 더 이상 해제하고 싶지 않습니다. 그러나 이것이 사실입니까? 통제 된 방식으로 릴리스하려는 것은 위험한 변경 일 수 있습니다. 예기치 않은 부작용 이 있으면 롤백 할 수 있습니다. 모든 변경에 대한 기능 플래그?

시각적 변화는 어떻습니까? 예를 들어 CSS에서 기능 플래그와 같은 것을 구현할 수 있습니까? 말이 되나요?

웹 앱 범주의 소프트웨어의 경우 인프라 / 호스팅 제공 업체에 따라 이러한 디커플링으로 인해 배포 된 다른 버전의 sw를 통해 들어오는 트래픽을 전환 (또는 분할)하여 실제로 언급 한 변경 사항 (실제로 버그 수정, 비주얼)을 처리 할 수 ​​있습니다. 등

이러한 지원에는 일반적으로 기능 토글이 필요하지 않습니다. 그리고 앱이 단일 서비스이거나 마이크로 서비스로 분할 되든 상관없이 적용 가능할 수 있습니다.

예를 들어 Google의 App Engine Paas 오퍼링은 트래픽 분할 및 마이그레이션을 지원합니다.

에서 분할 교통 :

트래픽 분할을 사용하여 서비스 내의 둘 이상의 버전에서 트래픽의 백분율 분포를 지정할 수 있습니다. 트래픽을 분할하면 버전간에 A / B 테스트 를 수행 하고 기능을 출시 할 때 속도를 제어 할 수 있습니다.

에서 마이그레이션 교통 :

트래픽 마이그레이션은 응용 프로그램 서비스 내의 버전간에 요청 라우팅을 전환하여 트래픽을 하나 이상의 버전에서 단일 새 버전으로 이동합니다.

단일체를 사용하는 경우 마이크로 서비스 아키텍처를 사용하여 스위치로 제한 될 수 있지만 서비스 (예 : 포드)를 제공하는 모든 배치 풀 노드를 분할 할 수 있습니다. 그런 다음 풀의 서브 세트에서 새로 변경된 제품의 배치를 활성화하고 신중하게 모니터하십시오. 예를 들어 트래픽의 15 %에 대한 변경을 활성화하는 등 변경을 배포 할 풀의 양을 선택할 수도 있습니다. 문헌에서 "롤링 업데이트"라는 기능을 찾을 수 있습니다.