CI/CD(Continuous Integration/Continuous Deployment)란 지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD)를 뜻한다. 애플리케이션 개발팀이 더 자주 그리고 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다. 다시 말해 git에 코드를 올리는 것만으로도 누군가가 빌드와 테스트, 배포까지 해주어 코드를 수정하고 빌드와 테스트를 하고 배포까지 수행하는 시간을 단축시키고 개발에 더 많은 시간을 투자할 수 있도록 하기위해 생겨난 방식이다.
DevOps와 같은 것처럼 보이지만 확실히 구별하자면 DevOps는 Development(개발+테스트) + Operations(운영)을 의미하는 개발과 운영을 통합하여 프로세스의 속도를 높이는 접근방식이다. CI/CD는 지속적으로 통합·테스트·배포를 하고 이 흐름을 자동화하는 것을 말한다.
간단하게 CI/CD 진행 과정을 요약하자면 아래 그림과 같다.
CI(Continuous Integration)
지속적 통합(CI)은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분은 여러 플랫폼과 툴을 사용해 개발을 진행하며 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.
쉽게 말해 CI란 빌드/테스트 자동화 과정이다. 지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장해야 한다.
극단적으로 만약 다수의 개발자가 한 프로젝트를 fork하여 각자 작업을하고 프로젝트 마감일에 합친다고 가정한다. 이 때 과연 프로젝트 마감일에 해당 소스 코드들을 문제없이 merge 할 수 있을까? 아마 불가능 할 것이다. 따라서 이에 대한 해결책으로 CI를 제시할 수 있다.
일반적인 CI에 대한 루틴인 아래의 예시가 있다.
- 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
- 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
- 통합된 코드가 제대로 빌드되는지 테스트한다.
- 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.
위 대로 수행한다면 어느정도 품질을 보장할 수 있겠지만 너무 번거로워 불만이 쏟아질 것이다. CI 자동화가 잘 이루어 진다면 위의 과정들은 아래와 같이 단순화될 수 있다.
- 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
- 다음날 출근시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.
테스트나 빌드등 복잡한 절차가 모두 생략되고, 퇴근전 코드를 git에 올리고 가면 되는 것이다.
CD(Continuous Delivery)
지속적 제공(CD)은 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
- 지속적인 제공(Continuous Delivery): 사용자들에게 서비스를 제공해도 된다는 결정 하에 배포를 수동적으로 진행하는 것
- 지속적인 배포(Continuous Deployment): 배포할 준비가 되자마자 자동화를 통하여 배포를 진행하는 것
이는 지속적 통합(CI)이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다.
즉, CD는 코드 변경을 적용(push)하기 위한 배포 자동화 과정이다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.
과정은 아래와 같다.
- CI를 적용하여 코드를 검증한다
- 배포 환경과 비슷한 곳에서 검증을 진행한다.
- 검증된 소프트웨어를 실제 프로덕션 환경으로 배포한다.
대표적인 CI/CD 관련 툴은 아래와 같다.
- Jenkins
- CircleCI
- TravisCI
- Github Actions
아래 그림은 단계별로 위 대표적인 툴을 포함한 여러 툴들이다.
참고 자료
https://www.ciokorea.com/insider/233289
https://itholic.github.io/qa-cicd/
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
https://www.opsmx.com/blog/what-is-a-ci-cd-pipeline/
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://sowon-dev.github.io/2020/12/04/201205devOpsandCICD/
