CI/CD(Continous Integration/Continuous Delivery)란

서론

UMC 서버 컨퍼런스에 다녀왔다. 현직 Devops 개발자 연사님의 발표를 들었는데, 새로 접한 기술과 지식이 많아서 정리 해보고자 한다. 

그 중 제일 먼저 정리해볼 것은 CI/CD 파이프라인이다. 

 

CI/CD란?

CI/CD(Continous Integration/Continuous Delivery)는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법이다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포이다. 

CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "통합 지옥(integration hell)")를 해결하기 위한 솔루션이다. 

 

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공한다. 이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부러며, 개발 및 운영팀의 애자일 방식 협력으 통해 DevOps 또는 SRE(사이트 신뢰성 엔지니어링) 방식으로 지원된다. 

 

사용자에게 코드를 보여주는 과정은 크게 3가지로 정리할 수 있다. 

1. 컴파일 : 우리가 만든 코드를 컴파일 한다(프로그래밍 언어 -> 기계어)
2. 빌드 : 컴파일된 기계어를 사용자에게 보여주기 위해 빌드하여 완성된 상품, 소프트웨어 가공물로 만든다
3. 배포 :이렇게 만들어진 산출물을 각각의 서버에서 동작하도록 하여 상품을 사용자들에게 공개하는 것. 

 

CI/CD를 사용해야 하는 이유

사용자에게 우리가 만들어낸 프로젝트를 배포했는데, 어떠한 동작이 올바르게 동작하지 않아 문제가 발생했다고 가정해보자. 

개발자들은 문제를 수정해야 하고, 수정을 했으면 다시 컴파일, 빌드, 배포하는 과정을 통해 수정된 코드가 제대로 동작하는지 테스트하고 검증할 필요가 있다. 

이 과정들은 시간도 많이 걸리고 실수하기도 쉽다. 

이를 위해서  CI/CD가 생겨났다. 

 

CI/CD(Continous Integration/Continous Delivery) 차이

CI/CD는 지속적 통합/지속적 배포를 뜻한다. 

CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continous Integration)을 의미한다. 

지속적인 통합이 제대로 구현되면, 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합된다. 

따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우, 서로 충돌하는 문제를 이 방법으로 해결할 수 있다. 

 

