Blog

‘프로그래밍 노트’ 원고를 쓸 때 참고하려고 미리 써놓은 원고를 살펴보니, ‘참 갈 길이 멀구나’라는 생각이 든다. 그래서 이번 시간엔 서문을 줄이고 진짜 이야기를 해볼까 한다. 단 그 전에 한가지만 복습해보자.

저장소에서 소스 코드를 빌드 서버에 내려 받는데, 이때 디렉터리 구조는 다음과 같아야 한다. 프로젝트 이름과 프로젝트의 플랫폼(Platform) 및 설정(Configuration)에 맞춰 디렉터리를 따로 만든다. 이래야 각각을 병렬로 빌드할 수 있고, 각 빌드 산출물이 다른 빌드를 망치는 일도 줄어든다.

[프로젝트 이름]-[플랫폼]-[설정]
C:\src\MyProject-Win32-Debug
C:\src\MyProject-Win32-Release
C:\src\MyProject-x64-Debug
C:\src\MyProject-x64-Release

또한 소스 코드를 저장소에서 받아올 때 Trunk 디렉터리만 가져오지 말고 저장소 전체를 가져오는 편이 좋다(보통 저장소 디렉터리는 크게 Trunk, Branch, Tags로 나뉜다). 형상 관리의 원칙에 따르면 Trunk 디렉터리에 지금 개발하는 소프트웨어 버전과 관련된 모든 자산이 있어야 한다. 달리 말하면, 지속적인 통합을 할 때 Trunk 디렉터리만 사용해야 제대로 하고 있다는 뜻이다. 그럼에도 불구하고 전체 디렉터리를 가져오라 말하는 이유는, 운이 나쁘면 일시적으로나마 Branch나 Tags 디렉터리에 있는 소프트웨어 자산을 이용해 빌드해야 할지 모르기 때문이다. 예를 들어, 팀 구성원 중 한두 명을 다음 이정표(Milestone, 마일스톤) 때 추가할 기능에 먼저 투입하는 경우가 생길 수 있다. 이런 경우라면 현재 진행 중인 프로젝트(Trunk)를 Branch 디렉터리에 따로 떼어내야 할지 모른다. 물론 100% 원칙대로 지속적인 통합을 수행하려면, 분기(Branch)하는 정도로 만족할 게 아니라 아예 새로운 저장소와 프로젝트를 만들어야 하지만, 두세 달 후에 주 프로젝트(Trunk)와 병합할 텐데 지나치게 노력을 들이는 것도 피곤한 일이다.

CruiseControl .NET 설치하기

