지속적 제공 파이프라인의 기초

진부하게 들릴 수 있지만 “인간은 실수를 범한다”라는 말은 여전히 사실로 남아 있습니다. 수동 릴리스는 프로세스가 불안정하므로 팀은 충격에 대비하고 있습니다. 예측 가능성은 릴리스가 지속적 제공 파이프라인을 통해 수행될 때 본질적으로 결정론적이라는 것을 의미입니다. 파이프라인은 프로그래밍 가능한 인프라이므로 팀은 항상 원하는 행동을 예상할 수 있습니다. 물론 버그가 없는 소프트웨어는 없기 때문에 사고는 일어날 수 있습니다. 그러나 파이프라인은 오류가 발생하기 쉬운 수동 릴리스 프로세스보다 훨씬 더 효과적입니다. 인간과 달리 파이프라인은 촉박한 기한에도 안정적으로 유지되기 때문입니다.

파이프라인에는 버전이 지정된 아티팩트의 통과를 자동으로 승격하거나 거부하는 소프트웨어 게이트가 있습니다. 릴리스 프로토콜을 준수하지 않으면 소프트웨어 게이트가 닫힌 상태로 유지되고 파이프라인 중단됩니다. 알림이 생성되고 파이프라인에 고장을 일으켰을 가능성이 있는 팀원으로 구성된 배포 목록에 알림이 전송됩니다.

바로 이러한 방식으로 CD 파이프라인이 작동합니다. 커밋 또는 소규모 증분 배치 커밋은 파이프라인이 성공적으로 실행될 때마다 프로덕션 환경으로 이동합니다. 따라서 팀은 기능과 궁극적으로는 제품을 안전하고 감사 가능한 방식으로 제공하게 됩니다.

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

제품 아키텍처는 파이프라인의 여러 단계와 각 단계에서 만들어지는 아티팩트에도 영향을 미칩니다. 지속적 제공의 네 가지 일반적인 단계를 논의하겠습니다.

1. 컴포넌트 단계
2. 하위 시스템 단계
3. 시스템 단계
4. 프로덕션 단계

조직에서 단계가 4개 이상 또는 4개 미만이 될 것으로 예상되더라도 아래에 설명된 개념은 여전히 적용됩니다.

흔한 오해는 이 단계가 파이프라인에 물리적으로 나타난다는 것입니다. 꼭 그렇지는 않습니다. 논리적인 단계이며 테스트, 스테이징, 프로덕션과 같은 환경적 마일스톤도 연계될 수 있습니다. 예를 들어 테스트에서 컴포넌트와 하위 시스템을 구축, 테스트 및 배포할 수 있습니다. 하위 시스템이나 시스템은 스테이징에서 구성, 테스트 및 배포할 수 있습니다. 프로덕션 단계의 일부로 하위 시스템이나 시스템을 프로덕션 환경으로 승격할 수 있습니다.

결함으로 인한 비용은 테스트 단계에서 발견되면 낮고 스테이징 단계에서 발견되면 중간이며 프로덕션 단계에서 발견되면 높습니다. “조기 단계에서 개입”이란 파이프라인 초기에 유효성 검사를 실시하는 것을 의미합니다. 요즘에는 테스트에서 스테이징으로 가는 게이트에는 훨씬 더 효과적인 방어 기술이 내장되어 있으므로 스테이징이 더 이상 범죄 현장처럼 보일 필요가 없습니다.

역사적으로 InfoSec은 거부된 릴리스가 회사에 사이버 보안 위협이 될 수 있는 소프트웨어 개발 수명 주기 막바지에 개입했습니다. 의도는 좋지만 좌절과 지연을 야기했습니다. “DevSecOps”는 평가를 위해 (안전하지 않을 수도 있는) 완제품을 보내는 대신 설계 단계부터 제품에 보안을 내장해야 한다고 주장합니다.

