[지디넷코리아]이번에 알아볼 기능은 팀빌드이다. 빌드(build)에는 여러 가지 사전적 의미가 있겠지만 소프트웨어 프로젝트에서 ‘빌드’라고 하면, 소스를 컴파일해서 오브젝트를 만들고, 링크하고, 그 에 리소스를 더하고, 패키징, code sign등의 과정을 거쳐서 최종적으로 만들어진 결과물을 말한다. 하지만 아직도 많은 업체들이 손으로 하는 수동적 빌드에 의존하고 있는 형편이다. 독자분들이 회사에서 어떤 식으로 빌드를 만들고 있는지 한번 생각해보자. 만약 일반 Visual C++ 애플리케이션이라고 한다면 다음과 같은 방식으로 하고 있지 않을까?

1. 최신 버전 소스를 가져온다.
2. 컴파일해서 *.exe를 만든다. 컴파일시에 오류가 나면 소스를 수정하고 다시 시도한다.
3. 만들어진 *.exe를 복사하고, 여기에 필요한 리소스(이미지 파일등)를 더한다.
4. InstallShield같은 프로그램을 실행시켜서 셋업 패키지를 만든다.
5. 만들어진 패키지를 복사해서 ftp에 올린다.

문제는 뭐냐 하면, 프로젝트의 막바지로 갈수록 빌드를 할 경우가 많아지는데, 이를 일일이 수동으로 수행하는 것은 대단한 시간낭비라는 것이다. 또 빌드의 각 단계가 길어지면 그 중간에 필요한 리소스를 빠뜨린다거나 소스가 잘못되었거나 하는 오류가 발생할 가능성도 높아진다.

이미 자바진영에서는 그런 문제를 해소하기 위해서 나온 빌드 자동화 도구들이 있으며 대표적인 것으로 Eclipse와도 연동되는 Ant를 들 수 있다. Ant를 사용할때는 xml로 정의된 설정파일만 준비하면 빌드 및 배포에 관련된 여러 가지 작업을 모두 자동으로 수행해줄 수 있으므로 대단히 편리하다.

이런 자동화 도구가 도입되어 자바개발자들의 생산성은 대폭 향상되었는데, 이번에 VS2005에 팀빌드가 도입되어 윈도 개발 분야에서도 반복되는 작업을 자동화하여 생산성 향상을 꾀할 수 있게 되었다. 하지만 팀빌드가 만능은 아니며, 진정한 빌드자동화 도구가 되기 위해서는 넘어야 할 산이 아직 많다.

팀빌드의 과정
팀빌드는 말 그대로 팀레벨에서 빌드를 하는 것으로, 다음과 같은 과정을 거친다. 굉장히 여러 단계로 나누어서 수행되며 중요한 것은 이 빌드 작업이 클라이언트에서 이루어지는 것이 아니라는 점이다. 모든 빌드 프로세스는 TFS 도메인에 설치된 어떤 시스템 상에서도 가능하므로, 클라이언트의 상태와 관계없이 빌드를 실행할 수 있다.

1. TFS에서 빌드가 초기화된다.
2. Build ID를 생성한다.
3. 빌드에 필요한 문서와 설정파일을 작성한다.
4. 빌드 시스템에서 최신 버전의 소스를 동기화한다.
5. 컴파일하고, analyze 옵션이 설정되었다면 수행한다.
6. Test가 설정되었다면 수행한다.
7. Work Item을 갱신한다.
8. Code coverage를 계산한다.
9. 빌드 리포트를 작성한다.
10. 만들어진 빌드를 배포한다.

보는 바와 같이 아주 많은 단계를 거치지만 이중 몇가지는 사용자의 구성에 따라 옵션으로 수행할 수도 있고 안할 수도 있다. 또한 각 단계 중간에서 문제가 생기면 그 즉시 빌드는 중단되고 사용자에게 빌드 실패에 대한 메시지가 로그파일의 형태로 보내어진다.

