Hudson설치

CI(Continuous Integration) Server는 간단하게 설명하면(내가 이해한 바로는) 여러명이 작업하는 소스의 빌드의 성공/실패 여부를 자동으로 체크해 주는 어플리케이션이다. 공동 작업을 하면 개발되는 프로그램 소스의 관리가 필요한데 이때 svn, cvn등의 버전관리 프로그램을 사용하게 된다. 이것으로 소스는 공동관리가 가능하게 되지만 각 개발자가 커밋(repository에 소스를 반영 작업)하는 소스의 빌드(컴파일 및 link)에 대해서는 보장하지 않는다. 이를 보장해주는 어플리케이션이라 보면 된다.(라고 이해했다.) CI는 상용 및 오픈소스등의 여러버전이 있는데 팀에서 선택한 것은 hudson CI였다. Hudson은 설치는 매우! 간단하다. war파일을 내려받아 tomcat의 webapp폴더에 넣고 tomcat을 구동시키는 것으로 끝! CI의 서버의 사용 목적은 개발 중인 c++프로젝트를 적용시켜 운용하는 것이므로 공동 개발으로 svn에 관리중인 의 c++의 빌드가 가능하도록 하면 되는 것이었다. 서버에 hudson을 올리는 것 까지는 매우 순조롭게 진행 되었으나 빌더를 무엇으로 해야하는가를 결정하는데 시간이 많이 걸렸다. 처음에 물망에 올렸던 것은 MinGW, Cygwin 두가지였으나 MinGW는 기능이 너무 제한적이라 탈락, Cygwin은 Ace를 다시 빌드해야 하는 점이 맘에 안들고 귀찮아 탈락시켰다. 그럼...뭘 쓰지?? 이리저리 뒤져 본 결과 vs2005에서도 command line에서 빌드를 해주는 바이너리가 있다는 것을 알았다. 참 착하게도 프로젝트에 설정해 놓은 정보를 그대로 가져다 쓰기 때문에 따로 Path를 잡아주거나 할 필요가 없다는 사실! devenv가 바로 그놈인데 사실 .net의 경우에는 MSbuild를 사용하면 되지만 c++의 경우에는 devenv밖에 되지 않는다. devenv는 환경변수에 등록이 되어 있지 않았기 때문에 Tools폴더에 들어있는 환경변수를 설정해주는 bat파일돌리고 프로젝트 파일(vcprj)이 있는 곳으로 이동해 빌드를 하게 끔 설정해 두었다. 후훗... 여기서 천인공노할 MS의 버그(920770 : 나같이 숫자외우기에 젠병인 놈이 번호도 외웠다.)때문에 3일을 고생하고 sp1으로 패치하여 겨우 원하는 결과를 얻을 수 있었다. 이런 고생이 의미가 있는 것일까?