rein’s world

대충 어제를 기점으로 삽질은 완전히 끝난듯한데, 그 동안 CruiseControl.NET을 처음 깔아보는 프로그래머(=rein)가 할만한 삽질들을 정리해보겠다. 우선 설치 과정 전체는 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 기반 메이크 파일(…보다는 좀 더 MS Windows 스러운)이다. C# 같은 것은 소스 기반에서도 빌드할 수 있는 룰들을 제공한다. 그리고 이 안의 설정들의 경우 CruiseControl.NET에서 지정할 수 있는 것보다 좀 더 유연한 룰들을 제공하는데다가(조건부 컴파일이라거나…), 상대적으로 테스트하기가 쉽다. (MSBuild 의 메이크파일에 해당하는 XML 파일만 시험해보면 되니) 그리고 문서화가 잘되어있는 XML 형식이라 배치 파일보다 유지/관리가 쉽다.

뭐 이 정도가 지금 당장(…) 생각나는 설정 삽질이다. 이 이후에도 뭔가 삽질을 하면 포스팅 해보도록 하겠다(…).