CI/CD에 대하여

 

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

https://www.youtube.com/watch?v=0Emq5FypiMM

 

 

CI/CD는 지속적 통합(Continuous Integration) 및 지속적 제공/배포(Continuous Delivery/Deployment)를 의미

CI/CD란? 어플리케이션 개발부터 배포까지의 모든 단계들을 자동화를 통해서 조금 더 빠르고 효율적으로 사용자에게 빈번히 배포할 수 있도록 만드는 것.

CI:

지속적통합(Continuous Integration)으로 여기서 통합이란 머지를 의미함. 
CI에는 두가지 특징이 있다. 
1. 코드 변경사항을 메인 레포지토리에 주기적으로 빌드, 테스트되어 빈번히 머지해야 한다.

동일한 소스파일을 서로 다른 두명의 개발자가 장시간 각기 수정을 하다가 메인 레포지토리에 머지 할려면 같은 파일의 서로 다른 코드를 어떻게 병합해 나갈건지 고생을 많이하고 충돌이 발생하게 된다. ==>> 머지 충돌을 해결하기 위해 더 많은 시간이 소요됨.==>> 따라서 새로운 기능 구현이나 버그를 수정할때는 가능한 더 작은 기능으로 나누어 메인 레포지토리에 반영, 배포해야 한다. 

동일한 소스파일을 서로 다른 두명의 개발자가 장시간 각기 수정을 하다가 메인 레포지토리에 머지 할려면 같은 파일의 서로 다른 코드를 어떻게 병합해 나갈건지 고생을 많이하고 충돌이 발생하게 된다

따라서 새로운 기능 구현이나 버그를 수정할때는 가능한  더 작은 기능으로 나누어 메인 레포지토리에 반영, 배포해야 한다.

2. 성공적인 통합(머지)을 하기까지의 모든 단계(머지, 빌드, 테스트)가 자동화 되어 있다(메인 레포지토리에 머지 하면 그 머지된 코드가 기존의 코드와 맞물려 잘 돌아가는지, 빌드, 테스트의 과정을 거침). 

성공적인 통합(머지)을 하기까지의 모든 단계(머지, 빌드, 테스트)가 자동화 되어 있다(메인 레포지토리에 머지 하면 그 머지된 코드가 기존의 코드와 맞물려 잘 돌아가는지, 빌드, 테스트의 과정을 거침)

일단 머지가 되면 자동으로 팀에서 만든 CI 스크립트를 통해서 추가된 코드와 함께 레포지토리가 다시 빌드되고 빌드가 잘 되면 팀에서 작성한 unit test, integration test등의 여러가지 테스트들도 스크립트를 통해 실행이 된다. 이렇게 빌드, 테스트가 잘되면 그림과 같이 초록불이 들어옴. ==>> 새롭게 배포할 때 반영할 수 있음.  반면 build혹은 test에 문제가 생기면 개발자에서 방금 merge한 코드에 문제가 있다고 알려줌.

 

이렇게 CI의 원칙을 따랐을 때의 장점은 주기적으로 머지(가능한 작은 단위의 변경사항을 반영함)를 하기 때문에 머지의 충돌을 피할 수 있어 개발의 생산성을 높일수 있다. 또한 머지되는 모든 코드들은 자동으로 빌드, 테스트의 과정을 거치므로 코드의 결함을 빨리 발견할 수 있다는 것이다.

 

Continuous Delivery(지속적 제공) / Continous Deployment(지속적 배포)

배포는 Deployment혹은 Release이다.

수동적으로 배포하는 것이 Continous Delivery

자동으로 배포하는 것이 Continous Deployment(prepare Release되자마자 자동으로 배포함)

회사에 따라서 수동적으로 배포하는 곳이 있고 자동으로 배포하는 곳이 있다. 얼마만큼 자신이 있느냐에 따라 나뉨. 회사마다 어느정도의, 얼마만큼의 자동화를 하는지가 다 다르다. 따라서 CI/CD라고 하여 모든 회사가 같은 프로세스를 거치는 것이 아니다.

 

아래의 그림을 CI/CD 파이프 라인이라고 한다.

