CI / CD / CD

 

지속적 통합 (Continuous Integration)

소프트웨어의 모든 변경 사항과 정기적으로 변경된 모든 구성요소를 통합 (최소 하루 한 번)
형상 관리, 편집, 소프트웨어 빌드, 배포 및 테스트를 하나의 자동화된 반복적인 프로세스로 통합 

<코드 변경  - 빌드 - 자동화 테스트>
지속적 전달/배포의 일부분

요구사항
새로운 기능, 개선, 버그 수정마다 자동화 테스트 작성
메인 repo를 모니터하고 테스트를 자동으로 실행할 CI 서버/도구 필요
개발자는 가능한 자주 코드 변경에 대한 병합(merge) 필요

장점
지속적 통합, 구축, 테스트 → 결함 빨리 발견
테스트 자동화로 인해 리그레션이 조기에 발견 → production으로 전달되는 버그 ↓
통합(integration) 이슈 조기 해결 → 쉬운 릴리스 빌드
빌드가 손상되자마자 알려주므로, 바로 수정 가능
테스트 비용 ↓, CI 서버 = 짧은 시간 내에 많은 테스트 실행
QA팀은 테스트 시간 축소 → 다른 중요한 활동 집중

 

지속적 전달 (Contiunous Delivery)

<코드 커밋/변경 - 빌드 - 테스트 자동화 - 배포 (testing/production 환경)>

'지속적 통합'의 확장판
테스트 자동화 + 배포 자동화
릴리스 결정 선택 가능
가능한 빨리, production으로 배포할 것 (production = 릴리스 준비 됨)

요구사항
지속적 통합의 강력한 기반 & 코드를 충분히 커버하는 테스트 스위트
배포 자동화 필요 (트리거는 수동)
Feature flag를 포괄하여, 미완성된 기능이 production 고객에게 영향을 주지 않도록 할 것

장점
배포의 복잡성 X → 릴리스에 시간 낭비하지 않아도 됨
더 자주 릴리스 가능 (고객 피드백 loop 활성화)
반복주기가 빨라짐 → 작은 변경에 대한 결정 부담 ↓

 

지속적 배포 (Continuous Deployment)

<코드 커밋/변경 - 빌드 - 테스트 자동화 - 배포 (고객에게 릴리스)>

'지속적 전달'의 확장판
테스트 자동화 + 릴리스 자동화
사람 개입 X, 릴리스 날짜 X
테스트 fail을 했을 때만, production에 변경이 배포되는 것을 막음

요구사항
테스트 스위트 품질 = 릴리스 품질
배포 속도를 맞추어 문서화 프로세스 필요
중요한 변경 릴리스 → Feature flags가 내재하게 됨 (다른 부서와 함께 조직화)

장점
개발을 더 빠르게 할 수 있음 (릴리스 위해 개발을 멈추지 않아도 됨)
배포 파이프라인은 모든 변경에 대해 자동으로 트리거 됨
조금씩 배포 → 릴리스 리스크 ↓ & 문제 생겼을 시, 고치기 쉬움
개선에 대한 지속적 흐름을 볼 수 있음
품질 = 매달, 매년이 아닌 매일 향상

 

지속적 전달과 지속적 배포의 차이점을 간략하게 설명하자면,

 

지속적 전달은 production 환경까지 이동하고, 배포를 위해 승인을 기다림 (릴리스할 준비)

지속적 배포는 production 환경에서 배포까지 자동화 (릴리스)

 

 

---

지속적 통합 → 지속적 배포

 

option 1. 새로운 프로젝트 & 고객 X

 

production에 모든 커밋을 쉽게 배포

배포 자동화, 알파 버전을 (고객이 없는) production에 릴리스

빌드하면서 코드 커버리지 향상하기

production에 자동으로 릴리스 되기 전에 모든 새로운 변경을 테스트하는 지속적 배포 프로세스

 

option 2. 기존 프로젝트 & 고객 O

 

속도를 늦춰 <지속적 통합 + 지속적 제공>으로 시작

유닛 자동화 테스트 구현, End-to-End 테스트 실행 X

가능한 빨리 배포 자동화 시도

staging 환경에 배포 자동화 수행

릴리스 조정이 아닌 테스트 개선에 에너지 집중

매일 소프트웨어 릴리스가 시작되면, 지속적 배포 적용 가능