팀빌드 설치
그러면 팀빌드를 사용하기 위해서 무엇을 어떻게 해야 하는지 알아보자. 팀빌드를 사용하기 위해서 가장 먼저 해야 할 것은 설치이다. TFS와 클라이언트를 설치한지 얼마 지나지도 않았는데 또 뭘 설치하라는 것인가? 라고 생각할 수도 있겠는데, 팀빌드는 TFS나 클라이언트에 설치하는 것이 아니다.

앞서 언급한대로 팀빌드는 TFS나 클라이언트 어느 쪽에서 실행되는 것도 아니며, 팀내에 준비된 ‘빌드 시스템’에서 실행하는 편이 제일 좋다. 클라이언트에서 팀빌드를 실행하게 되면 클라이언트 PC가 24시간 대기해야 하는 불편함이 있다. 또 누군가 팀빌드를 시작하면 자신의 PC가 갑자기 영문도 모른 채 느려지게 되는데 이런 불편함을 감수할 팀원은 많지 않을 것이다. 그렇다고 해서 TFS에서 팀빌드를 실행하게 되면 가뜩이나 부하가 많은 TFS에 짐을 하나 더 얹는 모양이 된다.

그러므로 TFS 도메인 내에는 빌드만을 하기 위한 전용의 시스템이 한대 있는 것이 가장 바람직하다. 여기서 모든 팀빌드 작업이 이루어지고, 그 결과는 지정한 네트워크상의 경로에 저장되는 것이다.
팀빌드는 다음과 같은 순서로 설치한다.

1. Windows 2003을 설치한다. 이 시스템은 TFS의 Active Directory에 참여하고 있어야 한다.
2. 제어판에서 ICF(Internet Connection Firewall)와 ICS(Internet Connection Sharing)서비스가 작동중인지 확인한다. 이 서비스는 팀빌드를 위해 반드시 필요하다(두개의 서비스가 아니라 ICF & ICS라는 하나의 서비스임). 만약에 작동중이지 않다면, 'Automatic'으로 설정한 후 서비스를 시작한다.
3. TFS DVD를 넣고, \bb\setup.exe를 실행한다.
4. Service Logon Account를 물으면 앞서 서비스 설치에 사용한 계정(ex. Domain\TFSSETUP)을 넣어준다.

팀빌드가 설치되었다면 이 시스템은 팀빌드 전용 머신으로 활용할 수 있다. 또한 도메인내의 팀빌드 전용 머신은 몇대든지 원하는 만큼 설치할 수 있다. 이제 VSTS에서 어떻게 팀빌드를 만드는지에 대해서 알아보자.

팀빌드 작성
Team Explorer에서 팀프로젝트를 조회해보면 'Team Builds'라는 폴더가 있는 것이 보일 것이다. 이 폴더에는 기존에 만들어진 모든 팀빌드 타입들이 리스팅되어 있는데 새롭게 팀빌드 타입을 하나 만들 때마다 아이템이 하나씩 추가되며, 각각의 아이템을 더블클릭하면 해당 빌드 타입에 대한 수행결과를 볼 수 있다.

이 그림은 모든 빌드결과를 조회한 것이다.

새롭게 팀빌드 타입을 만들기 위해서는 다음과 같은 절차를 거친다.

1. Team Builds 폴더에서 오른버튼으로 나오는 context menu에서 New Team Build Type을 선택해 Team Build Wizard를 실행시킨다.
2.이름과 설명을 지정한다.
3. 사용할 workspace와 빌드할 솔루션을 선택한다.
4. Configuration과 CPU타입을 선택한다.
5. 여기가 중요하다. 위에서부터 빌드를 만들 시스템을 선택한다. 이 시스템은 앞서 언급한 빌드 시스템, 즉 팀빌드가 설치된 시스템의 이름을 적는다. 두 번째는 이 빌드 시스템에서 사용할 로컬 작업 디렉토리를 적는 것으로, 아무 디렉토리나 만들고 작업공간으로 할당하면 된다. 세 번째는 최종적으로 만들어진 빌드 및 로그를 복사할 디렉토리를 네트워크 경로명으로 지정한다. 이렇게 하면 빌드를 실행했을 때 그 결과가 세 번째에 지정한 디렉토리밑에 로그와 같이 저장된다.


