rein's world

CruiseControl.NET 삽질 정리

어제를 기점으로 작업이 마무리 되어서, 그 동안 CruiseControl.NET을 처음 깔아보면서 할 법한 실수들을 정리해보았다. 우선 설치 과정 전체는 KAISTIZEN 님의 CruiseControl.NET 설치 일지 를 따라 갔다. 전체 과정이 잘 정리되어있으니 매우 유용한 페이지다.

IIS 설정 삽질

IIS 설정에서 ASP.net 의 버젼을 1.1.x 대신에 2.0.x 이상을 사용해야 한다. 그렇지 않으면 IIS에 등록한 파일 형식이 이상하다는 식의 에러를 뱉는다(그것도 로컬 접속에서만 볼 수 있는 형태)

통계 기능 사용하기

기본적으로 이 기능이 꺼져있는데,, 이 기능을 통해서 구현되는 페이지 – 각 프로젝트(ccnet.config의 Project 섹션에 대응)의 Statistics 페이지 – 의 경우 예쁘지 않은 예외;exception을 던지면서 죽는다. 프로젝트 설정에

<publishers>
  <xmllogger/> <!-- for CC.NET -->
  <statistics/> <!-- for statistics page -->
</publishers>

이런 부분이 들어가 줘야 한다. 작업할 때 메일링 리스트만 보고 <statistics /> 항목만 추가 해줬더니 이젠 전체 히스토리 페이지에서 예외가 발생했던 것. xmlloger 를 발행하는 부분이 CC.NET 전체의 히스토리나 로그 뷰를 제공하기 때문에 저 부분이 빠지면 제대로 안되는 것에 주의.

UnitTest++ 연동

이 부분은 전혀 감이 안잡혔는데, 이 역시 KAISTIZEN 님의 UnitTest++ 연동 부분을 따라했다. 여기서도 삽질한 부분이 있다. 위의 연속이긴 한데, 로그 파일 합치는 부분(merger)을 나중에 추가 했다고 publishers 부분의 뒷부분에 붙였더니 제대로 출력이 되질 않는다. 즉, 다음과 같은 순서가 되야 한다.

<publishers>
  <merge>
    <files>
      <file>Path_To_UnitTest++\Output\XmlFile.xml</file>
    </files>
  </merge> <!-- merge가 xmllogger보다 앞임 -->
  <xmllogger/>
  <statistics/>
</publishers>

실제 xmllogger가 처리하는 부분이 우리가 실제로 보게되는 페이지 – 에 해당하는 xml 출력이 – 라서 그 부분 이전에 빌드 결과가 xmllogger에 의해 처리되어버리면 UnitTest++결과를 볼 수 없다. 그러니 순서에 주의.

다만 전체 통계 페이지에서도 통계를 보고싶은데 오늘 수정한 xsl이 제대로 동작하지 못하는 것인지 통계를 제대로 못 얻어내더라(테스트 결과에 대한 것들에 대해서). 이건 해결하게되면 다시 포스팅을 하던가 해야.

C++ 빌드 방식에 대한 첨언

이건 삽질했다기보단 Visual C++ 기반으로로 빌드를 해야해서 좀 선택하거나 고민할게 많아서 써보는 얘기다. CruiseControl.NET이 C#을 위해서는 정말 완벽한 지원 – 특히 NAnt와 NUnit 지원이 멋짐 – 이지만 C++의 경우엔 저렇게 널리 쓰인다고 할만한 빌드 팩키지가 없다. 그래서 그런지 몇 가지 대안으로 쓸만한 것들이 존재한다.

  • <exec> task – 말그대로 커맨드라인에서 뭔가 실행시켜주는 태스크다. 처음엔 batch 파일을 이걸 이용해서 실행시켜서 빌드했다 – 이전에 trc / svn / XML-RPC를 모두 결합시켜서 post-commit 훅으로 빌드했었기에. Batch 파일 하나 실행시키면 되는 거기 때문에 상대적으로 빌드를 테스트하기도 쉽고 설정 부담도 적지만, 언제나 그렇듯 batch 파일은 유지보수가 힘들다[…].
  • <devenv> task – DevEnv.com은 VisualStuiod.Net 을 실행시켜주는 쉘 비슷한 녀석이다. 이놈을 직접 호출해서 빌드하는 방식 – 예를 들어 devenv.com some_solution.sln /build DEBUG – 을 쓸 수 있게 해준다. 다만 기본값이 rebuid 라서 빌드 트리 일부에 있는 라이브러리 부분 등을 모두 다시 빌드하는건 원치않기도 했고, nightly-build도 아닌 CI로만 활용할 때엔 좀 괴롭기 떄문에 잘 취사 선택해야한다. 별로 설정할게 없어서 편하긴한데, ccnet.config 에 추가해야할 줄이 무지 많다. 솔루션이 추가될 때마다 CruiseControl의 설정을 건드려야 하는 것도 문제고, 빌드 자체가 안될 때 디버깅 하기도 좀 난감하다.
  • <MSBuild> task – devenv를 좀 찔러보다가 일단 현재 도착한 장소가 여기. MSbuild 는 .NET 프레임웍에 포함되어있는 툴인데 XML 기반 makefile(…보다는 좀 더 MS Windows 느낌의)이다. C# 같은 것은 소스 기반에서도 빌드할 수 있는 룰들을 제공한다. 그리고 이 안의 설정들의 경우 CruiseControl.NET에서 지정할 수 있는 것보다 좀 더 유연한 룰들을 제공하는데다가(조건부 컴파일이라거나…), 상대적으로 테스트하기가 쉽다. (MSBuild 의 메이크파일에 해당하는 XML 파일만 시험해보면 되니) 그리고 문서화가 잘되어있는 XML 형식이라 배치 파일보다 유지/관리가 쉽다.