Ben Waldron (영문)
목차
Agile 방법론
Continuous Integration
비쥬얼 스튜디오 2005 팀 시스템
프로젝트 유닛 테스팅
팀 프로젝트 생성하기
유닛테스트 빌드 생성
새로운 빌드의 정의
팀 파운데이션 서버의 확장
Work Item의 설정
결론
많은 개발 팀들이 개발중의 변화와 소프트웨어 품질을 향상시키기 위해 Agile 방법론을 채택했습니다. 이 개발방법은 새로운 기능이 추가되었을 때, 버그가 고쳐졌을 때, 그리고 코드가 새로 고쳐졌을 때, 소프트웨어 프로젝트를 점차적으로 테스트하고 빌드하는 방법를 이용하여 Continuous Integration을 증진시킵니다. 그렇다면 어떻게 비쥬얼 스튜디오 2005 팀 시스템과 팀 파운데이션 서버가 Agile 방법론에 의한 개발과 Continuous Integration을 용이하게 할까요?
이 글은 비쥬얼 스튜디오 2005 팀 시스템을 이용해서 TDD (Test-Driven Development)와 같이 Agile 개념을 이용한 예제 프로젝트를 생성함으로써 위의 질문에 대답해 드릴 수 있습니다. 프로젝트가 끝이 났을 때, 어떻게 저는 팀 파운데이션 서버를 이용해서 팀 프로젝트를 생성하는지, 그리고 이 기술의 확장 기능을 이용하여 프로젝트의 소스들이 소스컨트롤에 체크인 됨과 동시에 어플리케이션을 빌드 하는 continuous integration 기능을 가능하게 하는 사용자 정의 웹서비스를 생성하는지를 보여드리겠습니다.
Agile 방법론
구체적으로 Agile 방법론의 개념으로 들어가기 이전에, Agile 방법론의 역사에 대해서 살펴보고 어떠한 개발 방법론이 민첩한 지에 대해서 정의하는 것이 유용할 것 같습니다. 몇몇 개발 방법론들이 1990년대에 RUP(Rational Unified Process)와 같은 무거운 개발 방법 모델에 대안으로 생겨났습니다. 어떤 개발자들은 일의 우선 순위가 자주 바뀌고 사용자의 반응이 아주 중요한 소프트웨어 개발의 속성을 이러한 개발 방법론들이 잘 반영하지 못한다고 생각했었습니다. 경험을 통하여 많은 개발 팀들은 소프트웨어 프로젝트가 수많은 형태와 크기가 될 수 있음을 알고 있었고, 이런 이유로 무거운 개발 방법론이 수많은 경우에, 특별히 작고, 아주 자주 바뀌는 환경에서는 잘 맞지 않는 다는 것을 느끼고 있었습니다. 예를 들어, Predictive waterfall 방법론으로는 급박하게 변하는 개발 환경을 예측하기 힘들었습니다.
eXtreme Programming, Adaptive Software Development, Dynamic Systems Development Method 들과 같은 방법론들은 프로젝트 관리를 하도록 하고 개발자들에게 품질을 희생하지 않고도 재빠르게 변화에 적응할 수 있도록 하기 위해서 만들어 졌습니다. 지금에 와서 보니, 이러한 개발 방법론들이 고객의 반응과 회사의 요구에 재빠르게 반응할 수 있는 능력, 고객이 제품의 진화에 얼마나 크게 영향을 미치는지에 대한 이해, 짧은 개발 주기, 그리고 전체 영역에 대한 테스트, 이러한 면에서 보았을 때 많은 공통적인 면을 가지고 있었다는 것이 분명했습니다. 개발 팀들은 그들의 개발 조직에 가장 알맞는 개발 방법론을 채택하기 시작하여 시간이 지남에 따라 이 방법들을 진화하여 향상시켰습니다.
2001년에, 소프트웨어 개발자 그룹이 이러한 방법론들의 공통점에 대해서 논의하기 위해서 모임-다섯 개의 소프트웨어 개발 방법론 모임-을 가졌습니다. 이러한 소프트웨어 개발자들은 이러한 방법들에서 공통된 모든 부분을 포함하기 위해서 Agile이라는 용어를 만들었습니다.
그 이후로는, Agile 개발방법은 계속 성장해 왔으며, 이 방법의 사용을 돕기 위한 개발 도구들이 계속 만들어 졌습니다. 반면에, 개발팀들은 이러한 방법을 사용한 혜택을 거두고 있습니다. NUnit 같은 유닛테스트 툴들은 개발 프로세스의 필수 불가결한 부분이 되었습니다. 이와 유사하게, Continuous Integration은 Agile 방법론의 전체를 다 채택하지 않더라도 많은 개발 팀들이 채택한 표준적인 방식이 되었습니다. 이 부분에 대한 좀 더 많은 정보는, "Agile 개발 방법 자료" 사이드바를 한 번 눈여겨 보시기 바랍니다.
Continuous Integration
Continuous integration은 Martin Fowler이 소프트웨어 개발에 있어서 최상의 관행이고, Agile 개발 과정에 꼭 맞는 기술이라는 것을 주장( 여기 (영문)를 참고해 보시기 바랍니다)하였던 간단하고, 아주 효과적인 테크닉입니다. Continuous Integration은 소프트웨어의 어떤 부분이 변하는 매 번 마다 빌드가 생성하도록 하는 일일 빌드에서 한 걸음 더 나아간 개념을 받아 들였습니다. 거의 모든 경우에, 개발자가 어떤 소스 코드를 체크인(check-in) 하거나 혹은 소스컨트롤 하에 있는 구성의 변화 때 마다 빌드를 생성하도록 합니다. 빌드는 중앙의 소스 저장 장소에서 모든 파일을 받아 들여서, 이 것들을 컴파일해서 빌드를 생성합니다. 빌드의 상황은 실패한 빌드를 빨리 알아내고 고치기 위해서 진행과정 마다 개발자와 테스터에게 전달됩니다. 이에 한 걸음 더 나아간 변화는 체크인(check-in)이 파이널라이즈(finalize)되기 전에 빌드를 수행하고, 체크인이 빌드 수행에 지장을 준다면, 체크인 자체를 중지시키는 것을 허용하는 것 입니다.
eXtreme Programming(이하 XP)는 특별히 TDD를 강조해서, Continuous Integration의 속성과 아주 잘 맞는 개발 방법론입니다. TDD는 개발자가 테스트 케이스(일반적으로 유닛테스트)를 작성해서, 자동화된 도구에 의해 코드를 실행하고, 필요한 만큼 코드를 수정해야 한다는 개념입니다. 이러한 테스트를 효과적으로 작성하기 위해서는 제품 전체의 코드를 충분히 검토하는 유닛테스트를 만들어야 합니다. 이러한 자동화된 테스트 케이스들은 모든 개발자와 테스터들이 접근 권한이 있어서 빌드로 소스코드를 체크인(check-in)하기 전에 테스트를 할 수 있는 공통 영역에 놓여져 있어야 합니다.
이러한 속성은 Continuous Integration과 아주 잘 맞습니다. 왜냐하면, 빌드가 컴파일된 후에, 모든 유닛테스트는 최신 빌드에서 동작하기 때문입니다. 만약 어떤 유닛테스트가 실패했다면, 어떤 부분이 제대로 동작하지 않기 때문에 빌드가 실패했다는 것을 의미합니다. 이러한 테스트 케이스들이 소프트웨어의 품질을 보장하기 위해서 소프트웨어의 많은 부분을 검사할 수 있어야 한다는 점은 아주 중요합니다. 또 다른 최상의 습관은 이미 발견되어 고쳐된 버그들이 고쳐졌음을 확인할 수 있도록 유닛테스트를 만드는 것과 자동화된 방식으로 진행상태를 확인할 수 있게 하는 것 입니다.
이러한 Continuous Integration의 한 가지 명백한 이점은 투명성입니다. 실패한 빌드와 테스트는 다음 빌드를 기다리는 대신에 아주 빠르게 발견됩니다. 그러한 버그를 만든 개발자는 아마도 그 근처에 아직 있을 것이고, 아주 빠르게 버그를 고치거나 오류를 발생시키는 변화를 오류가 없었던 이 전 상태로 롤백할 수 있습니다.
이 글이 Visual Studio 2005 팀 시스템과 팀 파운데이션 서버를 이용한 유닛 테스팅과 Continuos Integration에 집중하고 있지만, 이러한 툴 없이도 Continous Integration을 구현하는 것은 당연히 가능합니다. CruiseControl.NET (영문)는 여러분의 프로젝트에 Continuous Integration을 구현하는데 적용할 수 있는 또 다른 예제입니다. 그러나, 이 글에서 저는 어떻게 팀 파운데이션 서버가 새로운 비쥬얼 스튜디오 2005에서 빌드를 자동화해서 유닛테스팅 기능과 통합할 수 있는지 보여 드리겠습니다.
비쥬얼 스튜디오 2005 팀 시스템
이미 비쥬얼 스튜디오 2005와 개발팀을 위한 새로운 기능들에 대해서 많은 글들이 쓰여졌습니다. 이러한 새로운 기능들에 대해서 배울 수 있는 좋은 자료 중의 하나는 Chris Menegay에 의해서 쓰여진 "Get All Your Devs in a Row with Visual Studio 2005 Team System (영문)" 입니다.
팀 파운데이션 서버는 비쥬얼 스튜디오 팀 시스템의 기능 중 많은 부분을 조정하는 백 엔드 서버 컴포넌트입니다. 이 기능중 새로운 기능 중의 하나가 바로 새로운 소스 관리 시스템입니다. 이 기능은 비쥬얼 소스세이프를 대체하고 기존에 존재하는 소스코드를 새로운 소스관리 툴로 마이그레이션 할 수 있는 새로운 변환 툴까지 가지고 있습니다. 만약 여러분이 이동하기를 선택하지 않는다면, 새롭게 출시된 소스세이프를 이용하실 수도 있습니다.
팀 파운데이션 서버는 소스 관리 이상의 많은 것들을 제공하고 있습니다. 개발자는 버그, 혹은 작업 혹은 프로젝트 문서들을 추적할 수 있습니다. 이러한 아이템들은 보관되고 버젼 관리가 지원되어, 소스 코드만큼 귀중하고 필요한 것으로 간주됩니다. 개발자뿐만 아니라 모든 팀원들이 하루 단위로 마쳐야 하는 일들도 팀 파운데이션 서버안에 저장되어, 비쥬얼 스튜디오 사용자 인터페이스를 통하여 제공되어, 여러분이 가장 많이 사용하는 툴 안에서 정보를 볼 수 있게 해줍니다.
팀 파운데이션 서버는 웹서버로 구성되어 비쥬얼 스튜디오 클라이언트와의 상호작용을 처리합니다. SQL Server™ 2005는 Work Item들과 소스 코드들을 이전 버젼과의 차이만을 압축해서 저장하는 방식으로 관리합니다. (역자 주-원문에는 Reverse delta라는 용어를 사용했으며, 이 방식은 최근에 변경된 파일은 원본을 저장하고, 그로부터 과거의 파일들의 정보는 가장 최근에 저장된 소스 코드의 차이 만을 저장하는 방식입니다.) SQL Server Analysis Services 와 Reporting Services는 프로젝트에 관련된 테스트 결과, 단위, 그리고 코드의 변경사항(원래는 code churn이라는 용어를 사용했으며, 이 용어에 대한 설명은 http://blogs.msdn.com/askburton/archive/2004/09/09/227515.aspx (영문) 이 곳에서 찾아보실 수 있습니다.)을 보고해 줍니다. Windows® SharePoint® Services는 프로젝트의 상호협력 그리고 문서 저장소를 위한 포탈을 제공해 줍니다. 프로젝트 팀 사이트는 비쥬얼 스튜디오를 이용하여 일하지 않는 팀원들에게 프로젝트 정보와 자원에 접근할 수 있도록 해줍니다.
소스코드는 독립 실행 서버에서 설치될 수 있는 팀 파운데이션 빌드서버를 이용하여 컴파일됩니다. 코드는 소스 컨트롤 시스템에서 체크 아웃, 빌드, 테스트 되어, 빌드의 결과는 네트웍 공유를 통하여 접근할 수 있습니다. 개발자는 그에 관련된 매니져가 어떻게 프로젝트를 빌드할 지를 조정할 수 있도록 하기 위해서, 많은 종류의 빌드 종류가 지원됩니다.
팀 파운데이션 서버의 많은 부분이 .NET 프레임웍과 웹서비스를 통하여 작성되어서, 팀 파운데이션 객체 모델을 이용하여 작업들을 자동화하는데 이벤트를 구독을 이용해서 사용자가 자신이 원하는 대로 변경하는 것이 쉽습니다. 제가 소스 컨트롤의 체크인(check-in) 이벤트에 응답함으로써 continuous integration을 가능하게는 하는 예제를 보여드리도록 하겠습니다.
프로젝트 유닛 테스팅
한 가지 예를 들기 위해, 저는 XP 방법을 따르는 간단한 .NET 라이브러리를 생성하고, 빌드하여, 테스팅 해보도록 하겠습니다. 저는 .NET 프레임웍 2.0의 generics를 이용하여 간단한 수치 함수를 제공하는 수학 컴포넌트를 개발하겠습니다. generic 인터페이스는 덧셈 혹은 뺄셈과 같은 수치연산을 할 수 있는 함수를 위한 메써드들을 정의하고 있습니다. 이 인터페이스는 계산기 라이브러리가 자료형에 따른 정확한 메써드를 호출할 수 있도록 해 줍니다. 이 예제 자체는 개념 전달을 위해서 그렇게 중요하지는 않으나 .NET generics의 사용을 보여주기 위한 목적으로 한 번 참고해 볼만 합니다. 이 글에 대한 모든 소스코드가 C#과 Visual Basic® 의 두 개의 언어 버전으로 존재한다는 것을 기억해 주시기 바랍니다.
모든 XP 프로그래밍을 이용하는 개발자들이 하듯이, 저는 구현하기를 원하는 공용 메써드 각각을 위해서 유닛테스트를 생성했습니다. 일반적으로, 저는 유닛테스트를 만들기 이전에 공용 메써드와 속성들을 미리 정의합니다. 비쥬얼 스튜디오에 있는 새로운 클래드 다이어그램 기능이 이러한 일을 쉽게 할 수 있게 해줍니다(그림 1 참조).
그림 1 CalculatorLibrary 클래스 다이어그램
위의 그림과 같이 CalculatorLibrary 클래스의 공용 메써드에 대해서 유닛테스트가 생성되었습니다. 비쥬얼 스튜디오 팀 시스템을 이용하여, 유닛테스트 프로젝트를 생성함으로써 이러한 유닛테스트들을 솔루션에 추가할 수 있으며, 이러한 유닛테스트 프로젝트는 개발자로 하여금 웹 페이지 테스트들을 생성하고, 불러들이고, 코드 유닛테스트, 그리고 수동으로 동작하는 다큐먼트 테스트까지 가능하게 해 줍니다. 여기서의 코드 유닛테스트 클래스는 수학적인 메써드들의 정확성을 시험할 수 있도록 해 줍니다. 그림 2는 리스트의 총합이 86과 같다는 것을 확인해 주는 유닛테스트의 예를 보여주고 있습니다. 만약 예외가 발생되거나 혹은 그 총합이 86이 아닌 다른 값이라면, 테스트는 실패할 것 입니다.
Initialize 메써드는 이러한 테스트를 설정하기에 필요한 작업을 정의 해 줍니다. 이 경우에는, Calculator 객체를 생성해 줍니다. 테스트 초기화 메써드는 반드시 TestInitialize 속성이 설정되어 있어야 합니다. 이와 유사하게, 테스트 메써드들은 TestMethod 속성이 설정되어 있어야 합니다. 이러한 속성들은 비쥬얼 스튜디오의 테스팅 프레임웍에서 메써드들이 인식할 수 있도록 하기 위해서 반드시 필요합니다.
그림 3 로컬 테스트 결과 확인하기
일단 유닛테스트가 완료되면, Calculator 라이브러리는 구현을 할 수 있습니다. 그러면, 저는 이 유닛테스트를 로컬에서 실행할 준비가 되었습니다. 테스트 매니저는 위에 보이는 그림에서와 같이 현재 솔루션에 위치한 모든 테스트들을 선택하고 실행 할 수 있게 해줍니다. 그림 3에서 보이는 테스트 결과 윈도우는 모든 테스트를 통과했으며, 제가 다음 단계로 넘어갈 준비가 되었다는 것을 보여줍니다; 구체적으로는, 팀 파운데이션 서버에 새로운 팀 프로젝트를 생성하고, 그 솔루션을 추가하는 것이 그것 입니다.
새로운 팀 프로젝트의 생성
팀 파운데이션 서버가 네트워크에 설정이 된 후, 비쥬얼 스튜디오에서 그 서버에 연결하는 일은 매우 직관적입니다. 툴(Tools)메뉴에서, “Connect To Team Foundation Server” 메뉴를 선택하시면 됩니다. 그 곳에는 새로운 서버를 추가할 수 있는 옵션이 있고, 통상적으로는 URL을 통해서 기본 포트인 8080에서 동작하는 서버에 연결합니다. 저의 경우에는, URL은 TeamFoundation:8080 입니다.
일단 서버에 접속된 후에는, 여러분은 새로운 프로젝트를 생성할 수 있습니다. 일반적으로, 프로젝트의 이름은 솔루션의 이름보다 좀 더 포괄적이어야 합니다. 저는 그림 4에서 보여지는 것과 같이 제 프로젝트의 이름을 MSDN Calculator로 선택했습니다. 일반적으로, 팀 프로젝트는 어플리케이션의 작성을 위한 정의 단계에서, 코드가 작성되기 이전에 생성됩니다. 그리고 이러한 팀 프로젝트는 비쥬얼 스튜디오 프로젝트와 많은 솔루션을 가지고 있습니다 한 가지 흥미로운 사실은 이 팀 프로젝트가 소스 컨트롤 이상의 의미를 가지고 있다는 사실 입니다. 팀 프로젝트는 구체적인 역할(role)를 가지고 있는 사용자들이 있고, 그 사용자들은 구체적인 소프트웨어 개발 방법론을 준수해야 하며, 그 방법론에 대응되는 여러 가지 Work Item을 가지고 있고, 프로젝트에 관련된 정보를 주고 받으며 협력할 수 있는 포탈을 가지고 있다는 점 입니다. 이러한 것들을 이용할 수 있는 좀 더 적절한 팀 프로젝트의 이름은 사내에서 많은 응용프로그램에 의해서 공유되는 공통 클래스들의 집합이 있고, 그리고 그 개발을 관리하기 위한 팀 프로젝트로서 아마도 “Enterprise Infrastructure” 정도는 되어야 할 것 입니다. 그러나, 저는 간단하게 예를 들기 위해서 여기서는 MSDN Calculator를 사용하기로 하겠습니다.
그림 4 새로운 팀 프로젝트 생성하기
새로운 일련의 과정들이 저에게 프로젝트를 좀 더 자세하게 정의할 수 있도록 허용해 줍니다. 처음에, 저는 현재 이용하고 있는 개발 방법론에 대응되는 프로세스 템플릿을 정의할 수 있습니다. 현재 베타3에서는 agile 소프트웨어 개발 혹은 CMMI을 위한 각각의 마이크로 소프트 솔루션 프레임웍들이 제공되고, 이 중에서 선택할 수 있습니다. 저는 현재 XP 개발 방법론을 사용하고 있기 때문에, agile 개발 템플릿을 선택하도록 하겠습니다. 그러나, 이러한 템플릿들이 사용자에 의해 변경될 수 있고, 여러분이 또한 새로운 템플릿을 정의하는 것 역시 가능하다는 사실을 기억하시기 바랍니다. 이러한 템플릿들은 work items과 리포트 그리고 프로젝트를 위한 보안 설정을 정의할 수 있기 때문에 아주 중요합니다.
다음 단계는 프로젝트를 위한 소스컨트롤의 설정입니다. 이러한 일을 하는 인터페이스는 비쥬얼 소스 세이프와 매우 흡사하며, 그 환경에서 이동하는 사용자는 직관적으로 활용할 수 있습니다. 이 프로젝트를 위해서 저는 프로젝트의 이름과 동일한 빈 소스컨트롤 폴더를 생성하는 기본 옵션을 선택했습니다.
이 단계를 끝낸 후에, 다이얼로그 박스가 제가 만든 설정과 새롭게 생성된 프로젝트를 확인합니다. 이 일은 새로운 프로젝트를 생성하는데 많은 일들이 내부적으로 필요하기 때문에 약간의 시간이 걸릴 수 있습니다. 백 엔드에서는 쉐어포인트 사이트와 work items들이 생성되고, 레포트들이 정의되며, 그리고 프로세스 템플릿에 따른 다른 많은 일들이 설정됩니다. 이 때, 저는 개발자, 테스터, 그리고 프로젝트에 관여하는 다른 사람들을 위한 역할을 정의해서 프로젝트의 보안 속성을 설정할 수 있습니다. 이제 저는 어떤 아이템에 대해서 체크인(check-in)할 수 있고, 저의 빌드 설정을 정의할 수 있습니다. 이러한 경우, 또한 팀 파운데이션 서버가 “continuous integration”을 지원하도록 확장할 수 있습니다.
이제까지는 저는 .NET 라이브러리를 생성하였고, 여러 유닛테스트를 완료하였으며, 그리고 새로운 팀 프로젝트를 생성하였습니다. 다음 단계는 유닛테스트를 준비하여 팀 파운데이션 빌드 서버에서 원격으로 동작할 수 있게 하는 것 입니다.
유닛테스트 빌드 생성
비쥬얼 스튜디오 팀 시스템 안에는, 테스트 매니져가 자동으로 .vsmdi 확장자를 이용해서 테스트 메타테이타 파일을 생성합니다. 이 파일은 원격 빌드시 유닛테스트의 동작을 가능하게 하는 유닛테스트 설정을 가지고 있습니다.
테스트 매니져에서 저는 왼쪽 윈도우에서 오른쪽 클릭을 하여 두 종류의 테스트들을 생성하였습니다. 한 종류의 테스트들은 CalculatorLiabrary에 Int형을 전달하는 유닛테스트들이고, 다른 하나는 부동소수점 형식의 데이터를 전달을 커버하는 테스트들입니다(그림 5을 참조). 이 빌드가 사람의 조작이 없이 백그라운드에서 일어나기 때문에, 제가 어떤 종류의 수동 테스트도 포함시키지 않았다는 것을 주목하시기 바랍니다. 이 데이터들은 .vsmdi 파일에 저장되어, 소스컨트롤에 체크인(check-in) 됩니다.
그림 5 테스트 매니저에서 프로젝트 테스트 설정
팀 파운데이션 서버 안에서 소스컨트롤 체크인 정책을 정의할 수도 있지만, 저는 이 프로젝트를 위해서는 설정하지 않는 것을 선택했습니다. 체크인 정책은 개발자로 구성된 팀으로 하여금 균일성을 부여하는 훌륭한 기능입니다.
그림 6 프로젝트 내용
이 경우, 솔루션과 프로젝트 설정은 그림 6에서 보이는 것과 같이 설정됩니다. 이것은 Calculator 라이브러리와 유닛테스트 프로젝트를 포함하는 메인 프로젝트를 보여 줍니다. 테스트 메타데이타 파일은 소스컨트롤에 바인딩되는 솔루션의 아이템입니다.
새로운 빌드의 정의
저는 이제 프로젝트를 위한 빌드 형식을 정의할 준비가 되었습니다. 이 경우 저는 math 라이브러리와 유닛테스트 프로젝트를 디버그 빌드로 컴파일 해서, 제가 정의한 테스트 파일들을 동작시키는 빌드를 생성하려고 합니다. 저는 이 빌드를 “Continous Integration”이라고 명명하겠습니다. 이 이름은 향후에 제가 이 빌드를 변경 시에 다시 한 번 사용하도록 하겠습니다. 빌드 혹은 어떤 단위 테스트가 실패할 때, 저는 이 문제를 수정하기 위해서 개발자들에게 여러 방법을 사용해서 알려줄 수 있습니다.
팀 익스플로러 윈도우(Team Explorer Window)에서, 팀 빌드 옵션이 여러분으로 하여금 새로운 빌드 형식을 생성할 수 있게 해줍니다. 이 마법사 윈도우는 여러분으로 하여금 빌드 형식의 이름과 컴파일할 프로젝트를 선택하고, 빌드 머신을 지정할 수 있게 해주는 프로세스로 이동시켜 줍니다. 제 설정에서는, 저는 팀 파운데이션 서버에 빌드 서비스가 설치되어 동작하고 있지만, 일반적으로 빌드가 독립실행형의 서버에서 수행될 것 같기 때문에, 저의 설정이 아마도 일반적인 시나리오일 것 같지는 않습니다. 마법사 윈도우의 마지막 페이지가 저로 하여금 빌드 테스트를 선택해서, 프로젝트가 컴파일 된 후에 빌드를 실행할 수 있게 합니다. 이 경우, 저는 이미 정의된 두 종류의 유닛테스트를 선택했습니다 ( 그림 7 참조).
그림 7 빌드 후에 동작할 테스트 선택하기
일단 “Continuous Integration” 빌드가 정의된 후에, 이것을 테스트 하는 가장 좋은 방법은 비쥬얼 스튜디오 팀 익스플로러 사용자 인터페이스를 통하여 강제로 빌드를 하게 하는 것 입니다. 이 “Continuous Integration” 빌드는 팀 익스플로러 안에서의 팀 빌드 폴더에서 보실 수 있습니다. 간단한 오른쪽 클릭이 팀 프로젝트를 빌드 할 수 있는 옵션을 보여 줍니다. 그러면, 빌드 상태가 비쥬얼 스튜디오 안에서 보고됩니다.
팀 파운데이션 서버의 확장
팀 파운데이션 서버는 확장성을 염두에 두고 만들어 졌습니다. 이 확장성에 대해서 여러분이 알아차릴 수 있는 제일 처음의 암시는 이벤트, 특별히 소스컨트롤 이벤트를 구독할 수 있는 기능입니다. BisSubscribe.exe라고 불리는 커맨드 라인 유틸리티가 팀 파운데이션 서버의 설치 안에 포함되어 있고 이러한 종류의 이벤트를 구독하는데 사용됩니다. 그러나 구독이 설정되기 전에는, 이벤트를 잡기 위해서 웹서비스가 생성됩니다. 베타 3에서는, BisSubscribe 유틸리티는 C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup folder에서 보실 수 있습니다.
BisSubscribe.exe는 여러분으로 하여금 여러분이 구독하는 이벤트의 형식을 정의해서 정확한 시그니쳐과 이벤트를 잡기 위해서 사용되는 웹서비스 메써드의 속성들을 정의합니다. Notify 웹 메써드와 특정한 작업을 수행하기 위해 변경된 프락시(Proxy)는 아래에서 보실 수 있습니다:
<SoapDocumentMethod(Action:="http://schemas.microsoft.com/
TeamFoundation/2005/06/Services/Notification/02/Notify", _
RequestNamespace:="http://schemas.microsoft.com/TeamFoundation/2005/06/
Services/Notification/02"), WebMethod()> _
Public Sub Notify(ByVal eventXml As String)
' 이벤트 기능을 구현합니다
ThreadPool.QueueUserWorkItem(AddressOf BuildProject, eventXml)
End Sub
구독을 하기 위해서는, 여러분은 아래의 명령을 실행해야 합니다:
BisSubscribe /eventType CheckinEvent /userId PICCOLO\TFSSetup /address TeamFoundation:8080/Continuous/Build.asmx /deliveryType Soap /domain TeamFoundation
위에서의 주소 인자는 여러분이 기억할만한 가치가 있습니다. 이 주소가 Notify 웹 메써드를 가지고 있는 웹서비스의 주소입니다. 이러한 웹서비스의 가장 쉬운 주소를 이용하는 방법은 팀 파운데이션 서버 웹서비스를 포함하는 웹사이트 안에 추가적인 가상 루트를 생성하는 것 입니다 (이 이유는 팀 파운데이션 서버 응용프로그램 풀(Pool)의 계정이 소스를 읽고 빌드를 시작할 수 있는 권한을 이미 가지고 있기 때문입니다; 만약 여러분이 다른 웹서비스로 설정한다면, 여러분은 빌드 시에 발생하는 모든 일을 할 수 있는 사용자 정보로 웹서비스를 동작하게 하는 것을 보장해야 합니다.) 이 웹서비스의 물리적인 위치는 C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services 폴더에 있습니다. 커맨드 라인 옵션에서 볼 수 있듯이, 저는 이러한 요청에 대한 서비스를 하기 위해서 “Continuous”라고 불리는 가상 루트를 추가했습니다.
Notify 웹 메써드는 eventXml 파라미터 안의 XML 문서를 받아 들입니다. 이 문서는 특별한 이벤트를 위한 모든 메타데이타를 가지고 있습니다. 그림 8은 제가 MathLibrary.cs 안에 의도적으로 생성한 에러가 있는 상태에서 체크인 했을 때 발생하는 체크인 이벤트를 보여주고 있습니다.
Notify 웹 메써드로부터, 저는 프로젝트를 생성하는 다른 메써드를 생성해서 개발팀에게 결과를 보고 합니다. 그림 9에서, 저는 이벤트 XML로부터 필요한 정보를 추출했습니다. 빌드 생성 시에는 정확히 두 개의 단계가 필요합니다. 처음에, 저는 빌드 컨트롤러에게 전달되어 빌드를 생성하는데 필요한 매개변수를 생성하였습니다. 최소 인자들은 예에서 볼 수 있습니다. 빌드 컨트롤러는 팀 파운데이션 서버 이름, 프로젝트 이름, 빌드 서버 이름, 그리고 빌드 머신이 컴파일을 위해서 사용할 디렉토리가 필요합니다. 미리 정의된 빌드 형식 역시 명시되어야 합니다. 이 경우 저는 팀 프로젝트에서 이전에 정의된 “Continuous Integration” 빌드 형식을 제공해 주었습니다.
빌드 파라미터가 정의된 후에, 저는 빌드 컨트롤러에 대한 프락시를 획득합니다. 이 것은 미리 정의된 인자를 가지고 StartBuild를 호출하는 웹서비스 프락시입니다. 이렇게 하면 고유한 URI가 StartBuild 메써드로부터 반환되어 저로 하여금 빌드의 상태를 확인할 수 있게 합니다. 빌드를 시작한 후에, 다른 프락시가 생성되어 제 프로젝트의 빌드 상태와 자세한 정보를 확인할 수 있는 Build Store 객체에 연결됩니다. 저는 Build Store에 주기적으로 접속하기 위해서 루프문를 이용하였고, 빌드가 끝이 났는지를 확인하기 위해서 StartBuild 메써드에서 반환된 URI를 Build Store 객체에 전달해 주었습니다.
Work Item의 할당
저는 빌드가 끝이 난 후에 빌드의 상태를 확인하였습니다. 빌드가 실패했다면, 저는 AssignWorkItem 메써드를 호출하여 에러를 발생시킨 코드를 작성한 개발자에게 이 문제를 할당하게 하였습니다. 이렇게 하기 위해서 저는 다른 웹서비스 프락시를 가져와야 하고, 이번 경우에는 Work Item Store 객체입니다. 이 객체는 저로 하여금 새로운 work item을 생성하고 저장할 수 있게 하고, 그림 10의 코드에서 볼 수 있습니다.
Work item은 이 빌드를 실패하도록 만든 개발자의 “My Work Items”리스트 안에서 업무로 나타나게 됩니다. 제가 의도적으로 에러에 기반해서 할당한 work item이 그림 11에서 보여지고 있습니다. 이 업무는 개발자로 하여금 에러를 고치기 위해서 필요한 자세한 정보를 제공하고, 이 이슈가 언제 완료되었는지 추적할 수 있게 해 줍니다. 얼마나 많이 이러한 반복과정에서 빌드가 실패했는지, 그리고 이 에러를 고치는데 걸린 시간 같은 많은 단위들이 이러한 work item으로부터 파생될 수 있습니다. 모든 이러한 정보는 개발 노력에 대해서 투명성을 줍니다.
그림 11 자동으로 할당된 Work Item
Work Item을 할당하는 것에 덧붙여서, 빌드 상태에 대해서 경고하는 이메일이 개발팀에게 보내질 수도 있습니다. 그리고 빌드가 성공 시에도 이러한 이메일은 보내질 수 있습니다. 실패한 빌드에 대해서 보내지는 이메일의 예는 그림e 12에서 볼 수 있습니다.
그림 12 개발팀에게 보내지는 자동화된 이메일
이 이메일은 새롭게 빌드 된 프로젝트의 위치와 빌드 로그의 위치에 대한 링크를 제공해 줍니다. 빌드 로그는 실패한 빌드의 원인 혹은 실패한 테스트 케이스의 원인을 파악하는데 필요한 정보를 가지고 있습니다. 이 전체 워크플로우는 사람이 상태를 확인하거나 수동으로 Work Item을 할당하지 않고 자동화되어, 개발팀으로 하여금 가장 중요한 문제인 높은 품질의 소프트웨어 개발이라는 목적에 집중할 수 있게 해 줍니다.
결론
비쥬얼 스튜디오 2005 팀 시스템과 팀 파운데이션 서버는 agile 개발 방법론을 지원하는 많은 기능들이 있습니다. 시스템 안에 통합된 유닛 테스팅과 work item을 가지고, 비쥬얼 스튜디오 안에서 TDD 방법을 이용하는 일이 이 보다 더 쉬워진 적이 없었습니다. 제가 보여드린 것과 같이, 팀 파운데이션 서버를 확장해서 continuous integration과 같은 최상의 관행을 지원하는 것이 이벤트를 잡거나 서버의 하부구조(Infrastructure)에 연결하는 것만큼 쉬워졌습니다.
페이지 맨 위로