CI/CD파이프 라인을 마지막으로 정리하면 다음과 같다. 개발자가 작은 단위로 새로운 기능을 구현하거나 버그를 수정함. 주기적으로 메인 레포지토리에 머지함. 자동으로 build, test과정을 거침(여기까지가CI). Release를 함. 수동혹은 자동으로 최종 Deploy를 함

 

 

지속적 통합(CI)은 코드 변경 사항을 공유 소스 코드 리포지토리에 자동으로 자주 통합하는 사례를 나타냅니다. 지속적 제공 및/또는 배포(CD)는 코드 변경 사항의 제공, 배포를 나타내는 프로세스로, 두 가지 부분으로 구성됩니다. 지속적 제공(Continuous Delivery)에는 자동 프로덕션 배포 기능이 없는 반면, 지속적 배포(Continuous Deployment)는 업데이트를 프로덕션 환경에 자동으로 릴리스합니다.

 

지속적 제공이란?

 지속적 제공은 CI에서 빌드와 단위 및 통합 테스트를 자동화한 다음 검증된 코드를 리포지토리로 릴리스하는 것을 자동화합니다(위 그림에서 prepare release를 말하는 것 같음). 따라서 효과적인 CD(지속적 제공 프로세스)를 마련하려면 CI(지속적 통합)가 개발 파이프라인에 이미 구축되어 있어야 합니다(CD(지속적 제공)가 되려면 CI(지속적 통합)가 구축되어 있어야 한다는 의미. 제공이 되려면 통합이 제대로 구축되어 있어야 한다는 의미로 기억하기. "통합(Integation)이 잘되어야 그것을 결과적으로 서버에 제공(Delivery) 할수 있다" 로 기억하면 됨).

지속적 제공의 경우, 코드 변경 사항의 병합부터 프로덕션 레디 빌드의 제공에 이르기까지 모든 단계에 테스트 자동화와 코드 릴리스 자동화가 수반됩니다. 이 프로세스가 종료되면 운영 팀은 애플리케이션을 프로덕션으로 신속하게 배포할 수 있습니다.

일반적으로 지속적 제공(CD)이란 개발자의 애플리케이션 변경 사항이 자동으로 버그 테스트를 거치고 레포지토리(예: GitHub, 컨테이너 레지스트리)로 업로드된다는 것을 의미합니다. 이후 레포지토리에서 운영 팀이 변경 사항을 라이브 프로덕션 환경으로 배포할 수 있습니다(즉 제공(delivery)된다는 것은 레포지토리로 제공된다는 것을 의미하는 것임). 그 결과 개발 팀과 비즈니스 팀 간 가시성 및 의사 소통 부족 문제가 해결될 수 있습니다. 이를 위한 지속적 제공의 목표는 언제나 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 갖추고 새로운 코드를 배포하는 데 필요한 노력을 최소화하는 것입니다(즉 배포 직전의 모든 준비를 다 해놓는 작업이 Continuous Delivery이다). (레포지토리와 프로덕션(운영)을 구분하고 있음)

실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다(자동화된 테스트를 통과한 것으로 간주). 이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해집니다. 이러한 연결된 모든 CI/CD 사례는 애플리케이션 배포의 리스크를 줄여주므로 애플리케이션 변경 사항을 한꺼번에 릴리스하지 않고 작은 단위로 세분화하여 더욱 손쉽게 릴리즈할 수 있습니다. 

 

CI/CD 에 대한 개념 최종정리 

CI는 지속적 통합을 의미하고 여기서의 통합은 운영에 사용되는 실제 레포지토리에 반영되기 전에 새롭게 수정된 소스코드가 기존의 코드와는 충돌하지 않는지, 몇명이서 서로 각기 수정한 코드가 기존의 코드와 충돌하지는 않는지 TEST를 통해 새코드혹은 수정된 코드를 기존의 코드와 병합해 보는 과정입니다. 
이과정에 이상이 없다면 CD(Continuous Delivery)의 과정에서 수정된 코드를 실제 운영환경에 사용되는 레포지토리에 적용하고 이러한 과정을 자동으로 반복해 주는 것이 Continuous Delivery라고 합니다. 그리고 여기까지 이상이 없다면 이것을 실제 운영환경에 자동으로 반영시켜 주는 것이 Continuous Deployment 라고 합니다.