지속적 통합(continuous integration, CI)은 개발자들의 변경을 공용 주 줄기(mainline)에 계속 합치고, 합칠 때마다 자동으로 빌드하고 테스트하는 개발 기법이다.[1][2] SWEBOK V4.0a에 따르면 CI를 하는 팀은 작업을 하루에도 여러 번 통합하고, 파이프라인이 통합마다 빌드하고 테스트해 오류를 찾아 빠르게 알려 준다. CI의 근본 목표는 문제가 있는 변경을 되도록 일찍 자동으로 잡는 것이다.[3]
기원
Kent Beck은 1999년 『Extreme Programming Explained: Embrace Change』에서 지속적 통합을 XP(Extreme Programming)의 실천 항목 가운데 하나로 두고, 하루에도 여러 번 통합하고 테스트하는 것으로 설명했다.[4] Martin Fowler와 Matthew Foemmel은 2000년에 지속적 통합을 설명하는 글을 냈고[5], Fowler는 2006년과 2024년에 이 글을 고쳐 썼다.[6]
실천 항목
Fowler는 지속적 통합을, 팀원 각자가 적어도 하루에 한 번 변경을 공동 코드베이스에 합치고 통합마다 테스트를 포함한 자동 빌드로 확인해 통합 오류를 되도록 빨리 찾는 관행으로 정의한다. 2024년판 글에서 그가 드는 실천 항목은 다음과 같다.[6]
- 모든 것을 버전 관리되는 주 줄기에 둔다.
- 빌드를 자동화한다.
- 빌드가 스스로 테스트하게 한다.
- 모든 개발자가 날마다 주 줄기에 push한다.
- 주 줄기에 push가 들어올 때마다 빌드한다.
- 깨진 빌드는 곧바로 고친다.
- 빌드를 빠르게 유지한다.
- 작업 중인 기능을 숨긴다.
- 운영 환경을 본뜬 환경에서 테스트한다.
- 누구나 진행 상황을 볼 수 있게 한다.
- 배포를 자동화한다.[6]
파이프라인에 넣는 검사
SWEBOK V4.0a에 따르면 지속적 통합에서는 서버에서 도는 도구가 소스 저장소를 지켜보다가, 변경이 커밋될 때마다 단계로 이은 파이프라인을 시작해 코드를 컴파일하고 링크한다. 여기에 정적 분석으로 코딩 표준을 확인하는 단계와, 단위 테스트를 돌리고 코드 커버리지를 재는 단계를 함께 두는 일이 많다.[3] 지속적 통합에서는 자동화한 회귀 테스트도 함께 돌린다.[3][7]
Jenkins는 지속적 통합을 지원하는 자동화 엔진이다.[8]
지속적 전달과 지속적 배포
- 지속적 전달(continuous delivery): ISTQB 용어집은 코드 변경을 자동으로 빌드하고 테스트해 운영 환경 출시를 준비하는 자동화된 개발 절차로 정의한다.[9] ISO/IEC/IEEE 24765 용어집은 자동화 도구로 새 시스템을 스테이징이나 여러 테스트 환경에 자주 내보낼 수 있게 하는 실천으로 정의한다.[1] 자동 테스트와 품질 검사를 통과한 애플리케이션을 늘 운영 환경에 내보낼 수 있는 상태로 두는 실천을 지속적 전달이라 부르며, 지속적 전달은 운영 환경으로의 마지막 배포를 사람이 하는 단계로 남긴다는 점에서 지속적 배포와 갈린다.[10]
- 지속적 배포(continuous deployment): 정해진 테스트와 검증을 통과한 변경을 자동으로 운영 환경에 배포하는 절차다.[1][11]