들어가며
지속적 통합(Continuous Integration, 이하 CI)은 수년전부터 많은 이슈가 되어왔고, 상당한 성숙단계에 이른 개발 활동(Development Practice)입니다. CI는 대표적인 agile 개발 process인 extreme programming 의 개발 practice 중 하나로 포함되어 있고, Martin Fowler 는 2000년도에 이에 대한 글을 썼습니다(이 글은 2006년도에 다시 개정되었습니다). 손쉽게 CI 를 적용하기 위한 다양한 CI 서버들이 개발되었고, 현재 많은 프로젝트에 도입되어 성공적인 프로젝트 수행에 공헌을 하고 있습니다.
지속적 통합(Continuous Integration)
기존의 많은 개발 프로젝트들의 막바지 통합 과정은 참으로 지루하고 고통스러운 과정으로 묘사되고 있습니다. 개발자의 환경에서는 멀쩡하게 돌아가던 코드들을 통합 서버에 올리기만 하면 도대체 알 수 없는 에러들을 뱉어내고, 모듈 간 약속된 인터페이스는 어느사이엔가 변경되어 서로 연동이 되지를 않습니다. 시연은 당장 며칠 남지 않았는데 하나 고치면 다른데서 문제가 생기기 일쑤입니다.
이러한 고통스러운 통합과정의 문제를 해결하기 위해 Martin Folwer는 그의 글 Continuous Integration에서 기존 개발 단계의 후반에 수행되던 통합 활동을 일상적인 개발 활동에 자연스럽게 녹이는 CI를 해결책으로 제시합니다. CI 활동을 간단히 설명하면 다음과 같습니다.
- 개발자는 소스 저장소로 부터 최신 소스를 내려받습니다(check out).
- 개발자는 코드를 작성한 후 자신의 개발기에서 정상적으로 동작하는 지 충분히 검증합니다.
- 검증이 끝난 후 개발자는 작업 내용을 소스 저장소에 올립니다(check in).
- 개발자(또는 통합 관리자 또는 자동화된 시스템)는 통합 서버에서 방금 작업한 코드가 반영된 전체 코드 내용에 대한 빌드를 수행합니다.
- 만약 빌드가 실패할 경우, 실패 원인을 분석하고 문제를 해결하여 빌드가 성공될 수 있도록 합니다.
CI 가 이상적으로 수행된다면, 개발 막바지의 통합 작업이 필요가 없게 됩니다. 통합서버의 최신 빌드에는 개발자가 작업한 내용들이 자연스럽게 통합이 되어 있기 때문이지요. 2008년 JOLT 상을 수상한 책인 Continuous Integration: Improving Software Quality and Reducing Risk 에서는 CI 의 수행을 통한 주요 이점을 다음과 같이 제시하고 있습니다.
- 위험을 줄일 수 있다.
- 수동으로 수행해야 하는 반복 작업을 줄일 수 있다.
- 언제, 어느 장소에서도 배포 가능한 소프트웨어를 만들 수 있다.
- 프로젝트에 대한 더 나은 가시성을 제공한다.
- 개발팀에게 소프트웨어 제품에 대한 자신감을 불어넣는다.
이러한 목적을 달성하기 위해서 Martin Folwer가 제시하는 성공적인 CI 수행의 요건은 다음과 같습니다.
- 단일 소스 저장소(Source Repository)를 유지하라.
- 빌드를 자동화하라.
- 빌드가 자체적으로 테스트 가능하도록 하라.
- 모든 사람은 매일 작업 내용을 커밋(Commit) 하라.
- 모든 커밋들은 통합 서버의 메인 라인에 반영되어야 한다.
- 각 빌드가 빨리 수행되도록 하라.
- 운영환경과 되도록 비슷한 환경에서 테스트 하라.
- 최신 결과물에 쉽게 접근할 수 있도록 하라.
- 현 빌드 상황을 쉽게 알 수 있도록 하라.
위의 요건 중 일부는 개발팀의 업무 프로세스 정의와 같은 정책적인 부분이고, 일부 요건들은 시스템적으로 뒷받침 되어야 하는 부분입니다. 이 중 시스템적으로 뒷받침 되어야 하는 부분을 구현한 것이 CI 서버, 소스 버전관리 시스템과 같은 도구들 입니다. 본 포스팅에서 소개하는 CTIP도 이러한 시스템적 요건을 효과적으로 (그리고 손쉽게) 구성하기 위해 고안되었습니다.
CTIP 소개
CTIP은 CI 개념을 Java 기반의 개발 프로젝트에 쉽게 적용하기 위한 Platform 입니다. CTIP 이 제공하는 기능은 다음과 같습니다.
- CI 서버를 통한 지속적 통합 및 빌드
- 품질 도구들을 통한 코드 품질 검토( 테스트 및 정적 분석)
- 빌드 결과의 배포 및 관련자에게 통보
다음은 이를 도식화 한 CTIP 의 전체적인 구조입니다.
CTIP은 크게 코드 품질 관리 영역, 빌드 및 배포 관리 영역, 소스코드 버전 관리 영역, 그리고 대상 서버군으로 구성되어 있습니다. 다음은 각 영역에 대한 설명입니다.
- 소스코드 버전 관리: CVS, SVN 등의 소스코드 버전 관리 시스템을 사용하여 프로젝트 전체 소스코드의 일관성을 유지합니다. 개발자는 버전 관리 시스템의 repository로 부터 최신 소스를 check out하고, 작업내용을 check in 합니다.
- 빌드 및 배포 관리: CI 서버를 통해 지속적으로 빌드를 수행하고, 대상 서버에 대한 배포작업을 수행합니다. 빌드 주기는 정해진 시점에 수행하거나 (nightly build가 이에 해당합니다), 버전 관리 시스템의 repository에 변경이 있을 경우 즉시 수행될수 있습니다.
- 소스코드 버전 관리 시스템으로 부터 최신 소스를 받아옵니다.
- 코드 품질 관리 도구를 실행합니다.
- 빌드 결과를 개발자에게 통보합니다.
- 서버에 빌드된 어플리케이션을 배포합니다.
- 코드 품질 관리: 오픈소스 코드 검토 도구를 활용하여 코드 품질을 확인하고, 결과를 개발자에게 통보합니다. 다양한 오픈소스 및 상용 품질 관리 도구가 개발되어 있으므로 필요에 따라 선택하여 적용할 수 있습니다.
- 서버군: 운영 서버 배포를 위한 스테이징 서버, 테스트 실행을 위한 테스트 서버 등을 운영합니다.
CTIP의 각 영역에서는 적절한 도구를 선정하여 영역에서 필요한 기능을 제공해야 합니다. 다양한 오픈소스 및 상용 도구들이 개발되어 있기 때문에 특별한 기능이 필요하지 않은 경우, 구지 직접 이러한 도구를 개발할 필요는 없습니다. 도구는 도구 자체의 기능, 프로젝트 특성, 팀의 도구에 대한 익수함 등을 고려하여 선정합니다. 본 구현에서 선정한 도구는 다음과 같습니다.
- CI 서버: 대표적인 CI 서버인 CruiseControl을 사용합니다.
- 소스코드 버전 관리 시스템: 역시 유명한 소스코드 버전 관리 시스템인 Subversion 을 사용합니다.
- 빌드 시스템: XML 기반으로 간단히 빌드 스크립트를 작성할 수 있는 Ant 를 사용합니다.
- 품질관리 도구
- Glean: 다양한 품질 관리 도구를 쉽게 적용하고, 통합된 보고서를 생성하는 품질관리 도구의 관리 도구 입니다.
- JUnit: 대표적인 Java 단위 테스트 프레임워크입니다.
- Cobertura: JUnit 등의 단위 테스트에 대한 커버리지 측정 도구입니다.
- Checkstyle: 각 소스코드에 대하여 표준 소스코드 스타일 가이드의 준수 여부를 검토합니다.
- PMD: copy & paste 된 코드와 소스코드의 잠재적인 오류 사항을 검토합니다.
- JavaNCSS: Java 프로젝트의 size를 측정합니다.
- JDepend: Java 패키지의 설계 품질을 검토합니다.
그럼, CTIP을 적용하여 Martin Folwer이 제시한 CI 수행 요건을 어떻게 충족시킬 수 있을까요?
- 단일 소스 저장소(Source Repository) 관리: 소스코드 버전 관리 시스템을 도입하여 소스코드를 일관성있게 관리합니다.
- 빌드 자동화: CI 서버와 Ant 빌드 스크립트를 통해 빌드를 자동화합니다.
- 자체적으로 테스트 가능한 빌드: 코드 품질 관리 도구들을 통한 단위 테스트 등의 테스트 성공 여부와 서버의 deploy 성공 여부를 통해 빌드 성공 여부를 확인합니다.
- 빠른 빌드 수행: CI 서버와 Ant 빌드 스크립트를 통해 단계적 빌드(staged build)를 구성합니다.
- 운영환경과 유사한 환경 구성: CI 서버의 환경을 운영환경과 유사하도록 구성합니다.
- 최신 결과물에 대한 쉬운 접근: CI 서버를 통해 최신 빌드 결과물 및 빌드 리포트를 쉽게 내려받을 수 있습니다.
- 손쉬운 빌드 상태 모니터링: CI 서버가 제공하는 RSS feed 혹은 e-mail 전송 기능을 통해 빌드 상태를 모니터링할 수 있습니다.
출처 : http://www.sereform.com/?p=234
