CI/CD 파이프라인이라고 하면, 개발 환경의 코드가 테스트, 스테이징, 그리고 최종적으로 사용자에게 전달되는 다양한 단계를 거치는 프로세스를 말합니다.

CI/CD의 목적은 이 프로세스를 정기적으로(하루 혹은 한 시간에 여러 번) 실행하는 것이므로, CI/CD 파이프라인을 최대한 자동화하는 것이 필수적입니다. 한 단계가 성공적으로 완료되면 다음 단계가 자동으로 트리거되어야 합니다. 어떤 단계가 실패하면 문제 해결을 위해 피드백이 빠르게 전달되어야 합니다.

CI/CD 파이프라인을 자동화하면 전반적인 빌드, 테스트 및 소프트웨어 배포 과정이 빨라질 뿐만 아니라 각 단계의 일관성 및 안정성을 확보할 수 있습니다.

지속적 통합을 적용하기 위한 첫 번째 단계는 전체 코드 베이스를 Git, Mercurial 또는 Perforce와 같은 버전 관리 시스템(VCS 또는 SCM(소스 제어 관리)이라고도 함)으로 전환한 다음, 팀의 모든 사용자가 변경 사항을 자주 커밋하도록 하는 것입니다. 메인 브랜치에 커밋할 때마다 지속적 통합 파이프라인이 시작되며, 코드 빌드 및 테스트가 실행되어 최신 변경 사항에 대한 신속한 피드백이 제공됩니다.

잦은 커밋은 CI/CD 파이프라인에서 중요한 작업이지만, 완료하는 데 며칠 또는 몇 주가 걸리는 대규모 기능을 작업하는 경우, 작업 중에 주기적으로 커밋하는 것이 비생산적으로 느껴질 수 있습니다.

그러나 일정한 분량의 변경 사항을 파이프라인으로 푸시하면 피드백을 빠르게 받을 수 있습니다. 또한, 기능이 완성될 때까지 기다리는 것보다 복잡한 병합 충돌이 발생할 가능성이 줄어듭니다.

한편, 완성되지 않은 기능을 파이프라인으로 푸시하는 것이 바람직하지 않을 때도 있습니다. 스테이징 환경이라 하더라도 완성되지 않은 작업을 사용자와 공유하는 것은 좋지 않을 수 있습니다.

피처 플래그와 피처 브랜치는 이러한 문제를 해결할 수 있는 방법을 제공합니다. 피처 플래그를 사용하여 사용자에게 코드를 보여줄 환경을 지정하세요. 내가 적용한 변경 사항은 여전히 메인 브랜치에 커밋되어 팀에게 표시되지만, 스테이징 및 프로덕션에서 기능을 보여줄 시점은 직접 정할 수 있습니다.

피처 브랜치를 통해 자동화된 빌드 및 테스트의 이점을 활용하면서 별도의 브랜치에서 기능을 개발할 수 있습니다. 메인 브랜치에 커밋할 때와 마찬가지로 피처 브랜치에 커밋할 때마다 CI/CD 파이프라인이 트리거되어 빌드에 대한 피드백을 신속히 받을 수 있습니다.

자동화된 테스트의 결과가 안정적이려면 테스트 결과가 일관되게 실행되도록 해야 합니다.

이상적으로는 테스트 환경이 프로덕션 환경과 최대한 흡사하도록 구성하고 테스트 결과를 방해하는 환경적 불일치를 방지하기 위해 테스트 실행 간에 환경을 재설정해야 합니다.

가상 머신(VM)은 새 빌드를 테스트할 때마다 테스트 환경을 새로 고치는 프로세스를 스크립트로 처리할 수 있기 때문에 오랫동안 테스트 환경 실행에서 애용되어 왔습니다.

그러나 새 VM을 해체하고 가동하는 데 시간이 걸릴 뿐만 아니라, 소프트웨어를 실행하는 데 필요한 모든 종속성을 제공하려면 각 가상 환경에 대한 구성을 스크립트에 포함해야 합니다. 새 종속성이 추가되면 환경 스크립트를 업데이트해야 합니다. 이는 빌드가 실행되지 않는 이유에 의문이 들 때 비로소 알아차리게 되는 놓치기 쉬운 작업입니다.

초기 빌드 단계의 일부로 코드를 컨테이너에 패키징하여 이러한 문제를 방지할 수 있습니다. 컨테이너에는 소프트웨어를 실행해야 하는 모든 종속성이 포함되어 있어 이동성이 뛰어나고 다양한 환경에 쉽게 배포할 수 있습니다.

