CI/CD 파이프라인 이해
지속적 통합, 전달 및 배포 (통칭하여 CI/CD라고 함)에 대해 학습하셨다면 "자동화된 파이프라인"이라는 용어와 이러한 관행을 구현하는 데 중추적인 역할을 한다는 사실을 알게 되셨을 것입니다. 그렇다면 Continuous Integration/Continuous Delivery(CI/CD) 파이프라인이 정확하게 무엇입니까? 그리고 어떻게 구할 수 있나요?
CI/CD의 목적은 품질 저하 없이 사용자에게 소프트웨어를 전달하는 데 걸리는 시간을 줄이는 것입니다. 변경 사항을 자주 확인하고, 엄격하게 테스트하고, 피드백에 신속하게 대응함으로써 목적을 달성할 수 있으며 이에 따라 원하는 만큼 자주 변경 사항을 적용할 수 있습니다.
CI/CD 파이프라인이 무엇인가요?
CI/CD 파이프라인이라고 하면, 개발 머신에서 테스트와 스테이징을 거쳐 최종적으로 출시하여 사용자에게 전달하기 위해 코드가 거치는 일련의 단계를 말합니다.
CI/CD 전략은 이 프로세스를 정기적으로(일반적으로 하루에 여러 번) 실행하는 것이기 때문에 단계 마다 다음 단계를 트리거하거나 문제가 발생한 경우 플래그를 표시하여 가능한 한 많은 프로세스를 자동화하는 것이 중요합니다.
자동화는 전체 프로세스 속도를 높여 개별 피드백 루프를 가속화할 뿐 아니라 각 단계가 일관되고 안정적으로 수행되도록 보장합니다.
빌드 파이프라인 단계
CI/CD 파이프라인의 정확한 형태는 현재 빌드 중인 제품 유형과 조직의 요구 사항에 따라 달라질 것이지만, 여기에 설명된 대로 모든 파이프라인이 따르는 일반적인 패턴이 있습니다.
프로세스는 빌드를 트리거하나 초기 유닛 테스트 세트를 트리거하는 마스터(또는 CI 브랜치로 지정한 브랜치)에 커밋하는 것으로 시작합니다. 결과는 대시보드에 피드백되며 빌드나 테스트가 실패하는 경우 자동 알림으로 플래그가 표시됩니다.
파이프라인을 구성하여 이슈를 해결하고 새 커밋으로 다시 시작할 수 있도록 프로세스를 중지하거나 특정 유형의 장애에 대한 예외를 생성하여 프로세스를 계속할 수 있습니다.
다음 단계는 일련의 자동화된 테스트를 포함하며, 각 테스트 과정을 거친 후 피드백을 제공합니다. 일반적으로, 테스트는 가장 빠른 테스트가 먼저 실행되도록 구조화되어 있기 때문에 가능한 한 빨리 피드백을 제공합니다.
엔드 투 엔드 테스트와 같이 서버를 더 오래 사용할 더 많은 테스트는 이전 테스트가 성공적으로 통과된 후에만 실행됩니다. 이를 통해 리소스를 보다 효율적으로 사용할 수 있습니다.
자동화된 테스트가 완료되면 소프트웨어는 일반적으로 일련의 스테이징 환경에 배포되며, 이중 일부는 추가적인 수동 테스트에 사용될 수 있고 다른 일부는 교육, 지원 및 고객 미리보기에 사용될 수 있습니다.
CI/CD 파이프라인 아키텍처의 마지막 단계에는 변경 사항을 실시간으로 적용하는 과정이 포함되며, 수동(지속적 전달의 경우) 또는 자동(지속적 배포처럼)으로 트리거할 수 있습니다.
각 단계에 대한 몇 가지 고려 사항을 좀 더 자세히 살펴보겠습니다.
플래그 및 브랜치
지속적 통합을 적용하기 위한 첫 번째 단계는 전체 코드 베이스를 Git, Mercurial 또는 Perforce와 같은 버전 관리 시스템(VCS 또는 SCM(소스 제어 관리) 이라고도 함)으로 전환한 다음, 팀의 모든 사용자가 자주 변경 사항을 커밋하도록 하는 것입니다. 마스터에 대한 각 커밋은 파이프 라인을 시작하고 코드를 빌드 및 테스트하여 작성한 내용에 대해 신속한 피드백을 제공합니다.
수시로 하는 커밋이 중요한 CI/CD 파이프라인 작업 방식이지만, 완료하는 데 며칠 또는 몇 주가 걸리는 대규모 기능을 작업하는 경우 해당 프로세스 중에 주기적으로 커밋하는 것이 양날의 칼처럼 느껴질 수 있습니다.
파이프라인을 통해 변경 사항을 점증적으로 푸시하면 피드백을 신속히 받을 수 있고 끝까지 기다릴 때보다 더 복잡한 충돌이 발생할 가능성이 줄어듭니다.
반면, 사용자에게 미완성된 기능을 사용자에게 릴리스하고 싶지 않을 수 있으며 스테이징 환경을 통해 진행 중인 작업을 내부 사용자와 공유할 준비가 되어 있지 않을 수도 있습니다.
기능 플래그와 기능 브랜치는 이 이슈를 해결하는 방법을 제공합니다. 기능 플래그를 사용하여 사용자가 코드를 볼 수 있는 환경을 지정합니다. 변경 사항은 여전히 마스터에 커밋되어 팀일 볼 수 있지만 스테이징 및 프로덕션에서 기능을 사용할 수 있는 시점은 사용자가 결정합니다.
기능 브랜치를 통해 자동화된 빌드 및 테스트의 이점을 활용하면서 별도의 브랜치에서 기능을 개발할 수 있습니다. 마스터에 대한 커밋과 마찬가지로 기능 브랜치에 대한 각 커밋에서 CI/CD 파이프라인을 트리거하면 빌드한 내용에 대한 피드백을 신속히 받을 수 있습니다.
빌드 및 테스트
커밋으로 파이프 라인의 인스턴스를 트리거 한 경우 다음 단계가 빌드 및 테스트입니다. 자동화된 유닛 테스트가 있는 경우 이 테스트는 일반적으로 린팅 및 정적 분석 검사를 사용하여 빌드 전에 실행됩니다.
사용하는 빌드 도구(예: Ant 또는 Maven)와 빌드 단계의 세부 정보는 작업 중인 언어와 프레임워크에 따라 달라집니다. 전용 빌드 서버에서 자동화된 빌드를 실행하면 종속성 누락으로 인한 문제, 즉 전형적인 '내 시스템에서는 작동'한다는 류의 문제를 더욱 철저히 방지할 수 있습니다.
빌드 단계의 출력에는 설치 프로그램, 2진수 또는 컨테이너(빌드 아티팩트)가 포함되어, 테스트 환경에 배포되고 시스템의 다른 부분과 결합되어 보다 높은 수준의 자동화 테스트: 통합 테스트, 구성 요소 테스트, 엔드 투 엔드 테스트 및 비기능 테스트(예: 성능 및 보안 분석)를 실행합니다.
이러한 테스트는 병렬로 실행되어 파이프라인 속도를 높이고 피드백을 더 빠르게 제공할 수 있습니다.
컨테이너 vs VM
자동화된 테스트의 결과가 안정적이려면 테스트 결과가 일관되게 실행되도록 해야 합니다.
이상적으로는 테스트 환경이 프로덕션과 최대한 흡사하도록 구성하고 테스트 결과를 방해하는 환경적 불일치를 방지하기 위해 테스트 실행 간에 재설정해야 합니다.
가상 머신(VM)은 테스트 중인 새 빌드에 대해 새로 고침 프로세스를 스크립팅할 수 있기 때문에 오랫동안 테스트 환경을 실행하는 데 많이 사용되어 왔습니다.
그러나 새 VM을 해체하고 가동하는 데 시간이 걸리는 반면, 소프트웨어를 실행하는 데 필요한 모든 종속성을 제공하기 위해 각 가상 환경에 대한 구성을 스크립트에 포함해야 합니다. 새 종속성이 추가되면 환경 스크립트를 업데이트해야 합니다. 세부 정보를 쉽게 놓칠 수 있어 왜 빌드가 실행되지 않는지 의아할 수 있기 때문입니다.
초기 빌드 단계의 일부로 코드를 컨테이너에 패키징하여 이러한 문제를 방지할 수 있습니다. 컨테이너에는 소프트웨어를 실행해야 하는 모든 종속성이 포함되어 있어 이동성이 뛰어나고 다양한 환경에 쉽게 배포할 수 있습니다.
자체 인프라에서 CI/CD를 호스팅하는 경우에도 컨테이너를 배포하는 데 VM이 필요하지만 테스트 환경을 준비하는 데 필요한 작업이 줄어들어 파이프라인이 효율적으로 운영되도록 하는 데 도움이 됩니다. 클라우드에서 파이프라인을 실행하는 경우 컨테이너를 채택하면 관리형 서비스를 이용하고 인프라 측면을 클라우드 제공업체에 오프로드할 수 있습니다.
사전 프로덕션 환경
파이프라인 아키텍처의 테스트 및 스테이징 환경 수는 무엇을 빌드하고 있는지와 조직 내 다양한 이해 관계자 그룹의 요구사항에 따라 달라집니다. 예를 들어 탐색 테스트, 보안 검토, 사용자 조사, 영업 데모, 교육 환경 및 지원 담당자가 고객 문제를 복제할 수 있는 샌드박스 등이 있습니다.
이러한 환경의 생성 및 배포를 자동화하는 것이 수동으로 새로 고침하는 것보다 효율적이며 환경에 따라 서로 다른 파이프라인 트리거를 구성할 수 있습니다.
예를 들어 테스트 환경이 모든 빌드로 업데이트될 수 있지만 스테이징 환경을 덜 자주 새로 고침하도록 결정할 수 있습니다(예: 최근 성공한 빌드로 하루에 1회 또는 일주일에 1회).
배포
코드 변경 사항이 이전의 각 파이프라인 단계를 성공적으로 통과하면 프로덕션에 릴리스할 준비가 된 것 입니다. 마지막 단계는 수동 또는 자동일 수 있습니다.
수동 릴리스(지속적 전달이라고 함)는 새 기능 또는 기능성을 사용할 수 있도록 하는 시기를 통제하려는 경우, 배포 프로세스에서 사용자의 다운타임이 발생하는 경우 또는 제품이 설치되고 변경 사항을 일괄 처리하여 정기 릴리스 일정에 따라 제공하려는 경우에 유용합니다.
완전히 자동화된 지속적 배포 프로세스를 통해 모든 이전 단계를 통과한 만큼 오랫동안 변경 사항을 적용할 수 있습니다.
코드 베이스에서 작업하는 개발자 수 및 커밋 빈도에 따라 하루에 수십 번 사용자에게 업데이트를 배포하는 것을 의미할 수 있습니다. 자동화된 파이프라인 없이는 사실상 불가능합니다.
CI/CD 파이프라인 이해: 요약
CI/CD는 가능한 한 빨리 이슈를 강조 표시하여 소프트웨어 개발 효율성을 높입니다. 즉, 상호 작용을 앞당기고 피드백을 더 빨리 받음으로써 빠르게 페일하도록 도와줍니다(즉, Shifting Left: 보안 조기 도입). 자동화된 파이프라인을 구축하면 이러한 기술을 활용할 수 있습니다.
CI/CD 프로세스를 직접 설계할 때는 지속적 통합부터 시작하여 단계별로 빌드하는 것이 도움이 됩니다. 파이프라인의 정확한 단계와 각 단계가 트리거되는 시기를 결정하는 로직은 사용자의 제품과 조직에 따라 다릅니다.
요구사항에 맞게 파이프라인을 구성할 수 있는 유연성을 제공하는 동시에 관리가 용이한 CI/CD 플랫폼을 선택하면 안정적인 릴리스 프로세스를 구축하고 소프트웨어 품질을 개선할 수 있습니다.