지속적 배포 (Continuous Delivery)

지속적 제공 파이프라인의 프로덕션 단계 직전에 수동 게이트가 있는 경우가 있습니다. 수동 게이트에는 사용자의 개입이 필요합니다. 그리고 조직에는 파이프라인에 수동 게이트가 필요한 시나리오가 있을 수 있습니다. 수동 게이트에는 의문스러운 것도 있고 합리적인 것도 있습니다. 합리적인 경우라면 비즈니스 팀이 최종 순간에 릴리스 결정을 내릴 수 있습니다. 엔지니어링 팀은 매 스프린트가 끝날 때마다 제품의 제공 가능한 버전을 준비해 두고, 비즈니스 팀은 모든 고객이나 전체 사용자, 아니면 특정 지역에 사는 사용자에게 제품을 릴리스하는 최종 결정을 내립니다.

파이프라인을 거치는 제품의 아키텍처는 지속적 제공 파이프라인의 구조를 결정하는 핵심 요소입니다. 고도로 결합된 제품 아키텍처는 복잡한 그래픽 파이프라인 패턴을 생성하여 프로덕션에 도달하기 전에 다양한 파이프라인이 뒤엉킬 수 있습니다.

제품 아키텍처는 파이프라인의 여러 단계와 각 단계에서 만들어지는 아티팩트에도 영향을 미칩니다. 파이프라인은 먼저 배포 가능하고 테스트 가능한 제품 중 가장 작은 단위인 컴포넌트를 빌드합니다. 예를 들어, 파이프라인으로 빌드한 라이브러리를 컴포넌트라고 부를 수 있습니다. 이러한 과정이 컴포넌트 단계입니다.

느슨하게 결합된 컴포넌트는 배포 가능하고 실행 가능한 가장 작은 단위인 하위 시스템을 구성합니다. 예를 들어, 서버는 하위 시스템입니다. 컨테이너에서 실행되는 마이크로서비스도 하위 시스템의 한 예입니다. 이러한 과정이 하위 시스템 단계입니다. 컴포넌트와는 다르게 하위 시스템은 만들어서 테스트할 수 있습니다.

따라서 전체 시스템을 전체적으로 릴리스해야 하는 경우에는 느슨하게 연결된 하위 시스템을 이용해 시스템을 어셈블하도록 파이프라인을 학습시킬 수 있습니다. 이러한 과정이 시스템 단계입니다.

모두 선택하지 않으면 모두 포기하는(all-or-none) 접근 방식은 가장 빠른 하위 시스템이 가장 느린 하위 시스템의 속도를 따르도록 만듭니다. “쇠사슬의 강도는 가장 약한 고리에 달려 있다”는 이러한 아키텍처 패턴에 사로잡혀 있는 팀에 경고할 때 사용하는 말이죠.

검증이 끝나면 어셈블된 시스템은 추가 수정 없이 마지막 단계인 프로덕션으로 승격됩니다.

프로덕션 단계는 물리적이기보다는 논리적인 단계이며, 큰 문제를 여러 개의 작은 하위 문제로 나누기 위해 만들어졌습니다. 아키텍처와 요구 사항에 따라 단계가 더 많거나 적을 수도 있습니다.

품질이 높지 않고 속도만 빠르다면 고객에게 쓸모가 없습니다. 지속적 테스트는 자동화된 테스트를 소프트웨어 제공 파이프라인에 통합하고 파이프라인에서 이루어지는 모든 변경 사항을 검증하는 기술입니다. 파이프라인의 각 단계에서 테스트가 실행되어 해당 단계에서 생성된 아티팩트를 검증합니다. 단위 테스트와 정적 코드 분석은 파이프라인의 컴포넌트 단계에서 컴포넌트를 검증합니다. 기능, 성능, 보안 테스트는 하위 시스템 단계에서 하위 시스템을 검증합니다. 통합, 성능, 보안 테스트는 시스템 단계에서 시스템을 검증합니다. 마지막으로 스모크 테스트는 프로덕션 단계에서 제품을 검증합니다.