Post

CI/CD란?

CI/CD란 무엇인가 정리해보고자 합니다.

CI/CD란?

요즘같이 빠르게 변화하는 시대에는 어떻게 하면 시장과 고객의 요구에 빠르게 반응해서 제품을 출시하고 업데이트할 수 있을지가 큰 과제입니다. 이런 고민을 해결하기 위해 많은 기업들이 CI/CD를 개발 프로세스로 사용하고 있습니다.

CI/CD란 애플리케이션 개발 단계부터 배포까지 모든 단계를 자동화해서 더 효율적이고 빠르게 사용자에게 배포할 수 있도록 만드는 것을 말합니다.


CI (Continuous Integration) - 지속적인 통합

버그 수정이나 신규 기능이 메인 Repository에 주기적으로 Build 되고 Test가 되어서 Merge 되는 것을 말합니다. 이 방식은 1991년 Grady Booch가 처음 사용했습니다.

image1 Grady Booch - CI 개념의 창시자

주기적이고 빈번한 Merge

개발자들은 코드 변경 사항을 메인 Repository에 주기적으로 빈번하게 Merge 해야 합니다.

예를 들어 동일한 소스파일 위에서 두 명의 개발자가 오랜 기간 서로 작업을 하다가 머지를 하려고 한다면, 서로 다른 코드를 어떻게 통합해서 적용해 나갈 건지 고생을 많이 할 것입니다. 새로운 기능을 개발하기 위해서 코드를 작성하는 시간보다 Merge Conflict을 해결하기 위해 더 시간을 써야 할지도 모릅니다.

image2 Merge Conflict 상황 예시

버그를 수정하거나 신규 기능을 구현할 때는 작은 단위로 나눠서 메인 Repository에 반영하거나 배포하는 것이 중요합니다.

통합 단계의 자동화

Build, Test, Merge 단계를 자동화합니다.

  • 주기적으로 머지된 코드의 변경 사항이 자동으로 빌드되어서 성공적 빌드가 완료되는지 확인
  • 빌드가 된 코드 변경사항뿐만 아니라 기존 시스템에 다른 버그를 초래하지는 않았는지 자동으로 테스트

image3 일반적인 CI 파이프라인 구성

  1. 메인 Repository가 있고 개발자들은 하루에도 몇 번씩 코드를 머지
  2. 머지가 되면 CI 스크립트를 통해 자동으로 빌드
  3. 빌드 완료 후 유닛 테스트 등 여러 테스트가 실행
  4. 빌드와 테스트가 정상적으로 완료되었다면 성공 노티를, 실패했다면 실패 노티를 보냄

CI를 도입하면 이런 점이 좋습니다.

  • 주기적으로 머지를 하기 때문에 Merge Conflict가 적게 발생해요
  • Conflict 해결 시간이 단축되어 개발 생산성이 향상됩니다
  • 머지되는 모든 코드가 자동으로 빌드되고 테스트되기 때문에 문제점을 빠르게 발견할 수 있죠
  • 주기적으로 작은 단위로 머지하기 때문에 문제가 된 코드를 빠르게 찾아서 수정할 수 있습니다

CD (Continuous Delivery / Deployment) - 지속적인 제공 / 배포

마지막 배포 단계에서 어떻게 하면 자동화해서 배포할 수 있을지 고민하는 단계입니다.

Continuous Delivery (지속적 제공): CI를 통해 코드가 자동으로 빌드되고 테스트되었다면 이제 배포할 준비 과정을 거쳐야 합니다. 준비된 Release가 정상적인지 직접 개발자나 QA가 검증하고, 검증이 통과되면 수동으로 배포합니다.

Continuous Deployment (지속적 배포): Continuous Delivery와 거의 같지만 Release를 자동으로 검증하고, 검증이 완료되면 자동으로 배포합니다.

둘의 차이점은 최종 단계가 자동인지 수동인지에 따라서 용어가 달라집니다.

image4 다양한 CI/CD 도구들

CI/CD를 자동화해주는 툴은 여러 가지 있습니다. 회사마다 사용하는 툴이 다르기 때문에 회사에 맞게 공부하면 되겠습니다.

This post is licensed under CC BY 4.0 by the author.