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

매번 개발자가 코드를 수정하고 빌드와 테스트를 하고 배포까지 한다면 상당히 많은 시간이 소요됩니다. 하지만 git에 코드를 올리는 것만으로도 누군가가 빌드와 테스트, 배포까지 해준다면, 쓸데없는 시간을 단축시키고 개발에 더 많은 시간을 투자할 수 있을겁니다.

이번에는 CI, CD의 개념에 대해 정리하겠습니다

CI

CI는 간단히 요약하자면 빌드/테스트 자동화 과정 과정입니다. CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작합니다. 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장합니다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 합니다.

CD란?

CD는 간단히 말하면 배포 자동화 과정입니다. CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올립니다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포됩니다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있습니다.(정말 편합니다 👍)

지속적 배포는 또한 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 합니다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포됩니다. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리즈가 특별하지 않은 작업이 됩니다.

CI/CD 적용 전 과 후 비교

CI/CD를 적용하기 전의 고전적인 코드 통합 과정을 생각해봅시다

1. 개발자들이 개발하여 코드를 수정합니다.

2. 각자의 feature 브랜치에 코드를 push합니다. (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못합니다.)

3. 각자의 코드를 git에 올리고 통합(Intergration)합니다.

4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어느 부분에 에러가 있는지 디버깅하고 코드를 수정합니다.

5. (1) ~ (4)의 과정을 반복합니다.

6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작합니다. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요합니다.

코드의 양이 적다면 조금만 시간을 할애해도 에러를 찾아낼 수 있지만, 코드의 양이 많다면 에러 추적이 안되므로 어마어마한 양의 디버깅 과정을 마주하게 될 수도 있습니다.

CI/CD를 적용한 후

1. 개발자들이 개발하여 브랜치에 코드를 push 한다.
2. git push를 통해 Trigger 되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송한다.
3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러 부분을 수정하고 코드를 main 브랜치에 merge 한다.
4. main 브랜치에 코드를 merge 하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy(배포) 과정을 수행한다.

그럼 대표적인 CI/CD 종류에 대해 알아보자!

CI/CD 툴 비교

• Jenkins
• Github Actions
• CircleCI
• TravisCI

우선 CI/CD 툴이 위에 예시처럼 여러가지 있겠지만 비교적 래퍼런스가 많고 가장 많이 이용하는 Jenkins와 GitHub Actions을 후보에 두고 비교 해보겠습니다.

👏🏻 젠킨스는 무료이고, 오래되서 문서도 많고 탄탄한 느낌

• 하지만 → 구성 자체가 어렵다 (젠킨스 빌드를 위해 서버를 하나 뛰어야한다고 함)

👏🏻 GitAction 은 비교적 쉽게 빌드가 가능하다

• 별도의 클라우드로 돌리기 때문에 사용자가 따로 구성해주지 않아도 됨

• GitHub Actions는 GitHub에서 제공하는 완전 관리 형 서비스이므로 이를 실행하기 위해 인프라를 확장하고 운영하는 방법을 알 필요가 없습니다.

• GitHub 작업은 많은 언어와 프레임 워크를 지원하며 YAML로도 작성됩니다. 따라서 코드처럼 편집, 재사용, 공유 및 분기 할 수 있습니다.

• 저장소를 포크하면 작업이 자동으로 포크되기 때문에 GitHub와 함께 사용하는 것은 간단합니다.

• 이를 통해 프로젝트를 매우 효율적으로 테스트하고 빌드 할 수 있으며 개발자와 더 가깝게 실행할 수도 있습니다.

📌 (요약)

큰 규모의 프로젝트라면 Jenkins 추천하는 느낌, but 작은 서비스라면 쉽게 설정 가능한 GitHub Actions를 추천함

• Jenkins가 더 커스텀하게 맞출 수 있고 플러그인도 훨씬 다양함

  • 확장성: 풍부한 플러그인 생태계 덕분에 다양한 요구사항을 충족할 수 있음.
  • 유연성: 커스텀 파이프라인 작성 및 복잡한 CI/CD 워크플로우 설정에 강력한 기능을 제공.
  • 자동화: 고도로 자동화된 빌드, 테스트, 배포 파이프라인을 구축할 수 있어 대규모 프로젝트에 적합.

• GitHub Actions는 설정들이 어느 정도 정형화되어 있어 쉽게 사용 가능한 느낌

  • 쉬운 설정: GitHub 리포지토리 내에서 YAML 파일을 통해 간단하게 설정할 수 있음.
  • GitHub과의 통합: GitHub 이벤트와 밀접하게 통합되어 코드 변경, PR, 이슈 등의 이벤트를 쉽게 트리거할 수 있음.
  • 비용 효율성: 작은 프로젝트나 스타트업의 경우 무료 요금제를 이용할 수 있어 초기 비용 절감에 유리함.

언뜻 봐서는 굳이 필요한 작업인가? 하실수도 있지만(저도 처음엔 그랬습니다,,,) 프로젝트를 진행하고 규모가 커질수록 일일히 빌드와 테스트, 배포과정을 개발자가 직접한다는 것은 리소스 낭비이고 심한 경우에는 업무의 대부분을 빌드와 테스트, 배포에 투자해야 할 수도 있습니다.

저도 최근 프로젝트에 CI/CD를 접한 후, 장점을 몸소 느끼게 되어 프로젝트 진행 시 자동화 구축은 필수라고 생각합니다!⭐️

참고

https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://seosh817.tistory.com/104
https://jud00.tistory.com/entry/CICD%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C