CI/CD (지속적 통합/지속적 제공)
쉽게 설명하자면, CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다. 이러한 CI/CD의 기본 개념은 다음과 같이 세 가지로 구분할 수 있다.
- 지속적 통합 (Continuous Integration)
- 지속적 전달 또는 제공 (Continuous Delivery)
- 지속적 배포 (Continuous Deployment)
개발/운영 조직에서는 새로운 코드 통합으로 인해 발생할 수 있는 문제(일명: Integration Hell)를 해결하기 위한 솔루션으로 CI/CD 환경을 구성한다. 또한, 애플리케이션 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션 라이프사이클 전체에 걸쳐 지속적인 자동화 및 모니터링을 제공한다.
이러한 구축 사례를 일반적으로 "CI/CD Pipeline"이라 부른다.
통합 지옥 (Integration Hell)
"통합 지옥"은 개발/운영 조직에서 코드 통합(Merge) 과정에서 발생하는 여러가지 문제들을 말한다.
일반적으로 통합 프로세스가 매끄럽지 않은 기존의 소프트웨어 개발 환경에서는 통합을 위한 작업으로 수 시간(또는 수 일)이 소요되기도 하며, 최악의 경우 수행한 작업에 대한 롤백(Rollback)을 수행한다.
일반적으로 "작업 단위가 클수록, 반영주기가 길어질수록" 발생 가능성이 높다.
CI/CD 파이프라인
CI/CD 파이프라인은 새 버전의 소프트웨어를 제공하기 위해 수행해야 할 일련의 단계이다.
일반적인 파이프라인 단계는 다음과 같다.
-
빌드(Build)
: 애플리케이션을 컴파일하는 단계 -
테스트(Test)
: 코드를 테스트하는 단계. 이 단계를 자동화하여 시간과 수고를 줄일 수 있다. -
릴리스(Release)
: 애플리케이션을 리포지토리에 제공하는 단계 -
배포(Deploy)
: 코드를 프로덕션에 배포하는 단계 -
검증 및 컴플라이언스(Validation & compliance)
: 빌드 검증 단계는 해당 조직의 필요에 따라 결정된다. Clair와 같은 이미지 보안 스캔 툴을 사용하여 알려진 취약점(CVE)과 비교하는 방법으로 이미지의 품질을 보장할 수 있다.
CI 와 CD 차이점
- 지속적 통합 (CI, Continuous Integration)
지속적 통합(Continuous Integration)은 개발자들의 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 수행할 수 있도록 한다.
개발자가 애플리케이션에 적용한 변경 사항에 대해 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축(Build)하고 각기 다른 레벨의 자동화 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다. 만약, 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 없다면 병합(Merge)한다.
CI(지속적 통합) 과정을 통해 소스코드는 항상 "빌드 가능한 상태"가 되고, 양질의 코드 퀄리티를 유지하는 등 개발 조직의 업무 생산성 및 효율성을 높일 수 있다.
CD는 지속적 제공(Continuous Delivery)과 지속적 배포(Continuous Deployment)를 모두 의미한다.
CD(지속적 제공 및 배포)에서는 개발에서 배포까지의 과정이 간소화되어 사용자 피드백을 빠르게 반영할 수 있으며, 크리티컬한 이슈가 발생하는 등의 장애 대응 관점에서도 빠른 대응이 가능하다.
- 지속적 제공 (CI, Continuous Delivery)
지속적 제공(Continuous Delivery) 단계에서는 CI 과정 이후의 유효성 검증이 끝난 코드를 리포지토리에 릴리즈 자동화 작업을 수행한다.
CD(지속적 제공) 과정을 통해 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있도록 도와준다.
- 지속적 배포 (CI, Continuous Deployment)
지속적 배포(Continuous Deployment)는 지속적 제공(Continuous Delivery)의 확장된 형태로, 고객이 사용 가능한 프로덕션 레벨로 릴리스 자동화 작업을 수행한다.
