[CI/CD] CI/CD란? - 지속적 통합 / 지속적 제공 기본개념

매번 개발자가 이슈가 생길때 코드를 수정하고 빌드와 테스트 배포까지 한다면 상당히 많은
시간이 소요되는 현상이 발생할 수도 있다. 하지만 git이라는 버전관리 시스템이 있다면

프로젝트의 코드만 올리는 것 만으로도 누군가가 빌드와 테스트, 배포까지 해준다면,

쓸데없는 시간을 단축시키고 개발에 더 많은 시간을 투자할 수 있을것이다.

 

이번시간에는 그 CI와 CD의 기본 개념에 대해 알아보겠다.

 

CI : Continuous Integration

지속적 통합

어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에
통합되는 것을 의미한다.

CI란?

CI란 간단히 요약해 프로젝트를 빌드/테스트 자동화 과정을 담당하는 과정이다. 

CI는 개발자를 위한 프로세스인 지속적 통합(Continuous Integreation)을 의미합니다. 

CI를 성공적으로 구현할 경우 애플리케이션에 대한  새로운 코드 변경 사항이 정기적으로

빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에

애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충될할 수 있는 문제를 해결할 수 있습니다.

 

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋해 모든 사람에게 

동일 작업 기반을 제공하는 것으로 시작합니다. 
커밋을할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 
생기는 부분이 없도록 보장합니다.

 

CI가 필요한 환경

• 다수의 개발자가 형상관리툴(git,SVN 등)을 공유해 사용하는 환경
• MSA(Micro Service Architecture)환경
  • Agile 방법론(소규모 기능 단위로 빠르게 개발 & 적용을 반복하는 개발 방법론) 
    이 적용되기 떄문에 기능 추가가 매우 빈번히 발생
  • 동작테스트도 중요
  • CI의 적용은 기능 충돌 방지 등의 Benefit을 제공할 수 있음 

CI의 핵심 목표

• 버그를 신속하게 찾아서 해결한다.
• 소프트웨어 품질을 개선하기위해 노력
• 새로운 업데이트의 검증 및 릴리즈의 시간을 단축

CD: Continuous Delivery / Continuous Deployment

Continuous Delivery != Continuous Deployment

• continuous delivery는 공유 레포지토리로 자동으로 Release 하는 것
• continuous deployment는 개발자의 변경사항이 레포지토리를 넘어, Production 레벨까지
  자동으로 deploy 하는 것을 의미

CD란?

CD는 간단히 말해 배포를 자동화 하는 과정입니다. CD는 지속적인 서비스 제공(Continuous Delivery)

또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다.

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

 

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어올리는데

코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과 시 수동 개입 없이 해당 변경 사항이 
프로덕션에서 자동으로 배포됩니다. 지속적 배포를 채택 시 품질 저하 없이 최대한 빠르게 사용자 에게

새로운 기능을 제공해 줄 수 있습니다.

 

지속적 배포는 또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 진행합니다. 

간단한 코드 변경이 정기적으로 마스터에 커밋이 되고, 자동화된 빌드 및 테스트 프로세스를 거치며
다양한 사전 프로덕션 환경이 승격되며, 문제가 발견되지 않을 시 최종적으로 배포됩니다.

강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도
여러 번 이루어지는 릴리스가 특별하지 않은 일상이 됩니다.

CI/CD의 종류

• Jenkins
• CircleCI
• TravisCI
• Github Actions
• etc

CI/CD 적용 전과후 비교

CI/CD를 적용하기 전의 고전적인 코드 통합 과정을 생각해보자.

• 개발자들이 개발하여 코드를 수정한다.
• 각자의 feature 브랜치에 코드를 push한다 (단 어느 한 부분에서 에러가 발생하였으나 개발자들은
  눈치채지 못한다)
• 각자의 코드를 git에 올리고 통합(intergration)한다.
• 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는가 디버깅
  하고 코드를 수정한다.
• 위에서 순서대로 과정을 반복한다.
• 많은 시간을 할애하며 에러가 해결되었고 배포를 시작한다. 하지만 배포 과정 또한, 개발자가 직전 
  배포 과정을 거치므로 많은 시간이 소요된다.

만약 코드의 양이 적다면 그나마 조금만 시간을 할애하면 에러를 찾아낼 수 있지만, 코드의 양이 많다면 
에러 추적이 어렵기 때문에 어마어마한 양의 디버깅 과정을 마주하게 될 수도 있다.

 

CI/CD를 적용 후과정

 

이 과정은 하나의 예시일 뿐 상황에 따라 다르게 적용될 수 있다. 예를 들면 중간에 PR과정을 추가할 수 있고,

SonarQube를 돌린다던지, git tag를 통해 Deploy를 Trigger 시킬 수 있다.

 

• 개발자들이 개발하여 feature브랜치에 코드를 push한다.
• git push를 통해 Trigger되어 CI서버에 알아서 Build(빌드), Test(테스트), Lint (분석)를 실행하고 
  결과를 전송한다.
• 개발자들은 결과를 전송받고 에라가 난 부분이 있다면 에러부분을 수정 후 코드를 master 브랜치에
  merge(병합)한다.
• master 브랜치에 코드를 merge하고 Build(빌드), Test(테스트)가 정상적으로 수행이 되었다면 
  CI서버에서 알아서 Deploy 과정을 수행한다.

언뜻 봐서 굳이 필요한 작업일까? 라고 생가할 수도 있지만 실무에서 일일히 빌드와 테스트, 배포과정을 
개발자가 직접한다는 것은 사실생 리소스낭비이고 심한 경우 업무의 대부분을 빌드와 테스트, 배포에 
투자 해야하는 경우도 있을 것이다.

 

참고 자료

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정

[CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념

CI / CD 란 무엇일까