CI/CD

CI/CD란 무엇인가?

• CI^{Continuous Integration} (지속적 통합) : 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것.
• CD^{Continuous Delivery} (지속적 배포) : 팀이 짧은 주기로 소프트웨어를 개발하는 소프트웨어 공학적 접근의 하나로, 소프트웨어가 언제든지 신뢰 가능한 수준으로 출시될 수 있도록 보증하기 위한 것.

출처 - Wikipedia

Image from Devops Explained

• CI/CD는 개발하는 과정(프로세스)에 밀접한 관련이 있습니다. 서비스를 개발하는 일은 단순히 코딩으로만 끝나는 것이 아닙니다.
• 개발부터 운영이 끝없이 반복되는 위 그림과 같은 형태를 띕니다.
  • 흔히 말하는 개발 프로세스는 Dev에 해당하는 프로세스들이고, 릴리즈부터 배포, 모니터링까지 이르기를 운영(Ops)에 해당하는 프로세스입니다.
• 그렇다면 CI/CD와 이것이 무슨 상관인지 하나씩 알아보겠습니다.

CI란?

CI^{지속적 통합}는 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이라고 정의가 쓰여있습니다. 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어서 하나의 레포지토리로 관리되는 것을 의미합니다.

• SCM^{Source Code Management}의 과정도 CI에 속합니다.
  • Git을 사용해 Github 레포 하나로 여러명의 개발자가 소스코드를 올리고 충돌을 처리하는 모든 과정도 CI에 속합니다.
  • Git이 아닌 SVN도 마찬가지입니다.
• 빌드 후 작성된 테스트 코드를 통해 유효성을 검증하는 것도 CI에 속합니다.
  • 아주 간단한 예시로 Pull Request를 생성했을 때, 소스코드가 Conflict나는 경우 Merge 버튼이 비활성화 되는 경험을 해보셨을 겁니다. 그것 또한 유효성 검사에서 실패한 것으로 CI에 속합니다.
  • 더 나아가, CI 툴을 사용해 소스코드가 컨벤션에 준수하는지 등을 체크하는 린터^linter로 검증을 하도록 할 수 있는 등 다양한 일이 가능합니다.

CI를 하면 뭐가 좋은가요?

• 지속적 통합을 하게되면 소스코드는 항상 Ready-to-run 상태(배포가 가능한 상태는 아닙니다.)가 됩니다. 즉, 중간에 누군가 합류를 해도 빌드가 되는 코드를 받을 수 있습니다.
  • 혼자서 개발할 때는 이런 문제를 겪어보지 못해서 중요성을 체감하지 못합니다.
  • 하지만, 회사 프로젝트나 오픈소스 프로젝트 등 여러명이서 개발을 하는 상태라면 이 문제는 더욱 중요해집니다.
    • 중간에 합류해서 새로운 기능을 개발하려고 하는데 누군가 작업하고 있는 코드가 아직 공유 레포^upstream에 올라가 있어서 빌드가 안된다.
    • 이런 경우가 발생하면 그 사람과 얘기해서 해결하던가, 직접 소스코드를 보고 돌아가도록 디버깅을 하던가 해야합니다. 하지만, 이 자체로도 시간이 소요되므로 생산성이 매우매우 떨어지게 됩니다.
  • 게다가, 특정한 날을 정해서 각자 개발한 소스코드를 병합하도록 하게되면 그에 따르는 많은 시간을 소모하게 됩니다.
    • 만약, 기존 코드와 Merge한 코드가 에러가 난다면 이를 처리하는 과정에도 많은 시간이 소요될 것입니다.
• 항상 양질의 코드 퀄리티를 유지할 수 있습니다.
  • 테스트의 자동화를 이루게되면 항상 테스트 코드를 통과하는 코드만 공유 레포에 올라갈 수 있기 때문에 상당한 퀄리티의 소스코드로 유지되게 됩니다.

CD란?

CD는 지속적 제공^{Continuous Delivery}과 지속적 배포^{Continuous Deployment}를 모두 의미합니다.

• 지속적 제공^{Continuous Delivery} : CI 과정이 모두 끝난 뒤 유효성 검증이 된 코드를 레포지토리에 올리는 것을 자동화합니다. (프로덕션 레벨로 배포하는 것과는 별개입니다.)
  • 항상 프로덕션 레벨로 배포할 수 있는 준비가 되어있는 소스코드를 자동으로 올라갈 수 있도록 합니다.
• 지속적 배포^{Continuous Deployment} : CI/CD 과정의 마지막 단계입니다. 지속적 제공을 통해 배포 가능한 소스코드를 프로덕션 레벨로 릴리즈하는 것을 의미합니다.

실제 사례에서 지속적 배포는 개발자가 애플리케이션을 수정한 뒤 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다.

CD를 하면 뭐가 좋은가요?

• 개발부터 배포까지 과정이 번거롭지 않고 간소화 되기 때문에 사용자 피드백을 빠르게 반영할 수 있습니다.
  • 장애 대응이 빨라집니다. 릴리즈를 했는데 굉장히 크리티컬한 이슈가 발견되었을 때, 개발부터 배포까지의 과정이 복잡하면 반영에 오래걸리게 됩니다.
• 만약, 로드밸런서로 수십대의 서버를 동시에 운용한다면?
  • 자동화를 하지않으면 직접 서버에 들어가서 일일이 실행해야하기 때문에 하루종일 배포를 할 수도 있습니다.

CI/CD를 가능하게 해주는 툴

CI/CD를 제공하는 툴은 상당히 많습니다. 그 중에서 유명한 것 약 3개 정도를 비교해보겠습니다.

툴별로 이름, 가격, 특징에 근거한 내용을 정리함

Jenkins

무료 오픈소스지만
직접 설치해서 서버를 운용해야함.
설치가 어려움
자바 분야 CI/CD로 뿌리가 깊다.
다양한 플러그인 제공
파이프라인 구성 자유도 매우 높음

Circle CI

무료 플랜은 동시에 Job 1개만 돌 수 있음.
(게다가, 크레딧은 1주당 2500)
Perfomance 플랜은 한달에 30$
기업용은 꽤 비싸다
Docker-Compose를 사용 가능
무료 플랜에서는 도커 레이어 캐싱 불가

Travis CI

오픈소스(Public Repo)는 무료
기업용은 꽤 비싼편
심지어 취미용도 비싸다
Github 의존도가 높음
빌드 매트릭스 제공
(여러 버전으로 빌드를 해야할 때 이를 지원함.)

• 이외에도 TeamCity 등 많은 CI/CD 툴이 있으므로 알아보고, 여건에 맞게 골라서 사용하시면 됩니다.
• 이번 프로젝트에서는 Circle CI를 통해 자동화를 했습니다. Circle CI로 자동화하는 과정에 대한 자세한 설명은 다음 포스팅에 이어서 작성하겠습니다

출처: https://minz.dev/18 [MinJunKweon 개발 블로그]