CI(지속적 통합)은 개발자가 개발 주기 전반에서 더 빈번하게 신규 작성 코드를 통합하는 소프트웨어 개발 프로세스입니다. 매일 1회 이상 코드 베이스에 추가합니다. 빌드할 때마다 자동 테스트가 실행되어 통합 문제점을 일찍 찾아냅니다. 따라서 문제점을 수정하기가 더 용이합니다. 그리고 릴리스를 위한 최종 병합 단계에서 문제점이 발생하는 사태를 방지할 수 있습니다. 전반적으로 지속적 통합은 더 능률적인 빌드 프로세스를 가능하게 하므로, 소프트웨어 품질 향상 및 예측 가능한 딜리버리 일정 관리에 기여합니다.
DevOps는 근본적으로 더 우수한 품질의 소프트웨어를 더 신속하게 딜리버리하기 위한 소프트웨어 개발 프로세스이자 조직 문화적 변화를 가리킵니다. 이를 위해 개발 팀과 IT 운영 팀의 활동을 자동화하고 통합합니다. 이 두 조직은 지금까지 개별적으로, 즉 각자의 사일로 내에서 작업하곤 했습니다.
현실적으로 최상의 DevOps 프로세스 및 문화는 개발 및 운영의 영역에 머무르지 않고 모든 애플리케이션 이해 관계자, 이를테면 플랫폼/인프라 엔지니어링, 보안, 컴플라이언스, 거버넌스, 위험 관리, LOB(line-of-business), 최종 사용자, 고객 등의 의견을 소프트웨어 개발 라이프사이클에 반영합니다.
DevOps 프레임워크에서는 소프트웨어 개발 프로세스의 초기 단계부터 지속적 통합이 이루어집니다. 즉, 매일 1회 이상 코드를 체크인함으로써 로컬 복사본이 코드 빌드의 기본 분기(branch)에서 너무 동떨어지지 않게 합니다. 그러면 병합 단계에서 심각한 충돌이 일어나 빌드 프로세스가 난관에 봉착하고 담당 팀이 몇 시간, 또는 며칠 동안 문제 해결에 매달려야 하는 상황을 방지할 수 있습니다.
지속적 통합은 지속적 딜리버리에서 테스트, 배치, 릴리스 단계의 선행 조건입니다. 개발 팀 전체가 체크인 후 몇 분 이내에 불량 코드 작성 여부를 파악하게 됩니다. 지속적 통합 서비스에서는 자동으로 코드 변경 사항을 빌드하고 테스트하면서 만일의 오류를 찾아내기 때문입니다.
DevOps 주기에서는 지속적 통합 다음에 지속적 딜리버리 및 지속적 배치가 이루어집니다.
CD(지속적 딜리버리)는 지속적 통합이 끝나는 지점에서 다시 시작하여 선택된 인프라 환경으로 애플리케이션을 자동 딜리버리합니다. CD는 검증 완료된 코드 베이스 변경 사항(업데이트, 버그 수정, 새로운 기능 등)을 사용자에게 최대한 빠르고 안전하게 제공하는 데 중점을 둡니다. 그러면 코드 변경 사항을 개발, 테스트, 프로덕션 등과 같은 다양한 환경에 배포하는 작업이 자동화됩니다.
지속적 배치에서는 애플리케이션의 코드 변경 사항이 프로덕션 환경에 자동으로 배포됩니다. 이 자동화는 일련의 사전 정의된 테스트로 구동됩니다. 신규 업데이트가 이 테스트를 통과하면, 시스템에서 곧바로 소프트웨어의 사용자에게 푸시 방식으로 업데이트를 배포합니다.
c지속적 통합으로 누릴 수 있는 대표적인 이점으로는 다음을 꼽을 수 있습니다.
- 조기에 더 효과적으로 오류 탐지 및 메트릭 확보 - 때때로 체크인 후 몇 분 이내에 오류 해결 가능
- 상시 진행 상황을 확인하면서 더 유익한 피드백 적용 가능
- 팀 협업 증진 - 모든 팀원이 코드를 변경하고 시스템을 통합하고 소프트웨어의 다른 영역과의 충돌을 신속하게 해결 가능
- 더 효과적으로 시스템 통합 - 소프트웨어 개발 라이프사이클의 말기에 뜻밖의 상황이 벌어질 가능성 최소화
- 병합 및 테스트에서 동시 변경의 필요성 감소
- 시스템 테스트 과정에서 오류 건수 감소
- 상시 업데이트된 시스템을 대상으로 테스트 가능
애자일은 소프트웨어 개발 팀에서 조직을 꾸리고 요구 사항의 변경을 수용하면서 소프트웨어를 배포하는 방식을 개선하는 소프트웨어 개발 프랙티스입니다. 지속적 통합(IBM 외부 링크)과 애자일 개발은 겹치는 기능이 많아(예: 테스트 자동화) 지속적 통합과 애자일을 동시에 설명하는 게 더 효과적일 수 있습니다. 애자일은 개발을 보다 작은 그룹의 작업 또는 스프린트로 구성합니다. 이를 DevOps에 접목함으로써 소프트웨어 품질 및 프로젝트 유연성을 보장할 수 있습니다.
지속적 통합에서는 자주, 대개는 매일 수차례 작업 내용을 통합해야 합니다. 사용자는 가능한 한 빨리 통합 오류를 감지하는 자동화된 빌드로 통합을 검증합니다. 빌드는 검증의 일부로서 실행 테스트를 포함해야 합니다. 고속 테스트를 확장하여 자동화된 테스트 환경에서 이루어지는 런타임 테스트까지 포함하면, 자연스럽게 지속적 딜리버리로 이어집니다.
애자일(IBM 외부 링크) 역시 반복적이며 변경 사항을 수용하므로 차츰 솔루션을 확장하고 발전시킬 수 있습니다. 지속적 통합의 관점에서 바라본 애자일 소프트웨어 개발은, 지속적 통합 과정에서 기능의 가치에 부여하는 우선순위에 따라 소프트웨어 이터레이션(iteration)을 제공하는 것을 의미합니다.
다음과 같은 오픈 소스 지속적 통합 툴이 자주 사용됩니다.
- Jenkins: 널리 쓰이는 오픈 소스 지속적 통합 툴인 Jenkins는 개발자가 소스 저장소에 커미트하는 즉시 코드를 자동으로 빌드, 통합, 테스트할 수 있게 합니다. 그러면 개발자가 더 손쉽게 일찍 버그를 찾아내 신속하게 소프트웨어를 배치할 수 있게 됩니다. Docker 플러그인을 Jenkins에서 사용할 수 있습니다.
- Buildbot: Buildbot은 소프트웨어 개발 주기의 모든 요소를 자동화할 수 있습니다. 작업 스케줄링 시스템인 이는 작업을 큐에 지정하고 실행하며, 결과를 보고합니다.
- Go: Go의 차별화 요소는 파이프라인의 개념입니다. 그 덕분에 복잡한 빌드 워크플로우 모델링이 손쉽게 해결됩니다.
- Travis CI: 가장 오래되었고 신뢰받는 호스팅 솔루션 중 하나이며, 기업용 온프레미스 버전으로도 제공됩니다.
- GitLab CI: 오픈 소스 Rails 프로젝트의 핵심 요소인 GitLab CI는 무료 호스팅 서비스이며, 세부적인 git 저장소 관리 기능과 함께 액세스 제어, 이슈 트래킹, 코드 리뷰 등의 기능도 제공합니다.
지속적 통합에 오픈 소스 툴을 활용하면 다음과 같은 여러 이점을 누릴 수 있습니다.
- 프로젝트를 지원하는 수백 가지의 플러그인
- Python, Java, JavaScript 등을 비롯한 다양한 오픈 소스 언어 지원
- 무료 - 학생, 스타트업, 개발자 등과 함께 경제적 부담 없이 강력한 툴 사용
- 맞춤화 가능 - 개발자가 기본 CI 툴을 바탕으로 각자의 필요에 따라 추가적인 빌드 적용 가능
- 툴 수정 및 재배포 가능
소프트웨어 개발 워크플로우를 위해 Jenkins, Go, Buildbot, Travis CI와 같은 오픈 소스 지속적 통합 툴 사용을 검토할 수 있습니다. 그에 관해서는 다음 섹션에서 자세히 설명합니다.
지속적 통합 서버는 모든 지속적 통합 작업을 중앙화한 다음 확실하고 안정적인 플랫폼을 제공하는 소프트웨어 툴입니다. 이 플랫폼에서 프로젝트 빌드를 수행할 수 있습니다. 서로 다른 플랫폼을 위한 다양한 프로젝트를 빌드할 수 있도록 CI 서버를 구성 및 조정할 수 있습니다. 지속적 통합 서버는 복잡한 워크플로우를 손쉽게 모델링 및 시각화하고(지속적 딜리버리 사용), 지속적 딜리버리 파이프라인을 빌드하기 위한 직관적 인터페이스를 제공합니다. 지속적 통합 서버는 다음과 같은 기능을 제공합니다.
- 한군데서 자동 빌드, 테스트, 배포 실행
- 어떤 버전이든 언제라도 배치
- 질서 있게 구성 관리
- 기능 확장을 위한 플러그인 지원
- 프로젝트의 저장소 모니터링
- 변경 사항 가져오기, 성공적인 커미트를 위해 정의한 태스크 수행
- 해당 프로젝트 멤버에게 빌드 세부 정보와 함께 피드백 전달
다음 가상의 유스 케이스에서는 두 명의 소프트웨어 개발자가 지속적 통합을 이용하여 DevOps 프로세스를 개선하는 방법을 보여줍니다.
이 두 개발자는 어떤 기능이 어떻게 작동하는지를 상대방에게 알려줘야 합니다. 이 소규모 팀은 정기적인 업데이트를 필요로 하며, 전체적으로 해당 코드를 통합하고 테스트할 수 있어야 합니다. 코드 체크인의 스케줄링과 테스트는 많은 개발 시간을 차지합니다. 지속적 통합을 위한 자동 시스템이 필요합니다.
이러한 조합과 테스트가 이루어지는 시점에 협상을 해야 한다면, 개발자의 시간을 많이 빼앗기게 됩니다. 이들은 다음과 같은 사항에 관해 합의해야 합니다.
- 코드 통합 테스트를 언제 시작할 것인가?
- 통합이 성공적이었음을 어떻게 테스트로 확인할 것인가?
- 그 결과를 팀에 어떻게 전달할 것인가?
지속적 통합 플랫폼은 이러한 물음에 대한 기본적인 답을 제시하며, 대부분은 구성 및 설정을 허용합니다.
일반적으로 Jenkins와 같은 CI 플랫폼은 체크인할 때 통합 테스트를 시작합니다. 신규 코드가 체크인되면, CI 시스템은 일련의 테스트를 실행합니다. 여기에는 유닛 테스트와 회귀 테스트가 포함될 수 있습니다. 그런 다음 코드가 성공적으로 통합되었는지를 확인합니다.
또는 컴파일된 언어를 사용하는 경우에는 코드가 성공적으로 컴파일되었는지를 기본 테스트를 통해 확인합니다. 그렇지 않은 경우, 새 코드가 빌드를 중단했습니다. Python, JavaScript 등과 같은 언어에서는 자체 통합 테스트를 생성해야 합니다.
어느 쪽이든 간에 CI 시스템 대부분은 통합 시도, 성공률, 기타 메트릭을 로그에 저장합니다.
테스트의 중요성
지속적 통합 빌드와 패키지(설치 가능 엔티티, 또는 패키지형 엔티티라고도 함)를 생성할 때 지속적 테스트가 시작합니다. 이는 패키징된 해당 엔티티가 프로덕션으로 이동할 때 중지됩니다. 처음부터 끝까지의 모든 단계에서 테스팅 솔루션을 사용합니다.
만약 테스트 단계가 하나 뿐이라면, 적어도 지속적 통합의 30%는 테스트가 차지합니다. 실제로 지속적 통합 활동은 50~70% 테스트로 구성됩니다. 예전에는 수동으로 테스트를 완료해야 했습니다. 지금은 (성공적인 지속적 통합의 핵심이라 할 수 있는) 자동화된 테스트를 이용하면 됩니다.
지속적 통합을 위한 자동 테스트의 일환인 테스트 기반 개발에서는 반복적으로 코드를 빌드하고 한 번에 하나의 유스케이스로 테스트하면서 테스트 범위를 보장하고 코드 품질을 개선하고 지속적 딜리버리를 위한 기반을 조성합니다. 자동화된 테스트는 새 코드가 애플리케이션의 모든 기능 영역에서 개발된 하나 이상의 테스트에서 실패했는지 여부를 알려줍니다. 베스트 프랙티스에서는 개발자가 로컬 환경에서 테스트의 전부 또는 일부를 실행하도록 요구하며, 이는 개발자가 새 코드 변경사항이 테스트를 통과한 후에만 버전 제어에 대해 소스 코드를 커미트할 수 있도록 보장합니다. 경험에 의하면, 효과적인 회귀 테스트를 통해 나중에 뜻밖의 문제가 생기는 것을 방지할 수 있습니다.
지속적 통합 파이프라인
지속적 통합 파이프라인은 프로젝트의 파이프라인 단계, 즉 빌드, 테스트, 배치 등을 반복 가능한 방식으로 자동화하면서 수작업을 최소화합니다. 자동화된 지속적 통합 파이프라인은 제어, 체크포인트, 속도의 측면에서 애플리케이션 개발, 테스트, 배치를 능률화합니다.
지속적 통합 베스트 프랙티스
지속적 통합 프로세스는 DevOps의 핵심 요소 중 하나입니다. DevOps는 개발 팀과 운영 팀이 소프트웨어 코딩, 테스트, 배치, 지원에 단일 저장소를 공유하면서 통합적으로 일할 수 있게 합니다. 성공을 뒷받침하는 CI 베스트 프랙티스 몇 가지를 소개합니다.
- 단일 소스 코드 저장소 유지: 소스 제어 관리를 통해 프로젝트 빌드를 위한 모든 파일을 추적하고 제어합니다. 이 통합 코드 베이스는 배포 및 가시성을 보다 간편하게 만듭니다.
- 빌드 자동화: 이를 위해 컴파일링, 링킹을 비롯하여 빌드 아티팩트를 생성하는 기타 프로세스가 수행됩니다. 자체 테스트도 역시 자동화되어야 합니다.
- 일일 메인라인 커미트 사용: 개발자가 반드시 매일 1회 이상 메인 개발 스트림에 변경 사항을 커미트하게 합니다. 각각의 개발자는 작업 사본이 기본 개발 스트림과 일치하는지 확인해야 합니다.
- 프로덕션 환경의 복제본에서 테스트: 테스트 환경을 최종 프로덕션 환경과 최대한 비슷하게 만듭니다.
- 배치 자동화: 빌드와 테스트를 실행하기 위해 여러 개의 환경(개발, 통합, 프로덕션)을 구현합니다.