빌드 자동화 하기 – CruiseControl.net

현재 개발하는데 사용하는 환경이 svn+trac이고 Windows 서버를 사용하고 있다(물론 XP이후의 Win32 환경이면 다 사용할 수 있는 상태지만…).

빌드가 자동으로 이루어지기 위해서 다음과 같은 구성을 쓰고 있다 (가장 효율적인 집합이랑은 거리가 좀 멀 것 같지만 )

• Machine A : svn 서버. trac 도 같은 서버를 사용한다 – trac 서버가 svn과 원격으로 있게 하는건 좀 어렵다.
• Machine B : 빌드를 수행한다. 

이런 개념으로 접근했었다. 실제로 빌드가 이뤄지는 시나리오는,

1. 누군가 소스를 수정하고 svn commit
2. A의 svn 서버의 post-commit 에 걸려있는 훅;hook 이 실행
3. 훅은 Machine B의 XML-RPC 서비스에 빌드 요청을 전달
4. Machine B에서 빌드를 시작
5. …미래의 어느 시점엔가 Machine A의 trac wiki의 빌드 상태 페이지를 누군가 열면 현재 상태를 B의 XML-RPC 서비스에 요청하고 현재까지 알려진 최신 빌드의 정보를 출력한다.

라는 것이다. 만약 강제 리빌드를 실행하게 되면 trac wiki에서 특정 페이지를 열면 해당 페이지의 trac-macro가 실행되고 그 매크로에서 forced-build라는 메시지를 XML-RPC로 전달하게 했다. 그 이후는 4~5의 반복.

여기서 문제는 바로 3~4의 연결문제와 5의 과정이 사람이 직접 접근해서 확인해야하는 과정이라는 것. 즉, 저 부분은 자동화가 이루어지지 않았다.

원하는 것.

• XML-RPC 같이 내가 직접 수정해야하는 – 지금은 trac macro와 빌드 서버 밑단이 python 코드 – 부분이 없거나 나 이외의 사람도 관리하기 쉬울 것 (명확한 문서화, 예제 등등)
• 실패한 빌드에 대해서 명시적으로  알려줄 것 (trac-wiki를 일일이 열어봐야하는 것 같은 것 말고)
• 전체 빌드를 기술할 때 Visual C++ 기반 프로젝트의 설정을 바꾸거나 추가하거나 제거하는게 쉬울 것
• svn에서 다른 SCM을 사용해도 쉽게 전환할 수 있을 것 (가능하면 SCM 계층과 커플링이 적을 것)

과 같은 조건이었는데 Rica 네 팀에서 설치해봤다는 CruiseControl.net 을 써보기로 하고 설치. 잘 알려진 오픈소스 Continuous Integration 툴인 CruiseControl의 .net framework 포트다† .

설치 과정 자체는  IIS, 빌드툴(이 경우엔 Visual Studio 2005), svn 그리고 CruiseControl.net 자체만 설치하면 끝.

IIS에 등록하는 과정도 CC.net이 알아서 해주는지라 쉬웠다 (다만 IIS 에러 메시지를 하나도 해석할 수가 없어서 ASP 1.1.x대신에 2.0.x로 설정하면 끝날 문제를 반나절 헤맸다…). 띄우고나서는 CC.net에 동봉된 문서를 따라서 설정을 하고 빌드가 이루어지는 것을 볼 수 있었다. CC-Tray라는 Win32용 태스크 바에 뜨는 트레이 프로그램을 제공하는데 현재 등록된 빌드들이 빌드성공/실패 여부를 알려주고 + 실패한 경우 누군가 자원해서 고치나를 알려주기 때문에 유용할 것 같다.

그리고 툴 자체가 Win32환경(특히 .net framework)에 최적화 되어있고, VS 200x의 솔루션 파일을 바로 빌드할 수 있는 태스크를 제공하기 때문에, 스크립트로 빌드하던 시절에서 좀 더 편한 방식으로(아무나 설정하기 쉬운) 옮겨갈 수 있게 된 듯하다.

실제 사용 경험은 팀에 좀 적용된 이후에 글로 써보도록 하겠다.

ps. 이걸로 하루 일과 종료(…)

*

† 비슷하게 로깅 라이브러리 log4j의 포트인 log4net, 빌드툴 ant의 포트인 Nant, 유닛테스트 프레임웍인 JUnit 포트인 NUnit 같은 툴들을 쓴다(…). 뭐 그래봐야 C++이라서 테스트 툴은 UnitTest++을 쓸 듯 하지만…