시스템에 대한 지속적인 통합 을 나타내는 이 단어는 여러 개발자들이 한 시스템을 개발할 때 초기부터 통합을 하지 않고, 개발 후기에[필요할 때] 통합을 함으로써 나타나는 문제를 미연에 방지하고자 하는 개념입니다. [물론 꼭 저런것만 방지하기 위해 나온 개념은 아닙니다. 자세한 정보를 얻고 싶으면 http://xper.org/wiki/xp/ContinuousIntegration 방문해보세요]
밑에서 쓰이는 얘기들은 지극히 개인적인 경험과 제가 하고 있는 프로젝트의 성격에 의존적인 얘기라 생각됩니다. 유념해주세요 :D
Contiuous Integration (이하 CI)를 하기 위한 툴은 시중에 많이 있습니다. 그중에서도 저런 기민한 방법론이나 XP같은 유행[?]에 잘 따라가지 않을 것 같은 .NET쪽에서도 역시나 여러 툴이 나와있고, Visual Studio 2005에서는 자체적으로 지원한다고 합니다. 2005년 q3나 q4정도가 되면 나오지 않을까 조심스레 추측해보지만, 미리 경험하고 익숙해진다면 좋겠지요 :D
먼저 VSS를 이용한 소스 형상 관리를 생각해보면, '여러 개발자들이 한 VSS Repository에서 Check Out/In을 하면서 작업을 진행한다' 가 기본이 되겠지요. 이런 상황에서는 시스템 통합이 누군가에 의해서 이뤄질 수 밖에 없습니다. 결국 누군가의 VS.NET에서는 모든 프로젝트가 추가되어있어서 빌드를 할 수 밖에 없으니까요. [구조에 따라서는 각자 빌드해서 DLL만 복사해서 가지고 있는 시나리오도 있을 수 있겠네요]
위에서 nAnt를 추가해봅시다. nAnt는 아시겠지만 Ant같은 빌드 도구입니다. 자세한 얘기는 저 역시 잘 모르기때문에 넘어가도록 하구요 ^^;; 기억해둘만한 사항은 프로젝트 단위마다[꼭 그런 단위로 가는 것은 아닙니다만, 대체로 그렇죠] nAnt용 build파일이 있어야 한다는 점입니다. 그렇긴 해도 템플릿 하나에서 프로젝트명과 참조 정도만 바꿔주는 정도입니다. 어려운 작업은 아닙니다만, 실제 작업 환경인 VS.NET에서 참조를 추가하고 build파일에 참조를 추가하지 않는 실수이 잦습니다 :'( 또한 프로젝간의 의존성 설정을 위해서 따로 master build파일을 두어야하는 불편함이 존재합니다. 역시 어려운 일은 아니지만 프로젝트의 생성/삭제가 일어날 때마다 갱신해줘야 하므로 귀찮은 일이 됩니다. 그래도 어느정도 프로젝트들이 안정이 된다면 그 이후에는 귀찮음이 많이 덜어지겠지요:)
nAnt를 추가했지만, 역시나 누군가가 VSS의 소스를 다 받아서 master.build파일이 있는 곳에서 커맨드창에 nant 라고 쳐줘야하는 불편함이 있습니다. 이제 Draco.NET을 추가해봅시다.
Draco.NET은 소개말에서 부터 CI를 위해 설계되었다고 합니다. 이는 주기적으로 형상관리툴[VSS나 CVS]에서 소스를 받아다가 빌드[nAnt나 VS.NET(devenv.exe)]를 해주는 유용한 툴입니다. [이런 툴은 AntHill, CruiseControl 등 여러가지가 있습니다] 이 툴까지 더해지면 CI의 시나리오가 어느정도 확립이 됩니다.
한 개발자가 VSS 저장소에서 Check Out을 한 후, 소스를 열심히 고치고 Check In을 한다. 그러면 빌드 서버에서는 변화를 모니터링하고 있다가 감지되면 소스를 받아 nAnt master.build파일을 가지고 빌드를 한다. master.build파일에는 각 프로젝트의 종속성에 따른 빌드 순서를 가지고 있고, 빌드가 끝난 후에는 그에 대해 FxCop을 실행하고, 출력된 DLL과 XML파일을 가지고 NDoc을 수행하여 MSDN스타일의 문서를 뽑아낸다.
위와 동시에 같은 네트워크에 구축되어있는 팀내[혹은 사내] 테스트 서버에 팀원들이 볼 수 있는 테스트 버전이 배포가 되어 빌드 후 즉시 결과가 확인이 된다.
위와 동시에 같은 네트워크에 구축되어있는 팀내[혹은 사내] 테스트 서버에 팀원들이 볼 수 있는 테스트 버전이 배포가 되어 빌드 후 즉시 결과가 확인이 된다.
이러한 시나리오가 됩니다 :D
구성하기까지는 여러 귀찮은 점이 많지만, 일단 구성되고 나면 통합에 대한 걱정은 많이 덜 수 있습니다. [물론 수행되는 프로세스가 길어 빌드 한 번에 30분이상 걸리는 대형 프로젝트에 있어서는 Draco.NET의 검색 주기를 하루정도로 늘려주는 식의 방법이 필요하겠습니다.]
실제 이러한 과정을 구축하기까지 [아직 구성 안된 부분도 있지만] 여러가지 이해과정과 사소한 실수들이 많았습니다. 가장 당황했던 적은, master.build파일에 ReBuild의 과정에 배포된 wwwroot의 파일을 지우는 프로세스를 넣어두었는데, 그걸 로컬에서 테스트 해보려고 실행했다가 aspx파일들이 다 지워졌던 적이었습니다. [빌드 서버의 배포 디렉토리와 로컬의 작업 디렉토리 구조가 동일해서 발생한 문제였습니다] 그 이후로 로컬에서는 VS.NET을 이용하여 빌드하고 실제 배포할 때는 빌드서버에서 나온 결과물을 배포하는 이상한[?] 구조로 바뀌었었죠.
그래도 구축하고 나서는 '빌드조차 안되는 상황'을 겪지 않아서 꽤나 즐겁게 일할 수 있었습니다. 또한 빌드가 안되는 상황이 오더라도 그것이 어느 부분에 문제 있는지 알 수 있는 history가 제공되기 때문에 빠르게 대처할 수 있구요. 기회가 된다면 이 포스트를 매뉴얼화 해보고 싶네요 :) VS.NET 2005에서는 저런 것들이 정식으로 지원된다고 하니 기대도 해봐야겠습니다.
루라라라.. 이 번 포스트는 좀 무리했네요 ;ㅅ;
로딘
제루
제루 Season 2, @Tokyo