지속적 제공 워크플로에서 “조기 단계에서 개입”과 “DevSecOps”를 어떻게 실행할 수 있는지에 대해 더 자세히 살펴보겠습니다. 다음 섹션에서는 각 단계에 대해 자세히 설명합니다.

파이프라인은 먼저 배포 가능하고 테스트 가능한 제품 중 가장 작은 단위인 컴포넌트를 빌드합니다. 예를 들어, 파이프라인으로 빌드한 라이브러리를 컴포넌트라고 부를 수 있습니다. 무엇보다도 코드 검토, 단위 테스트 및 정적 코드 분석기를 통해 컴포넌트를 인증할 수 있습니다.

코드 검토는 팀이 제품 구현에 필요한 기능, 테스트 및 인프라를 공유하는 데 중요합니다. 다른 개발자의 검토는 종종 놀라운 일을 할 수 있습니다. 시간이 지나면 더 이상 잘못된 코드라고 여기지 않을 정도로 잘못된 코드에 영향을 받지 않게 될 수도 있습니다. 신선한 관점은 이러한 약점을 다시 살펴보고 필요할 때마다 관대하게 리팩토링하도록 합니다.

단위 테스트는 거의 대부분의 경우 코드에서 실행하는 첫 번째 소프트웨어 테스트 집합입니다. 단위 테스트는 데이터베이스나 네트워크를 다루지 않습니다. 코드 커버리지는 단위 테스트에서 다룬 코드의 비율입니다. 커버리지를 측정하는 방법에는 줄 커버리지, 클래스 커버리지, 메서드 커버리지 등과 같이 여러 가지가 있습니다.

코드 커버리지가 좋으면 리팩토링이 쉬워지는 것도 좋지만 높은 커버리지 목표를 요구하는 것은 해롭다. 직관적인 느낌과 반대되지만 코드 커버리지가 높은 팀 중에서도 코드 커버리지가 낮은 팀보다 프로덕션 중단이 더 많은 경우가 있습니다. 또한 커버리지 숫자를 조작하는 건 쉽다는 것을 명심하세요. 심한 압박을 받는 경우, 특히 성능 검토 중에는 개발자가 부당한 관행으로 돌아가 코드 커버리지를 늘릴 수 있습니다. 자세한 내용은 여기서 다루지 않겠습니다.

정적 코드 분석은 코드를 실행하지 않고도 코드의 문제를 감지합니다. 문제를 감지하는 저렴한 방법입니다. 이 테스트는 단위 테스트처럼 소스 코드에서 실행되고 실행 시간이 짧습니다. 정적 분석기는 순환 복잡도나 코드 중복과 같은 코드 품질 지표와 함께 잠재적인 메모리 누수를 감지합니다. 이 단계에서 보안 취약성을 발견하는 데 검증된 방법은 정적 분석 보안 테스트(SAST)입니다.

컴포넌트 단계부터 하위 시스템 단계까지 소프트웨어 게이트를 제어하고 코드 승격에 영향을 미치는 메트릭을 정의하세요.

느슨하게 결합된 컴포넌트는 배포 가능하고 실행 가능한 가장 작은 단위인 하위 시스템을 구성합니다. 예를 들어 서버는 하위 시스템입니다. 컨테이너에서 실행되는 마이크로서비스도 하위 시스템의 한 예입니다. 컴포넌트와는 반대로 하위 시스템을 만들어 고객 사용 사례에 따라 검증할 수 있습니다.

Node.js UI와 Java API 계층이 하위 시스템인 것처럼 데이터베이스도 하위 시스템입니다. 데이터베이스 변경 관리를 자동화하고 데이터베이스의 지속적 제공을 수행하는 차세대 도구가 등장했음에도 불구하고 일부 조직에서는 RDBMS(관계형 데이터베이스 관리 시스템)를 수동으로 처리합니다. NoSQL 데이터베이스를 포함하는 CD 파이프라인은 RDBMS보다 구현하기가 더 쉽습니다.

