CI/CD (Continuous Integration, Continuous Delivery)
CI는 Continuous Integration, CD는 Continuous Delivery의 약자입니다. 한국말로 하면 계속되는 통합, 계속되는 배달(배포)라는 뜻이죠. 그렇다면 공통되는 단어인 Continuous는 어떤 의미로 쓰이고 있을까요?
예전에는 여러가지 개발을 통합(코드 최신화 → 빌드 → 서비스 통합 → 테스트)와 배포 (개발 서버 배포 → 운영 서버 배포)를 하기 위해서는 특정한 날을 잡아서 열심히 통합하고 배포하였습니다. 이 과정에서 예상치 못한 버그와 문제가 생겨 많은 밤샘과 야근을 만들었죠.
이러한 문제를 해결하기위해 통합과 배포과정을 코드로 자동화하고 기존처럼 날잡고 하는 것이 아닌 주기적으로 자주 할 수 있게 만들었습니다. 즉 자동화된 코드를 통해 주기적으로 통합과 배포를 하기 때문에 Continuous라는 단어가 붙은 것이죠
CI/CD에서 주로 하는 작업은 유닛테스트, 통합테스트, 코드 정적분석, 빌드, 테스트 서버 배포, 실서버 배포 등이 있습니다.
CI/CD 정책 예제
CI/CD는 정책에 따라 빌드 정적분석 유닛테스트 통합테스트 Relase 등을 주기적으로 진행합니다.
CI 정책의 예제로 많이 쓰는 Git관리 정책인 Gitflow 와의 연동 예제는 다음과 같이 할 수 있습니다.
- Feature Branch Push시
1. 유닛테스트 수행
2. 유닛테스트 수행 실패시 테스트결과를 Slack으로 전송
- Pull Reqeuest 생성시
1. 유닛테스트 수행
2. 유닛테스트 수행 실패시 테스트결과를 Slack으로 전송
3. 소스코드 정적분석 수행
3. Slack에 정적분석 결과 Slack 전송
- Develop Branch Merge시
1. 통합 빌드
2. Develop 서버 배포
3. 통합 테스트 수행
4. 통합테스트 수행 결고 Slack 전송
- Main Branch Merge시
1. 통합 빌드
2. QA 서버 배포
3. 릴리즈 메세지와 함께 QA팀에 메세지 전송
- Relase Branch Merge시
1. 통합 빌드
2. 릴리즈 서버 배포해당 과정에 대한 스크립트를 미리 작성해서 셋업해 놓으면 Git서버에서 이벤트 CI/CD에 메세지를 보내어 해당 과정을 자동으로 수행하기 때문에 빌드 & 테스트 & 배포 를 주기적으로 자주 할 수 있으며, 사람의 실수를 최소화 하여 일정 수준 이상의 소프트웨어 퀄리티를 유지할 수 있습니다.
다음 포스팅에선 Github Actions를 이용해 CI/CD를 구성하는 방법을 알아보겠습니다.
포트폴리오 제작에 도움이 필요하다면
카우치코딩에서는 6주 포트폴리오 수업을 통해 기획 ~ 배포까지의 과정을 멘토링하고 있습니다. 기획 ~ 배포까지의 과정을 전부 경험하고 싶으면 방문해주세요~