자체 인프라에서 CI/CD 파이프라인을 호스팅하는 경우, 컨테이너를 배포하려면 VM이 여전히 필요하지만 테스트 환경을 준비하는 데 필요한 작업은 줄어듭니다. 클라우드에서 파이프라인을 실행하는 경우, 컨테이너를 사용하면 관리형 서비스를 활용해 인프라 관리를 클라우드 제공업체에 맡길 수 있습니다.

파이프라인 아키텍처의 테스트 및 스테이징 환경 수는 무엇을 빌드하고 있는지와 조직 내 다양한 이해 관계자 그룹의 요구사항에 따라 달라집니다. 예를 들어 탐색 테스트, 보안 검토, 사용자 조사, 영업 데모, 교육 환경 및 지원 담당자가 고객 문제를 복제할 수 있는 샌드박스 등이 있습니다.

이러한 환경의 생성과 배포를 자동화하면 수동으로 새로 고치는 것보다 훨씬 효율적입니다. 환경마다 서로 다른 파이프라인 트리거를 구성할 수도 있습니다.

예를 들어 테스트 환경은 빌드할 때마다 업데이트하고, 스테이징 환경은 적은 빈도로 새로 고치도록 지정할 수 있습니다(예: 최근 성공한 빌드로 하루에 1회 또는 일주일에 1회).

코드 변경 사항이 이전의 각 파이프라인 단계를 성공적으로 통과하면 프로덕션에 릴리스할 준비가 된 것입니다. 마지막 단계는 수동 또는 자동일 수 있습니다.

다음과 같은 경우에는 수동 릴리스(지속적인 전달)가 유용합니다.

• 새로운 기능이 공개되는 시점을 통제하고 싶은 경우.
• 배포 프로세스 중에 사용자에게 중단 시간이 발생하는 경우.
• 사용자가 제품을 설치해야 하며 정기적인 릴리스 일정에 따라 전달할 변경 사항을 배치로 모으려는 경우.

지속적 배포에서는 릴리스가 자동으로 진행됩니다. 변경 사항이 이전의 모든 단계를 통과했다는 가정하에 라이브 환경으로 배포됩니다. 이는 자주 커밋하는 대형 팀의 경우 하루에도 수십 번 사용자에게 배포해야 할 수도 있다는 의미이며, 자동화된 파이프라인이 없다면 사실상 불가능합니다.

CI/CD란 DevOps 작업의 하나로, 자동화를 활용하여 소프트웨어 개발 주기의 각 단계에 관한 피드백을 빠르게 제공합니다. 최근에 변경된 코드로 인해 발생한 문제를 찾아내어 소프트웨어 개발이 효율화됩니다. 시프트 레프트(상호 작용을 앞당기고 피드백을 빠르게 전달)를 통해 실패하더라도 더 이르게 하고, 자동화된 파이프라인을 만들어서 이러한 테크닉을 작업에 적용할 수 있습니다.

CI/CD 프로세스를 직접 설계할 때는 지속적 통합부터 시작하여 단계별로 구축하는 것이 좋습니다. 파이프라인의 정확한 단계와 각 단계가 트리거되는 시기를 결정하는 로직은 사용자의 제품과 조직에 따라 다릅니다.

고유한 요구 사항에 맞게 파이프라인을 구성할 수 있는 유연성을 제공하는 동시에 관리가 용이한 CI/CD 플랫폼을 선택하면 안정적인 릴리스 프로세스를 구축하고 소프트웨어 품질을 개선할 수 있습니다.

TeamCity Pipelines 솔루션을 이용하면 기존의 CI/CD 프로세스를 자동화할 수 있습니다.

TeamCity Pipelines는 주요 버전 관리 시스템을 모두 지원하고 인기 빌드, 테스트 및 패키지 관리 도구와도 통합되어, 개발 워크플로를 효율적이며 자동화된 파이프라인으로 바꿀 수 있습니다.

유연한 트리거 옵션과 시각적인 파이프라인 에디터로 손쉽게 모든 워크플로의 파이프라인을 구성할 수 있습니다. 구성은 코드로 자동 저장되어 코드형 구성의 장점뿐만 아니라 GUI에서 파이프라인을 빌드하고 관리하는 자유까지 누릴 수 있습니다.

TeamCity는 온프레미스 및 클라우드 기반 배포 옵션으로 제공되므로 유연하게 원하는 곳에서 파이프라인을 실행하고 수요에 맞춰 확장할 수 있습니다. 테스트 병렬화와 실시간 피드백과 같은 기능을 활용하면 실패를 더 빨리 탐지할 수 있어 개발 생산성이 향상됩니다.