하위 시스템은 기능, 성능, 보안 테스트를 통해 배포하고 인증할 수 있습니다. 각 테스트 유형이 제품을 어떻게 검증하는지 연구해 보겠습니다.

기능 테스트에는 국제화(I18N), 현지화(L10N), 데이터 품질, 접근성, 부정적인 시나리오 등과 관련된 모든 고객 사용 사례가 포함됩니다. 이 테스트를 통해 제품이 고객의 기대에 부합하고 포용성을 존중하며 대상으로 하는 시장에 적합한지 확인할 수 있습니다.

제품 소유자와 함께 성능 벤치마크를 결정하세요. 성능 테스트를 파이프라인과 통합하고 벤치마크를 사용하여 파이프라인에 통과 또는 실패 판정을 하세요. 흔히 성능 테스트를 지속적 제공 파이프라인과 통합할 필요가 없다는 것이 일반적인 오해지만 그러면 지속적 패러다임을 깨뜨립니다.

최근에 대규모 조직에서 침해가 발생했으며 사이버 보안 위협이 최고조에 달해 있습니다. 우리가 작성하는 코드이든 코드로 가져오는 타사 라이브러리든 제품에 보안 취약성이 없는지 확인해야 합니다. 실제로 OSS(오픈 소스 소프트웨어)에서 중대한 침해가 발견되었으며 이 오류에 플래그를 지정하고 파이프라인을 강제로 중단시키는 도구와 기술을 사용해야 합니다. 보안 취약성을 발견하는 검증된 방법은 DAST(동적 분석 보안 테스트)입니다.

다음 그림은 컴포넌트 및 하위 시스템 단계에서 설명한 워크플로를 설명합니다. 독립적인 단계를 병렬로 실행해서 총 파이프라인 실행 시간을 최적화하고 빠른 피드백을 받아보세요.

하위 시스템이 기능, 성능, 보안 기대치를 충족하면 시스템을 전체적으로 릴리스할 때 느슨하게 연결된 하위 시스템으로 시스템을 어셈블하도록 파이프라인을 학습시킬 수 있습니다. 그러면 가장 빠른 팀의 속도가 가장 느린 팀과 같아질 수 있습니다. “쇠사슬의 강도는 가장 약한 고리에 달려 있다”라는 옛말이 떠오릅니다.

하위 시스템을 전체적으로 릴리스할 하나의 시스템으로 구성하는 구성 안티패턴은 권장하지 않습니다. 이 안티패턴은 성공을 위해 모든 하위 시스템을 연결합니다. 독립적으로 배포할 수 있는 아티팩트에 투자하면 이런 안티패턴을 피할 수 있습니다.

시스템을 전체적으로 검증해야 하는 경우 통합, 성능 및 보안 테스트로 인증할 수 있습니다. 하위 시스템 단계와 달리 이 단계에서는 테스트 시 모의 개체나 스텁을 사용하면 안 됩니다. 또한 무엇보다도 인터페이스와 네트워크 테스트에 집중하는 것이 중요합니다.

다음 그림은 구성을 사용하여 하위 시스템을 어셈블해야 하는 경우의 시스템 단계 워크플로를 요약한 것입니다. 하위 시스템을 프로덕션으로 이동시킬 수 있더라도 다음 그림은 코드를 이 단계에서 다음 단계로 승격하는 데 필요한 소프트웨어 게이트를 설정할 수 있습니다.

파이프라인은 자동으로 변경 요청(CR)을 제출하여 감사 추적을 남길 수 있습니다. 대부분의 조직에서는 표준 변경, 즉 예정된 릴리스에 이 워크플로를 사용합니다. 이 워크플로는 긴급 변경이나 계획되지 않은 릴리스에도 사용해야 하지만 일부 팀에서는 건너뛰는 경향이 있습니다. 오류로 인해 요청이 중단되면 CD 파이프라인에 의해 변경 요청이 자동으로 닫힌다는 데 주목하세요. 이렇게 하면 파이프라인 워크플로 도중에 변경 요청이 취소되는 것을 방지할 수 있습니다.

