지속적인 통합의 개념은 아래와 같습니다.
CI : Continuous Integration : 지속적인 통합
- 지속적으로 퀄리티 컨트롤(품질 관리)을 적용하는 프로세스를 실행하는 것.
- 모든 개발을 완료한 뒤에 퀄리티 컨트롤을 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점
- 초기에 그리고 자주 통합해서 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백사이클을 짧게 하여 소프트웨어 개발의 품질과 생산성을 향상시키는 것.
CI시스템이 어떻게 적용이 되는지 좀 더 자세히 살펴보도록 하겠습니다.
CI시스템을 구축하지 않은 경우에는 개발자들이 각자 개발한 소스코드를 형상관리 서버에 커밋하면 별도의 품질관리를 거치지 않고, 대부분 개발이 끝난 막바지에 통합을 하여 테스트를 진행하게 됩니다.
이런 경우, 개발 중 별도의 품질관리를 수행하지 않았기 때문에 잘못된 소스코드를 형상관리 시스템에 반영하였을 경우 발생되는 문제가 개발 후반에 모두 장애로 발견됩니다.
CI서버는 형상관리 서버에 Commit된 소스코드를 주기적으로 폴링하여 컴파일, 단위테스트. 코드 인스펙션 등의 과정을 수행하며 신규 또는 수정된 소스코드가 결함이 있는지의 여부를 지속적으로 검증합니다.
검증 결과는 이메일, RSS 등의 피드백 메커니즘을 통해 개발자들에게 전달되고, 이를 통해 조기에 결함을 발견하여 해결할 수 있는 것입니다.
이제, CI시스템 구축을 위한 핵심 구성요소에 대해서 살펴보겠습니다.
1. CI Server
- 빌드 프로세스를 관리하는 서버
- Jenkins, Hudson, CruiseControl.NET, TeamCity
CI시스템을 구축하기 위해서는 우선 CI 서버가 필요하겠지요. 오픈소스인 Jenkins가 가장 널리 사용되고 있는 CI서버입니다.
2. SCM(Source Code Management)
- 소스코드 형상관리 시스템
- 소스코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 도와줄 수 있는 시스템
- 여러사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 자동으로 동기화할 수 있는 시스템
- Subversion, Git, Mercurial
두번째, CI서버에서 자동으로 폴링하여 검증할 수 있도록 소스코드를 관리하는 형상관리 시스템이 필요합니다.
SVN(Subversion)과 Git이 가장 널리 사용되고 있습니다.
3. Build Tool
- 컴파일, 테스트, 정적분석 등을 실시해 동작 가능한 소프트웨어를 생성
- Ant, Maven, MSBuild, Make
세번째, 개발하는 언어에 맞는 빌드 툴이 필요합니다.
빌드란, 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정을 말하거나 그에 대한 결과물을 일컫는 것으로 빌드에 있어서 가장 중요한 단계는 소스코드 파일이 실행 코드로 변환되는 컴파일 과정입니다.
컴파일과 빌드를 혼동하여 쓰는 경우가 있으나 컴파일은 빌드 과정 중 한 단계일 뿐이며, 빌드는 형상관리 시스템에 있는 소스코드를 가져와 컴파일하여 사용자들이 실행할 수 있도록 실행 파일로 만드는 일련의 과정을 모두 포함합니다.
(참조 : 빌드의 중요성(http://softwaredev.tistory.com/10) / 빌드와 컴파일의 차이(http://allofsoftware.net/19)
4. Test Tool
- 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로, 빌드 툴의 스크립트에서 실행
- JUnit, CppUnit, CppTest, MSTest, Selenium(사용자테스트 자동화 가능)
네번째, 개발하는 언어에 맞는 테스트 툴이 필요합니다.
테스트는 단위 테스트를 말하며, 개발자라면 익숙한 JUnit(자바 애플리케이션의 단위 테스트 자동화를 위한 프레임웍)이 대표적입니다.
단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는 것으로, 개발자가 작성한 테스트 코드로 특정 메소드(Function)를 시험해보는 것이 일반적입니다.
다시 말해, 개발자가 작성한 메소드가 입력값에 따라 제대로 수행되는지 여부를 체크하는 것이지요.
단위테스트는 언어별로 자동화 테스트 도구들이 잘 만들어져 있어서 테스트코드 작성만 하면 자동으로 수행할 수 있습니다.
그 중 JUnit은 Ant와 같은 빌드 툴과도 쉽게 통합이 되기 때문에 가장 널리 사용되고 있습니다.
5. Test Coverage Tool
- 테스트 코드가 대상 소스 코드에 대해 어느정도 커버하는지 분석하는 도구
- Emma, Cobertura, TestCocoon
다섯번째는 테스트 툴과 함께 사용되는 테스트 커버리지 툴입니다.
테스트 커버리지 툴은 용어 그대로 개발자가 작성한 테스트코드가 테스트 대상 소스코드에 대해서 어느정도 테스트를 수행하는지를 코드 라인과 백분율을 통해 리포팅하는 것으로 단위테스트 수행 시 테스트 커버리지를 분석하기 위하여 부가적으로 사용하는 툴입니다.
6. Inspection Tool
- 프로그램을 실행하지 않고, 소스코드 자체로 품질을 판단할 수 있는 정적분석 도구
- 코딩 표준 준수 검사, 코드 메트릭 측정, 중복코드 검사, 코드 인스펙션 검사 등이 있음.
- CheckStyle, FindBugs, Cppcheck, Valgrind
마지막으로 인스펙션 툴이 필요합니다.
인스펙션 툴은 정적분석 도구로, 프로그램을 실행하여 분석하는 동적분석(JUnit도 일종의 동적 분석에 속함)과는 달리 소스코드 자체로 프로그램 상의 예상되는 잠재적인 결함을 검출하는 도구입니다.
정적분석의 개념과 도구에 대한 내용은 추후에 별도의 포스트로 작성하도록 하겠습니다.
3~6번의 도구는 XML 형태의 빌드 스크립트(Ant 등)로 수행 내용을 작성하여 CI서버에서 형상관리 서버에서 폴링한 소스코드를 빌드하면서 자동으로 수행됩니다.
빌드 스크립트를 통한 CI 자동화 수행 절차 예시는 아래와 같습니다.
1. 소스코드를 바이너리 파일로 컴파일 한다.
2. 바이너리 파일을 배포 형태로 패키징 한다.
3. 단위테스트(커버리지 포함)수행한다. (선택)
4. 정적분석을 수행한다. (선택)
5. 분석 결과를 리포팅 한다. (선택)
6. 패키징한 파일을 테스트 서버에 배포한다.