6. 빌드시 Test나 Code Analysis를 실행하고 싶다면 옵션에서 지정해준다.
7. 이제 최종적으로 Finish버튼을 누르면 빌드 타입이 저장된다.

팀빌드 실행
만들어진 팀빌드를 실행하는 것은 간단하다. 메뉴의 Build-Build Team Project를 실행한 후 원하는 빌드를 선택해서 상단의 Build버튼을 눌러주면 된다. 그러면 선택한 빌드의 상태가 바뀌면서 빌드가 진행된다. 빌드의 디렉토리는 지정한 결과 디렉토리 밑에 빌드 타입명_YYMMDD.NNNNN(N은 시리얼넘버)의 이름으로 만들어진다. 만약 어떤 문제가 있어서 빌드가 실패했다면 그 결과가 해당 디렉토리에 로그파일로 남게 될 것이다. 빌드가 성공했다면 그 역시 로그가 남고 빌드의 결과인 실행파일이나 그에 상응하는 결과물이 디렉토리에 복사된다.

빌드 시스템의 지정된 워크 디렉토리를 보면 해당 빌드에 대한 소스와 빌드용 설정파일 및 기타 필요한 파일들이 모두 복사되어 있고, 실제 컴파일한 결과물도 저장되어 있는 것을 볼 수 있다. 즉 빌드가 시작되면, 빌드 시스템은 소스를 가져와서 컴파일한 후, 그 결과를 지정한 네트워크상의 경로에 배포하는 것이다.

팀빌드의 장점
그러면 팀빌드를 사용하면 어떤 장점을 기대할 수 있을까? 일단 팀빌드는 타입을 여러 가지 지정할 수 있으므로 원하는 Configuration을 여러 개 두고 원하는 것을 그때그때 선택할 수 있다는 장점이 있다. 하나의 소스에서 fork된 여러 종류의 커스터마이즈된 제품들을 판매하고 있는 경우라면 각 제품별로 팀빌드 타입을 만들어놓고 필요할 때마다 빌드하는 방법으로 작업자의 혼동이나 실수를 원천 방지할 수 있으므로 아주 편리하다.

더불어 빌드 과정이 자동화되므로 매일매일 빌드를 만들어서 배포하는 daily-build가 가능해진다. 많은 전문가들이 지적하듯이 매일 통합하고 빌드를 만드는 것은 매우 좋은 일이며, 팀빌드는 필요하다면 테스트와 코드분석까지 포함시켜서 빌드하고 리포트해주므로 문제가 발생했을 때 일단위로 확인이 가능하게 된다. 또한 개발자가 아닌 프로젝트 팀원들이라도 지정된 디렉토리에 접근하기만 하면 매일 최신버전의 결과물을 얻을 수 있고, 프로젝트 진행상황을 꼭 보고받지 않더라도 실제 수행 가능한 결과물로 점검할 수 있다.

MSDN에 보면 팀빌드를 이용해서 모든 팀원들이 퇴근한 후 빌드를 만드는(이 문서에서는 Nightly-Build라고 한다) 방법에 대해서 설명한 문서가 있는데 관심있는 독자는 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/NtBldTmSrv.asp 를 읽어보기 바란다. 팀빌드를 Install하면 'Team Build Service'라는 이름의 서비스가 설치되는데 이 서비스에 접속해서 팀빌드를 수행하는 어플리케이션을 윈도의 기본 스케줄러에 추가한 것 뿐이다.

아직까지는 다른 경쟁제품에 비해 특별히 뛰어나다거나 독특한 기능을 제공한다든가 하는 부분은 없고 일단 간단하고 쓰기 편하게 만드는데 주력한 것으로 보이는데 빌드외에는 정말 아무 일도 안한다는 점은 아쉽다. 하지만 위에서 언급한 Nightly Build처럼 팀빌드 서비스와 다른 컴포넌트나 애플리케이션을 연동시키는 사례가 많이 소개된다면 팀빌드의 활용도는 앞으로 훨씬 더 높아질 것으로 생각한다.

필자 노규남님은 게임개발에 주력하고 있으며, 오랫동안 각종 플랫폼에서 사용되는 개발도구를 사용한 경험이 풍부하다.