우선 CruiseControl .NET 웹 사이트(http://ccnet.thoughtworks.com/)를 방문해 새 버전의 배포판을 다운로드 받자. 여기서는 1.3.0.2918 버전을 받아서 설치한다. 물론 독자들이 이 글을 읽을 때쯤엔 새 버전이 나와있을 수 있다. 하지만 걱정하지 않아도 된다. 새 버전이 나오더라도 기능이나 사용법이 크게 바뀌는 경우는 거의 없었다. 그저 새로 출시된 버전 관리 시스템이나 빌드 스크립트 등을 지원하는 정도에서 그치기 때문이다.

CruiseControl .NET을 설치하는 건 쉽다. 윈도우 인스톨러 형태로 묶어서 제공하므로 그저 마우스 버튼만 계속 누르면 된다.

CruiseControl .NET은 32비트 바이너리만 배포한다. 그러므로 64비트 WOW 윈도우 운영체제에 CruiseControl .NET을 설치하면 아마도 “C:\Program Files (x86)\CruiseControl.NET”에 바이너리가 설치될 것이다. 설치가 끝나면 바탕화면에 CruiseControl .NET을 콘솔 서버로 실행시킬 수 있는 바로가기 아이콘이 하나 생기고, 시작 메뉴에는 문서 바로가기와 설정 파일 바로가기가 만들어진다.

[그림 1] CruiseControl .NET을 콘솔 모드로 실행시키기

이제 바탕화면에 있는 아이콘을 클릭해서 CruiseControl .NET을 실행시켜보자. [그림 1]과 같이, 검은 색 콘솔 화면이 열리고, CruiseControl .NET이 기동하는 과정을 영문 로그로 하나하나 확인해볼 수 있다. 만약 CruiseControl .NET의 설정 파일(CCNet.config)에 문제가 있으면 콘솔 창이 열렸다가 순식간에 닫힌다. 이와 관련된 문제는 나중에 알아보기로 하자. 지금은 설정 파일을 건드리지 않았으니, 서버 포트( [그림1]에서는 21234 )를 다른 애플리케이션이 쓰고 있지 않다면 이렇게 창이 닫힐 일은 없다.

CruiseControl .NET는 크게 두 부분으로 나뉘는데, 하나는 방금 실행한 서버 인스턴스이고 다른 하나는 웹 대시보드이다. 서버 인스턴스는 소스 코드 저장소에 새로운 코드가 들어왔는지 확인하고, 새 코드를 빌드 서버에 내려 받아서 빌드를 돌리고, 단위 테스트를 하는 등의 일을 한다. 사실상 빌드 서버 그 자체이다.

웹 대시보드는 서버 인스턴스가 이렇게 빌드한 결과를 웹 브라우저를 통해 확인할 수 있게 해준다. CruiseControl .NET 웹 대시보드는 서버 인스턴스가 떠 있어야만 접근 가능해진다. 서버 인스턴스부터 실행시킨 다음, 웹 브라우저를 열어 주소창에 http://내웹사이트주소/ccnet 를 치면 [그림 2]와 같이 웹 대시보드가 뜬다. 원래는 첫 웹 페이지에 프로젝트 정보가 제시되어야 하지만, 아직 설정 파일에 아무런 내용을 적어 넣지 않았으니 별다른 정보를 제공해주지 않는다.

[그림 2] 웹 대시보드

말로만 설명할 게 아니라 실제로 확인해보자. “C:\Program Files (x86)\CruiseControl.NET”에 들어가면 [그림 3]과 같은 모습을 볼 수 있다.

[그림 3] CruiseControl .NET의 디렉터리 구조

각 디렉터리를 간단히 설명하자면, CCTray는 빌드 상황을 볼 수 있는 닷넷 프레임워크 기반의 윈도우 트레이 아이콘 애플리케이션이다. cctray 디렉터리는 이 애플리케이션을 웹을 통해 배포하기 위한 장소다. Examples 디렉터리엔 말 그대로 CruiseControl .NET 설정 예제가 들어 있는데, 사실 CruiseControl .NET의 배포판이나 웹 사이트에 있는 문서 자체가 예제 위주로 꾸며져 있기 때문에 Examples 디렉터리에 있는 파일을 참고할 일은 거의 없다. server 디렉터리엔 서버 인스턴스의 바이너리가 들어 있고, webdashboard 디렉터리엔 웹 대시보드가 들어 있다. CruiseControl .NET의 디렉터리를 앞으로 자주 방문하게 될 테니 그 구조를 눈에 익혀두는 편이 좋다.

CruiseControl .NET 실행 모드

CruiseControl .NET은 콘솔 모드와 서비스 모드 둘 다 지원한다. 콘솔 서버로 띄우려면 바탕화면의 바로 가기를 누르면 된다. 콘솔 모드는 앞서 [그림 1]에서 살펴봤다. 그리고 서비스 모드로 CruiseControl .NET을 실행시키려면 [제어판 – 관리 도구 – 서비스 – CruiseControl .NET]을 선택하고, 시작 유형을 자동이나 수동으로 바꾼 후 ‘시작’ 버튼을 누르면 된다. 서비스에 익숙하지 않은 독자를 위해 부연하자면, ‘자동’으로 하면 윈도우가 부팅될 때 CruiseControl .NET도 실행된다.

각각의 모드엔 장단점이 있는데, 서비스 모드를 사용하면 윈도우 서버가 부팅될 때 사용자 세션이 로그인되어 있지 않더라도 CruiseControl .NET이 실행된다.

콘솔 모드를 사용하면 CruiseControl .NET을 시작 프로그램에 등록해놔도 서버가 재부팅될 때 사용자 세션 로그인을 하지 않으면 프로그램이 실행되지 않는다. 이 문제를 해결하려면 윈도우 자동 로그인 옵션을 선택해야 하는데, Windows 2003 Server는 보안 상의 이유로 이 옵션이 비활성화해 놓았다. 자동으로 로그인하게 만들려면, 여러 방법이 있지만 Sysinternals 사이트(http://technet.microsoft.com/en-us/sysinternals/)에 가서 Autologon을 다운로드 받는 게 가장 편하다. Autologon은 151킬로바이트 밖에 안 되는 간단한 exe 바이너리 파일인데, 실행시키면 윈도우 사용자 계정과 암호를 입력하는 창이 뜬다. 여기에 적절한 값을 입력해주고 Enable 버튼을 눌러주면, 자동 로그인 관련 레지스트리 값을 알아서 바꿔준다(그림 4). 이 말을 다시 풀어보자면, 여러분이 직접 레지스트리를 손봐도 된다는 뜻이지만, 불편할뿐더러 사람이 실수할 여지가 있으니 이런 도구를 쓰는 편이 좋다.

[그림 4] Autologon

개인적으론 서비스 모드보단 콘솔 모드를 추천한다. 보안 설정을 하나 허물어야 한다는 단점이 있지만, CruiseControl .NET에 문제가 생겼을 때 뭐가 잘못됐는지 바로 오류 메시지를 볼 수 있다는 게 너무나 큰 장점이기 때문이다. 서비스 모드는 사용자 인터페이스를 따로 제공하지 않기 때문에 문제가 발생하면 파일 로그를 일일이 확인해봐야 한다. 이런 불편함을 감수하려면 참을 인자를 세 번 쓰는 것으론 부족하다.

콘솔 모드를 추천하는 또 다른 이유는 단위 테스트를 해야 하기 때문이다. 대부분의 단위 테스트 실행기(Runner)나 테스트 코드 자체가 콘솔 모드에서 돌아가기 때문에, 윈도우 세션 로그인을 반드시 해야 한다. 어차피 세션 로그인을 해야 할 것이라면, 서비스보단 콘솔이 낫다. CruiseControl .NET에 문제가 발생했을 때, 서비스 모드보단 콘솔 모드가 대처하기 쉽기 때문이다. 서비스 모드에서 문제가 생기면 [관리 도구 – 이벤트 뷰어]를 통해 오류 로그를 확인해야 한다. 그에 반해 콘솔 모드는 문제가 생겼을 때 바로 콘솔 창에 오류 메시지가 나오기 때문에 원인을 파악하기 쉽다.

CCTray 설치하기

http://내웹사이트주소/ccnet 에 접속해서 왼쪽 상단 메뉴를 살펴보면 Download CCTray 라는 메뉴가 보인다. 앞서 설명했듯, CCTray는 빌드 상황을 실시간으로 받아 개발자에게 알려주는 트레이 아이콘 프로그램이다. CCTray에는 빌드 상황을 확인하는 기능뿐 아니라 강제로 빌드를 실행하게 만드는 기능도 있다. 보통 때는 각 개발자가 쓰는 로컬 컴퓨터에 설치해놓고, 빌드가 깨졌을 때 통보를 받는 용도로 쓴다. CruiseControl .NET을 설치하고 설정하는 현 시점에선 빌드 상황을 확인하는 용도로 쓰기 보단, 강제로 빌드를 시켜보고 그 결과를 확인하는 용도로 쓰게 될 것이다. 물론 웹 대시보드에도 동일한 기능이 있지만, 빌드 상황을 실시간으로 돌려받지 못하므로 매번 새로 고침(F5) 버튼을 눌러줘야 하고, 웹 브라우저를 실행시켜야 하니 불편하다.

[그림 5] CCTray에 서버 등록하기

CCTray를 설치했으면 빌드 상황을 감시하고 싶은 프로젝트를 등록해야 한다. [File – Settings – Build Projects – Add – Add Server]를 차례대로 선택하면 [그림 5]와 같은 메뉴가 뜬다. 기본 값이 “Connect directly using .NET remoting”인데, 여기에 빌드 서버의 네트워크 주소를 적어주면 된다. 닷넷 리모팅이 아닌 웹 URL을 이용해서 CruiseControl .NET에 연결할 수도 있지만, 오직 닷넷 리모팅 방식만이 빌드 강제하기(Force Build) 기능을 제공한다. 참고로 웹 대시보드를 통해(Via the CruiseControl .NET dashboard) 빌드 상태를 확인하고 싶다면, http://내서버주소/ 가 아닌 http://내서버주소/ccnet, 다시 말해 웹 대시보드의 URL을 정확히 적어줘야 한다.

[그림 6] CCTray로 빌드 상황 보기

CruiseControl .NET를 버전 관리 저장소에 넣기

모든 소프트웨어 자산은 반드시 버전 관리 저장소에 넣어 관리해야 한다. 이때 ‘반드시’라 함은 기술적인 측면을 말하는 게 아니라 ‘지속적인 통합’이란 실천 방법의 측면을 말하는 것이다. 이를테면, 운이 나빠 잘 쓰던 하드디스크가 어느 날 갑자기 망가졌다고 해보자. 하드디스크를 교체하고 운영체제를 다시 설치한 다음, 기본적인 개발 도구(이 경우엔 비주얼 스튜디오)를 설치한다. 이제 단위테스트 라이브러리 최신 버전과 데이터베이스 드라이버 최신 버전을 다운로드 받아 설치하고, 소스 코드를 내려 받으면 끝이다.

아니, 잠깐만! 뭔가 이상하다. 어디가 이상한 걸까? 어째서 최신 버전을 다운로드 받은 걸까? 프로젝트에서 NUnit 2.2를 쓰고 있는데, 혼자 NUnit 2.4를 받아서 쓴다면 어떻게 될까? 사실 아무런 문제가 없을 수도 있다. 하지만 운이 나쁘면 멀쩡한 단위테스트 코드가 깨질 수도 있다. 이것은 실제로 며칠 전에 직접 겪었던 문제다. 새 프로젝트에 NUnit 최신 버전을 적용했더니 단위테스트 코드가 깨졌다. 한참을 고민하고 나서야 NUnit 2.4의 버그란 걸 알았다. 실제로 NUnit 2.2에서 똑같은 단위테스트 코드를 돌리니 아무런 문제가 없었다.

이런 경우도 있을 수 있다. FTP 라이브러리를 구매해서 쓰는데, 어느 날 갑자기 라이브러리를 제공하던 회사가 문을 닫았다. 전에는 웹을 통해 손쉽게 다운로드 받을 수 있었기 때문에 마침 저장해놓은 소스 코드도 없는 상황이다. 이럴 땐 어떻게 해야 할까?

이렇듯 프로젝트에 맞는 도구를 배포하고, 개발자 개인이 프로젝트 표준에서 벗어나지 않게 하려면 모든 자산을 한곳에 저장해야 한다. 이렇게 프로젝트에 필요한 모든 소프트웨어 자산을 버전 관리 저장소에 넣어놔야 만일의 사태에 대비하고, 개발자들이 편리하게 개발 도구를 내려 받을 수 있다. 물론 이런 원칙에도 예외는 있어서, 비주얼 스튜디오 같은 기가바이트 단위의 애플리케이션을 버전 관리 저장소에 넣었다간, 저장소가 버티질 못한다. 하지만 이런 경우이더라도 프로젝트용 공유 드라이브를 따로 둬야 한다. 결국 소프트웨어 자산을 한데 모아야 한다는 점은 변하지 않는다.

이러한 원칙에는 예외가 없어서, CruiseControl .NET 같은 빌드 서버의 바이너리와 설정 파일도 버전 관리 저장소에 넣어야 한다. 분산 빌드를 하기 위해 똑 같은 빌드 서버를 다른 컴퓨터에 설치해야 할 수도 있고, 운 나쁘게 멀쩡하던 빌드 머신이 하룻밤 사이에 벼락을 맞아 생을 다할 수도 있다. 그러니 방금 설치한 CruiseControl .NET을 서브버전에 올려놓자. “C:\Program Files (x86)\CruiseControl.NET” 아이콘 위에 마우스를 대고 컨텍스트 메뉴를 연다(그림 7). TortoiseSVN의 임포트(Import) 메뉴를 찾아 실행시키고, 적당한 저장소 경로를 입력해주면 된다. 단 “C:\Program Files (x86)\CruiseControl.NET\Server\ccnet.log” 파일은 계속 변경되는 로그 파일이니 Import 대상에서 제외시킨다.

임포트를 마쳤으면 기존 CruiseControl .NET 디렉토리의 이름을 살짝 바꾸어(예, CruiseControl.NET-tmp) 놓고, 저장소에 방금 올린 파일을 다시 체크아웃(Checkout)한다. 체크아웃이 잘 됐으면 임시 디렉토리를 삭제한다.

참고. CruiseControl .NET 디렉터리는 최대한 빨리 임포트(Import)하는 게 좋다. CruiseControl .NET을 한참 운영하다가 임포트하려고 하면, 커밋해선 안 되는 파일(로그 등)을 가려내야 하기 때문에 힘들다.

[그림 7] 빌드 서버를 저장소에 넣기

Visual Studio 2005 설치하기

다시 말하지만, 이 칼럼은 현재 널리 쓰이는 Visual Studio 2005 Professional Edition을 기준으로 삼는다.

Visual C++ 프로젝트나 .NET 프로젝트(예, C#, VB.NET)을 다룬다고 가정했으니 당연히 Visual Studio를 빌드 머신에 깔아야 한다. 아니, 사실은 Visual Studio가 없어도 빌드할 수 있다. 마이크로소프트 웹 사이트에서 .NET Framework SDK나 Platform SDK를 다운로드 받아 설치하면 굳이 Visual Studio를 설치하지 않아도 된다. 하지만 라이센스 문제가 없다면 Visual Studio를 설치하는 편이 낫다. ‘IDE에 의존하지 않아야 한다’라는 지속적인 통합의 원칙을 깨는 것이긴 하지만 그럴만한 이유가 있다.

우선 웹에서 다운로드 받은 SDK와 Visual Studio와 함께 배포된 SDK가 미묘하게 다를 수 있다. 물론 이 문제는 해결하기 어렵지 않아서 조금만 세심하게 버전을 확인해보면 된다. 참고로 Visual Studio 2008로 넘어오면서, 기존에 비주얼 스튜디오 디렉터리에 포함되었던 SDK 디렉터리(예, C:\Program Files\Microsoft Visual Studio 8\SDK)가, 외부로 빠져 나왔다(예, C:\Program Files\Microsoft SDKs).

하지만 진짜 문제는 이보다 훨씬 골치 아프다. Visual Studio는 프로젝트를 빌드할 때 필요한 자원(예, SDK)의 경로를 환경 설정 값으로 갖고 있다. Visual Studio를 실행시키고 [도구 – 옵션 – 프로젝트 및 솔루션 – VC++ Directories] 메뉴를 열면, 어떤 경로를 사용하는지 알 수 있다. 대충 봐도 수십 개의 경로를 사용한다는 걸 알 수 있다. 만약 IDE에 100% 독립적인 빌드 서버를 만들려면, 이러한 경로를 모두 설정해줘야 한다. 처음부터 이런 성가신 일을 해내려는 마음가짐은 가상하긴 하지만, 그러다 지쳐 쓰러지는 수가 있다. 혹, 그래도 “이왕 할거라면 제대로 해야겠다”라는 사람을 위해 간단한 팁을 하나 더 알려주겠다. [도구 – 옵션 – 프로젝트 및 솔루션 – VC++ Project Settings] 메뉴를 열어서 “Show Environment In Log” 값을 Yes로 바꾼 후에, Visual C++ 프로젝트를 빌드해 본다(그림 8). 그러면 출력 창에 빌드 로그 파일이 저장됐다는 메시지(예, “Build log was saved at file://d:\src\project\Debug\BuildLog.htm”)가 뜨는데, 이 파일을 열면, 빌드 때 사용하는 환경 설정 값을 한번에 알아낼 수 있다(그림 9).

[그림 8] 빌드 환경 설정 알아내기

[그림 9] 출력 창에서 빌드 로그 확인하기

좀더 미묘한 문제도 있다. Visual Studio 바이너리 파일(devenv.exe)가 없으면 보통 msbuild 바이너리를 써서 프로젝트를 빌드하게 된다. 그런데 msbuild는 “설치 프로젝트(Setup Project)”(확장자 .vdproj)를 빌드하지 못하고 다음과 같은 오류 메시지가 뜬다.

MSB4078: 프로젝트 파일 "HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj"은(는) MSBuild에서 지원하지 않으므로 빌드할 수 없습니다.

만약 설치 프로젝트를 써서 애플리케이션을 배포하려고 한다면, Visual Studio 바이너리가 있어야 한다(이 문제는 나중에 좀더 자세히 알아보기로 한다).

설치 프로젝트와 비슷한 경우겠지만, Visual Studio 2005부터 IDE와 통합되어 제공된 MSTest를 빌드 서버에서 돌리려고 해도 비주얼 스튜디오부터 설치해야 한다. 이래저래 빌드 서버에 비주얼 스튜디오를 설치해야 할 이유는 많다.

앞서도 언급했지만 지속적인 빌드, 빌드 자동화를 할 때 가장 중요한 원칙 중 하나가 ‘IDE에 의존하지 않아야 한다’라는 것이다. 하지만 Visual C++을 주로 쓰는 개발 환경이라면, 어쩔 수 없이 IDE에 의존해야 하는 것이 현실이다. 아무리 좋은 원칙이라도 도저히 지킬 수 없는 상황이라면, 융통성 있게 상황에 맞춰가야 한다. 다만, 어떤 부분이 IDE에 의존하는지 주의 깊게 살펴보고, 그런 부분을 최대한 분리시키려고 노력해야 한다.

부록. 지속적인 통합 팁 – CCNetConfig

곧 알아보겠지만 CruiseControl .NET은 XML 설정 파일을 사용한다. 다행히 문서에 예제가 많고 설명이 잘 되어 있는 편이라 설정하기가 그리 어렵진 않다. 하지만 매번 문서를 보면서 작업하기 귀찮다면, 깔끔한 그래픽 사용자 인터페이스를 제공하는 CCNetConfig(http://www.codeplex.com/ccnetconfig)을 써보자. 특히 CruiseControl .NET을 처음 쓰는 초심자에게 반가운 도구가 될 것이다. 벌써 CruiseControl .NET XML 설정 파일에 눈이 익은 사람에게도 도움이 될 텐데, 미처 그런 기능이 있는 줄 모르고 있었던 부분이나 새 버전이 나오면서 추가된 기능을 금새 눈치챌 수 있기 때문이다.

[그림 10] 빌CCNetConfig

하지만 CCNetConfig는 64비트 윈도우에서 제대로 동작하지 않는다. 이슈가 보고된 지 꽤 되었지만 아직(버전 0.5.0.120 Production)은 해결되지 않았다. 이 연재 글에서는 빌드 서버를 64비트 WOW 시스템에 설치하고, 64비트 애플리케이션 개발 시에 발생하는 여러 문제를 탐구해볼 것이므로, 앞으로 CCNetConfig를 이 글에서 볼 일은 없으리라 생각한다. 그러나 32비트 애플리케이션을 개발하는 경우라든가, CruiseControl .NET 같은 XML 기반의 빌드 서버에 익숙하지 않은 사람이라면 CCNet이 훌륭한 동반자가 되어주리라 생각한다.