CI/CD의 "CD"는 지속적인 서비스 제공(Continous Delivery) 및 지속적인 배포(Continous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용된다. 

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만, 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다. 

 

지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(ex : github 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있게 해준다. 이는 개발팀과 비즈니스팀 간의 가시성 및 커뮤니케이션 부족 문제를 해결해준다. 

그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다. 

 

지속적인 배포(또 다른 의미의 "CD" : Continous Deployment)란 개발자의 변경사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리즈하는 것을 의미한다. 

이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다. 

지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 서비스 제공의 장점을 활용한다. 

 

CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다. 좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다. 

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미한다. 

 

지속적 통합(Continous Integration, CI)

애플리케이션 개발에서, 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 한다. 

그러나 조직에서 특정한 "병합의 날(merge day)"을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 된다. 

이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 때문이다. 

CI(지속적 통합)를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 과정을 더욱 수월하게 자주 수행할 수 있다. 

1. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고,
2. 각기 다른 레벨의 자동화된 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다.
    

다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행한다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있다. 

 

CI가 나오기 전까지는 개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지를 검증하며 코드 품질을 관리할 수 있었다. 

 

CI를 적용하게 되면 각자의 개발자가 자신의 구현해야 할 기능을 구현하면 된다. 이후 완성이 되면 main 브랜치와 통합하고 코드가 잘 빌드되는지 보고, 올바르게 동작하는지 테스트하며 코드에 버그가 있다면 해결한다. 

 

하지만 개발자가 직접 코드를 병합하고 빌드, 테스트를 검증하는 것은 시간이 많이 소요될 뿐만 아니라 귀찮고, 그 양도 프로젝트의 크기가 커질수록 많아질 수밖에 없다. 

 

이를 자동화하면 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있다. 

 

개발자가 단위별로 구현한 부분을 병합할 때마다 자동화된 빌드와 테스트가 트리거되어 실행된다. 결과를 통해 우리는 어떤 부분에서 문제가 있는지 배포 전에 확인할 수 있고, 배포가 완성된 후에야 버그를 수정할 수 있던 기존의 문제를 빠르고 정확하게 해결할 수 있다. 

 

결과적으로 버그를 신속하게 찾아 해결할 수 있을 뿐 아니라, 소프트웨어 품질을 개선하고 새로운 소프트웨어 업데이트를 검증하고 릴리즈하는데에 걸리는 시간을 단축할 수도 있다. 

 

요약하자면 CI의 간단한 순서는 아래와 같다. 

1. 개발자가 구현한 코드를 기존 코드와 병합한다. 
2. 병합된 코드가 올바르게 동작하고 빌드되는지 검증한다. 
3. 테스트 결과 문제가 있다면 수정하고 1로 돌아간다. 문제가 없다면 배포를 진행한다. 

 

지속적 제공(Continuous Delivery, CD)

이제 지속적 통합을 거친 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다. 

 

CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후, 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스한다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 한다. 

지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것이다. 

 

지속적 제공의 경우, 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리즈 자동화가 포함된다. 이 프로세스를 완료하면 운영팀이 더욱 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다. 

 

즉, 지속적 제공은 CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github과 같은 저장소에 업로드하는 것을 의미한다. 

 

지속적 배포(Continuous Deployment, CD)

CI/CD 파이프라인의 마지막 단계는 지속적 배포이다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화한다. 

프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 한다. 

 

실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 위미한다.(자동화된 테스트를 통과한 것으로 간주) 

이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해진다. 

 

이렇게 성공적으로 병합된 내역을 저장소뿐만 아니라 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미한다. 

지속적 배포에서는 지속적 통합을 통해 빌드한 소스코드를 테스트 가능한 알파나 베타 버전으로 만든다. 이 버전에서 테스트를 수행해 문제가 발생하면 수정한 뒤 정식 버전으로 배포를 진행한다. 

이러한 모든 CI/CD 적용 사례는 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요하다. 

 

 

CI/CD 툴 및 구축

CI/CD 툴은 팀이 개발, 배포, 테스트를 자동화하도록 지원한다. 특히 통합(CI)  측면을 다루는 툴도 있고, 개발 및 배포(CD)를 관리하는 툴도 있으며, 지속적인 테스트 또는 관련 기능에 특화된 툴도 있다. 

 

 종류

• Jenkins : 간단한 CI 서버에서 완전한 CD 허브에 이르는 모든 것을 처리할 수 있게 설계
• Tekton Piplelines : 표준 클라우드 네이티브 CI/CD 경험과 컨테이너를 제공하는 쿠버네티스 플랫폼을 위한 CI/CD 프레임워크
• Spinnaker : 멀티클라우드 환경을 위해 구축된 CD 플랫폼
• GoCD : 모델링 및 시각화에 중점을 둔 CI/CD 서버
• Concourse : "지속적인 오픈소스 작업 툴"
• Screwdriver : CD용으로 설계된 빌드 플랫폼

다양한 벤더가 제공하는 관리형 CI/CD 툴도 있습니다. 주요 퍼블릭 클라우드 공급업체는 모두 GitLab, CircleCI, Travis CI, Atlassian Bamboo 등과 함께 CI/CD 솔루션을 제공합니다.

 

뿐만 아니라 DevOps의 기분 툴은 CI/CD 프로세스에 속해 있을 가능성이 높다. 

구성 자동화(EX : Ansible, Chef, Puppet), 컨테이너 런타임(EX: Docker, rkt, cri-o), 컨테이너 오케스트레이션(쿠버네티스)을 위한 툴은 엄밀하게는 CI/CD 툴이 아니지만, 많은 CI/CD 워크플로우에 표시된다. 

 

 

 

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

https://tecoble.techcourse.co.kr/post/2021-08-14-ci-cd/

CI/CD가 뭔가요? - 이론편

https://artist-developer.tistory.com/24

CI/CD란 무엇인가 (Feat. DevOps 엔지니어)