프로젝트 소스 빌드툴 : Cruise Control

Cruise Control : 지속적인 빌드 관리 시스템

일일빌드와 통합소스관리를 통한 프로젝트의 혁신을 꾀한다면 SVN(Subversion)과 Ant같은 빌드관리툴의 사용이 필수적입니다. - MS에서 내놓은 소스 버전 컨트롤 툴들이 있기는 하지만 일단 오픈소스 관점에서 살펴보려고 합니다. 제가 아는게 이쪽 뿐이라 그런거니 다른 MS제품이 궁금하신 분께 양해를 구합니다. - 자바의 경우 Ant나 Maven을 주로 사용하겠고 C나 C++의 경우는 make를 이용하여 빌드를 할 것입니다. 이런 프로그램들은 목적 언어가 약간씩 다를지라도 프로그램을 빌드하기 위한 과정을 일괄처리 할 수 있도록 돕고 최대한 자동화된 처리과정을 제공하는 점에서 비슷한 기능을 한다고 볼 수 있습니다. 이들 프로그램은 프로젝트 빌드를 위한 충분한 기능을 제공하고 있지만 CVS(Concurrent Versions System)이나 SVN과 같은 버전 컨트롤 시스템을 사용하여 소스를 관리하고 UnitTest를 위한 TestCase를 포함하고 있는 프로젝트의 경우 항상 최신의 소스를 유지하면서 빌드하고 빌드 결과 뿐 아니라 테스팅 결과도 날마다 생성하게 하는 작업은 불가능합니다. 이와 같은 작업을 위해서 Shell Script로 비슷한 약할을 하는 프로그램을 작성하여 쓰기도 하는데 제가 오늘 소개해 드릴 Cruise Control은 이런 작업에서 최적화 되어있는 프로그램이며 간단한 설정으로 전체빌드 과정을 통제할 수 있습니다.

Cruise Control의 특징

• 소스저장소와 빌드소스를 동기화 시켜줍니다


• 빌드후 결과를 웹으로 보여주고 메일로 전송도 가능합니다


• UnitTest결과를 보고서로 보여줍니다

Cruise Control이 필요한 사람

현재 Cruise Control이 최대의 성능을 발휘할 수 있는 환경은 다음과 같습니다.

Ant혹은 Maven을 이용하여 빌드를 관리하는 프로젝트이며 CVS나 SVN을 통해서 소스통합과 버전관리를 하는 프로젝트. 더불어 UnitTest Framework를 사용하여 TestCase를 가지고 있는 프로젝트

Cruise Control Setting

Cruise Control Getting Started에 Cruise Control을 세팅하는 기본적인 부분이 나와 있습니다. 설정의 세세한 부분은 Getting Started 문서를 참조하시길 바랍니다. 이 글에서는 문서에는 나와 있지 않은 svn과의 연동 부분에 대해서 설명하려고 합니다.

문서에는 기본적으로 ant를 이용한 cvs와의 연동을 가정하고 설명하고 있습니다. 하지만 기본적으로 svn은 cvs에서 파생된 프로그램이라 봐도 무방하기 때문에 설정도 많이 바뀌는건 없습니다. 그리고 Cruise Control에도 기본으로 svn플러그인이 포함되어 있기 때문에 설정파일만 수정하면 간단하게 사용할 수 있습니다.

일단 제가 사용하는 config.xml 파일을 보면서 설명을 하겠습니다.

  
  
  
  
    
      
    

    
    
    

    
      
    

    
    
                 buildfile="/home/minfra/build-PCT.xml"
           target="build"
           uselogger="true"
           usedebug="false"/>
    

    
    

    
    
    
  

기본적으로 Getting Started에 있는 config.xml 예제와 같습니다. 수정된 부분은

이 부분이 추가된 것과

이 부분이 변경된 정도입니다. 나머지는 ant파일의 위치같은 사소한 수정이 있습니다.

위의 수정되거나 추가된 코드 부분이 svn을 위한 세팅입니다. 다른 프로젝트에 이 설정을 사용하더라도 위의 svn부분은 수정할 필요가 없습니다. 위의 코드들은 svn에 대한 세팅 정도만 표시되어 있기 때문에 실제 svn의 작업이 이루어지게 하는 부분이 필요합니다. 그 작업은 config.xml에 ant 파일로 지정된 파일에서 이루어집니다.

결국 config.xml을 통해서 빌드 시스템의 세팅이 이루어지고 실제 빌드 작업은 ant 태그에 설정된 build-PCT.xml을 통해서 이루어집니다(혹시나 해서 하는 말이지만 파일이름은 아무래도 상관없습니다). build-PCT. xml에 실제 프로젝트 빌드를 위한 루틴을 넣어도 되겠지만 관리의 편리성을 위해서는 실제 빌드를 위한 파일은 build.xml를 만들어 소스 디렉토리에 추가 시키고 Cruise Control을 위한 파일들은 외부에 두어 빌드 루프가 실행되도록 하는 것이 좋습니다.

build-PCT.xml

위 xml문서의 아래 부분을 통해서 checkout 되어 있던 소스디렉토리가 update되면서 프로젝트를 빌드하게 됩니다. 다만, 이와 같은 설정을 사용할 경우 미리 프로젝트 디렉토리를 관리자가 checkout 해 두어야 합니다.

Cruise Control 실행

모든 설명이 끝나면 세팅 완료 후 빌드 시스템을 실행시켜야 합니다.
문서에 나와 있는 것과 같이 INSTALL_DIR/main/bin/cruisecontrol.sh 를 실행시키는 것으로 실제 프로그램은 동작합니다. 다만 사용자가 직접 실행시킬경우 현재 화면에 실행되기 때문에 cruisecontrol.sh & 처럼 백그라운드로 실행시키거나 cron에 등록시켜 실행되도로 하면 됩니다.

Cruise Control은 소스 저장소를 확인하면서 변경된 사항이 있을 경우 로컬의 소스 디렉토리를 업데이트하고 새로 빌드합니다. 이때 소스 저장소를 확인하는 주기는 5분정도 입니다. 이로 인해 개발자가 소스를 커밋한 다음 이 소스가 실제 시스템에서 빌드되는데 약 5분정도의 지연이 있게됩니다. 그리고 성공적으로 빌드 되어을 경우 보고서를 작성하는데 빌드에 실패했을 경우에도 보고서를 작성하게 되므로 빌드에 실패한 소스를 고치지 않고 계속 방치할 경우 5분에 한번식 실패보고서가 만들어지게 됩니다. SMTP를 이용해서 email로 보고서가 전송되도록 했을 경우 하루만 방치하더라도 수십통의 메일이 오겠죠. 이런 황을 방지 하기 위해서 빌드 실패에 대한 책임을 미리 정해서(마지막 커밋한 사람이 책임지고 성공하게 한다던지, 실패를 본 처음 사람이 한다던지) 관리하면 최대한 성공적으로 빌드되는 소스를 보유할 수 있습니다.