다음 그림은 CD 시스템 단계에서 다룬 워크플로를 명확히 설명합니다. 일부 단계에는 인간의 개입이 필요할 수 있으며 수동 단계는 파이프라인 수동 게이트의 일부로 실행될 수 있다는 점을 기억하세요. 완전히 매핑하면 파이프라인 시각화가 제품 릴리스의 가치 스트림 맵과 아주 비슷해집니다.

어셈블한 시스템이 인증되면 어셈블리는 그대로 두고 프로덕션으로 승격하세요.

하위 시스템을 독립적으로 배포하거나 시스템에 조립할 수 있는지 여부와 관계없이 버전이 지정된 아티팩트는 마지막 단계의 일부로 프로덕션에 배포됩니다.

가동 중지 시간 없는 배포(ZDD)는 고객의 가동 중지 시간을 방지하므로 테스트부터 스테이징, 프로덕션까지 실행해야 합니다. 블루-그린 배포는 널리 사용되는 ZDD 기법으로 새 비트는 인구의 아주 작은 부분(“그린”이라고 함)에 배포하는 반면 대부분은 이전 비트가 있는 “블루”를 전혀 인식하지 못합니다. 푸시가 밀려나는 경우 모두를 다시 “블루”로 되돌리면 영향을 받는 고객은 거의 없을 것입니다. “그린”에서 괜찮아 보이면 모두를 “블루”에서 “그린”으로 천천히 다이얼합니다.

하지만 어떤 조직에서는 수동 게이트가 잘못 사용되는 경우가 보입니다. 변경 승인 위원회(CAB) 회의에서 팀이 수동 승인을 받아야 합니다. 그 이유는 업무 분리나 관심사 분리에 대한 오해 때문인 경우가 많습니다. 진행을 위한 승인을 얻고자 한 부서에서 다른 부서에 일을 넘깁니다. 또한 일부 CAB 승인자는 운영 과정에서 발생하는 변경 사항에 대한 기술적 이해가 얕아서 수동 승인 프로세스를 느리고 지루하게 만드는 경우도 보았습니다.

지속적 제공과 지속적 배포의 차이를 설명하기에 좋은 방법입니다. 지속적 제공은 수동 게이트를 허용하지만 지속적 배포는 그렇지 않습니다. 둘 다 CD라고 하는데 지속적 배포는 파이프라인에 인간의 개입이 없기 때문에 더 많은 규율과 엄격함이 필요합니다.

비트를 옮기는 것과 활성화하는 것 사이에는 차이가 있습니다. 프로덕션 환경에서 통합, 성능, 보안 테스트 도구 모음의 하위 집합인 스모크 테스트를 실행하세요. 스모크 테스트가 통과하면 비트가 활성화되고 제품이 고객에게 구현됩니다.

다음 다이어그램은 지속적 제공의 마지막 단계에서 팀이 수행하는 단계를 보여줍니다.

성공적인 지속적 제공이나 지속적 배포를 위해서는 지속적 통합과 지속적 테스트를 올바르게 하는 것이 중요합니다. 탄탄한 기반이 있으면 품질, 빈도, 예측 가능성이라는 세 가지 측면에서 모두 성공할 수 있습니다.

지속적 제공 파이프라인은 일련의 지속 가능한 실험을 통해 아이디어를 제품으로 만들 수 있습니다. 아이디어가 생각보다 별로라는 사실을 발견하면 더 좋은 아이디어로 빠르게 변경할 수 있습니다. 또한 파이프라인은 MTTR(평균 해결 시간) 프로덕션 문제를 줄여 고객의 가동 중지 시간을 단축해 줍니다. 지속적 제공을 통해 생산적인 팀과 고객 만족을 얻게 되며 싫어할 사용자는 없을 것입니다.

지속적 제공 자습서에서 자세히 알아보세요.