지속적 통합

소프트웨어 공학에서 지속적 통합(continuous integration, CI)은 지속적으로 품질 관리(Quality Control)를 적용하는 프로세스를 실행하는 것이다. - 작은 단위의 작업, 빈번한 적용. 지속적인 통합은 모든 개발을 완료한 뒤에 품질 관리를 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있다. 대표적인 CI 툴에는 젠킨스(Jenkins)가 있다.

소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경

이론

개발자가 기존 코드의 수정 작업을 시작할 때, 일반적으로 현재의 코드 베이스의 복사본을 받아서 거기로부터 작업을 시작한다. 한편, 다른 개발자들이 자신들이 변경한 코드를 소스 코드 저장소에 제출하면, 코드 베이스로부터 받아온 복사본은 저장소 코드와 점차 달라진다. 코드 베이스만 변하는 것이 아니라, 새 라이브러리가 추가되거나 그 밖에 의존성 문제가 생길 수 있는 다양한 변화들이 생길 수 있다.

개발자들이 저장소에 코드를 제출하려면, 먼저 자신이 코드를 받았던 때부터 현재까지 저장소 코드의 변경 내용을 자신의 코드에 반영되도록 자신의 코드를 업데이트한 후 자신의 코드를 제출해야 한다. 저장소에 변경된 내용이 많을수록, 개발자들이 자신의 작업 내용을 제출하기 전에 해야 할 일이 많아진다.

언젠가는 저장소가 개발자들의 베이스라인과는 너무 많이 달라지게 되는 "통합의 지옥" 이라 불리는 상황에 빠지게 된다. 이 경우, 작업하는 시간보다 작업 내용을 통합하는데 걸리는 시간이 더 걸리게 되어, 최악의 경우 개발자들이 자신들의 변경 내용들을 취소하고 작업들을 완전히 처음부터 다시하는 것이 나을 수도 있다.

지속적인 통합은 초기에 그리고 자주 통합해서 "통합의 지옥"의 함정을 피하는 것을 내포하고 있다. 지속적인 통합은 재작업을 줄여서 비용과 시간을 줄이는데 초점이 맞추어져 있다.

지속적인 통합을 적용하지 않으면, 각각의 프로그래머가 자신이 작업한 것을 제출하기 전에 반드시 완벽한 빌드와 테스트를 해야 한다. 모든 프로그래머들은 저장소로부터 프로젝트를 업데이트하는 것으로 하루를 시작해야 한다. 그러면, 그들은 모든 것들을 최신의 상태로 유지할 수 있을 것이다.

같이 보기

• 지속적 배포