윈도우 프로젝트 필수 유틸리티 13장 - 프로젝트 준비

13장 프로젝트 준비

이재홍 http://www.pyrasis.com 2007.10.27 ~ 2008.04.20

목차

1. 개발 프로세스
2. 프로젝트 생성 및 설정
   1. 프로젝트 생성
   2. 프로젝트 기본 설정
      1. 사용자 생성
      2. 사용자별 권한 관리
      3. 티켓 설정
      4. 최초 소스 업로드
      5. 빌드 스크립트 작성

개발 프로세스

이번 장에서는 Hello World를 출력하는 간단한 프로젝트를 진행하면서 앞에서 구축한 통합 개발 환경의 사용법을 익히도록 하겠습니다. 먼저 소프트웨어 제품이 만들어지고 배포되기까지의 프로세스와 개발팀의 업무 프로세스, 그리고 테스트팀 사이의 업무 프로세스를 간단히 알아볼 것입니다.

예제 프로젝트를 진행하면서 지금까지 구축한 통합 개발 환경의 모든 기능을 사용해보고 개발 프로세스를 익히도록 합니다. 필자가 제시한 개발 프로세스와 실제 독자들이 일하고 있는 환경의 프로세스와는 조금 차이점이 있을 수 있습니다. 이러한 부분들은 독자들의 일하는 환경에 맞게 적용하는 것도 중요합니다.

이번 예제 프로젝트의 개발 프로세스는 다음과 같습니다. 먼저 제품 기획을 한 뒤 Trac 프로젝트를 생성합니다. 물론 Subversion 저장소도 함께 생깁니다. Visual C++로 빈 프로젝트를 생성하고 저장소에 커밋합니다. 주의할 점은 Visual C++로 프로젝트를 만들고 어느 정도 개발을 해놓고 커밋하는 경우가 있는데, 이렇게 하면 버전 관리 시스템을 사용하는 의미가 없어집니다. 그렇기 때문에 빈 프로젝트를 먼저 커밋합니다.

그리고 제품 개발을 하면서 중간 중간에 커밋합니다. 그리고 자동 빌드 또는 수동 강제 빌드로 빌드를 하고, 제품 테스트 후 버그가 있으면 버그를 수정하고 버그가 없다면 사용자에게 배포(판매)하는 것입니다.

개발팀의 입장에서 봤을 때 개발 프로세스는 다음과 같습니다.

1. 세부 기능에 대한 사양을 정리하여 작업(Task) 티켓을 생성합니다.
2. 티켓에 해당하는 기능을 개발하고 커밋합니다.
3. 기능 개발이 완료되면 해당 티켓을 닫습니다.

제품이 어느 정도 개발이 되었고 테스트팀과 함께 작업할 때의 프로세스입니다.

1. 테스트팀이 제품 테스트를 합니다.
2. 테스트 중 버그를 발견하였습니다.
3. 테스트팀은 버그에 대한 티켓을 생성합니다.
4. 개발팀은 버그 티켓을 확인하고 버그를 수정합니다.
5. 테스트팀은 수정된 결과물에서 버그가 수정되었는지 확인하고 버그가 수정되었다면 해당 버그 티켓을 닫습니다. 버그가 수정되지 않았다면 해당 버그 티켓에 버그가 수정되지 않았다고 답글을 남겨 개발팀에게 알립니다.

프로젝트에 따라서 개발팀, 테스트팀 이외에 기술지원, 마케팅, 영업팀도 함께 일할 수도 있을 것입니다. 테스트팀 이외의 기술지원, 마케팅, 영업팀에서 들어오는 요구사항 및 버그 보고도 Trac에 티켓을 올려 처리를 하면 될 것입니다. 물론 테스트팀의 최종 테스트는 거쳐야 하겠죠.

프로젝트 생성 및 설정

이제 간단한 프로젝트를 만들고 Trac, Subversion, CruiseControl.NET을 활용하여 프로젝트를 진행하겠습니다. 프로젝트라고 해서 그렇게 대단한 것을 하지는 않을 것입니다. 이 장의 목적은 통합 개발 환경을 활용하는 방법을 익히기 위한 것이기 때문에 프로젝트 자체는 그다지 중요하지 않습니다. 모든 프로그래밍 언어의 공통 예제이기도한 "Hello World" 출력 프로그램을 만들면서, 활용 방법을 설명하겠습니다. 프로젝트가 복잡해져 버리면 프로젝트 자체의 소스를 설명해야 되기 때문에 의도한 목적에서 벗어나게 됩니다.

프로젝트 생성

먼저 Trac 프로젝트를 생성합니다. 프로젝트 이름은 hello로 하겠습니다. 이 작업은 Trac이 실행되고 있는 서버에서 하는 것입니다.

시작 → 모든 프로그램 → Windows PowerShell 1.0 → Windows PowerShell을 실행하고 다음과 같이 입력합니다.

C:\tools\create-project.ps1 hello

그림 13-5 hello 프로젝트 생성

hello 프로젝트가 만들어졌습니다.

프로젝트 기본 설정

프로젝트를 만들었으니 기본적인 설정을 할 차례입니다. http://192.168.1.100/trac/hello (http://192.168.1.100/trac/hello)에 접속하고 admin 계정으로 로그인합니다.

그림 13-6 hello 프로젝트 기본 설정

Basic Settings에서는 프로젝트에 대한 기본 설정을 할 수 있습니다. Name에는 프로젝트의 이름이 들어가는데 Trac의 최 상위 페이지(http://192.168.1.100/trac)에 접속했을 때 표시되는 이름입니다. URL은 좌측 상단의 Trac 로고를 클릭 했을 떄 연결되는 주소입니다. Description은 프로젝트에 대한 설명입니다. Description은 Trac의 최 상위 페이지에는 나오지 않지만 나오도록 설정할 수 있습니다. 설정 방법은 따로 설명하겠습니다.

사용자 생성

Accounts → Users 메뉴로 이동합니다.

그림 13-7 사용자 생성

Trac과 Subversion에서 사용할 사용자를 생성합니다. 여기서 주의할 점은 Username에는 한글을 사용하면 안됩니다. 영문과 숫자만 사용할 수 있습니다(계정은 만들어지지만 로그인이 되지 않습니다). Trac과 Subversion은 Apache에서 작동됩니다. 그런데 Apache가 아직 한글 계정을 지원하지 않기 때문에 한글을 사용할 수 없습니다. Name 부분에는 로그인과 상관 없이 표시만 되는 것이므로 한글을 사용할 수 있습니다. Email은 각자 메일 주소를 입력합니다. 여기에 입력한 메일 주소로 티켓 변경 사항등을 받아 볼 수 있습니다.

사용자별 권한 관리

Trac을 사용하는 사용자들 중에서는 개발팀이 아닌 사용자도 있을 것입니다. 개발팀 이외에는 소스코드를 볼 필요가 없으면, 해당 권한을 조정하면 됩니다. 마찬가지로 각자 맡은 임무나 상황에 따라 권한을 조정하면 됩니다.

• Trac 권한 설정
  General → Permission으로 이동합니다.
  
  
  그림 13-8 권한 설정
  위 화면은 프로젝트를 처음 만들었을 때의 설정입니다. admin은 TRAC_ADMIN 권한을 가지고 있고 anonymous는 로그인을 하지 않았을 때의 권한입니다. authenticated는 어떤 사용자든 상관 없이 로그인을 했을 때의 권한입니다.
  여기서 사용자를 그룹으로 묶고 그 그룹에 따라 권한을 설정할 수 있습니다.
  
  
  그림 13-9 그룹 설정
  각 사용자를 그룹으로 묶은 화면입니다. 오른쪽의 Add Subject to Group에서 Subject에는 사용자 계정을 입력하고 Group에는 그룹 이름을 입력합니다. 현재 leejaehong, michael, thomas는 developer 그룹이며, bruce, john은 tester 그룹입니다.
  이제 anonymous(로그인 하지 않았을 때)와 tester 그룹은 소스 코드를 볼 수 없게 하고(BROWSER_VIEW, CHANGESET_VIEW), developer 그룹만 소스 코드를 볼 수 있도록 설정하겠습니다.
  
  
  그림 13-10 계정, 그룹별 세부 권한 설정
  anonymous에서는 BROWSER_VIEW와 CHANGESET_VIEW를 체크하고 Remove selected items 버튼을 눌러 권한을 제거하였습니다. 그리고 오른쪽의 Grant Permission에서 Subject에 그룹 이름을 입력하고 Action에서 권한을 선택합니다.
  현재 developer 그룹에는 BROWSER_VIEW, CHANGESET_VIEW 권한이 설정되어 있습니다. 따라서 developer 그룹에 소속된 사용자로 로그인 해야 소스 코드를 볼 수 있습니다. anonymous에서 BROWSER_VIEW, CHANGESET_VIEW 권한을 제거하였고 authenticated에도 이 두 권한이 없으므로 tester 그룹에는 따로 설정을 해줄 필요가 없습니다.
  tester 그룹에는 TICKET_ADMIN 권한이 설정되어 있습니다. 따라서 tester 그룹에 소속된 사용자는 티켓 본문을 마음대로 수정할 수 있습니다. 물론 developer 그룹은 TICKET_ADMIN 권한이 없기 때문에 티켓 본문을 수정할 수 없습니다. TICKET_MODIFY 권한은 새 티켓을 생성하고, 티켓에 답글을 달고 속성을 변경할 수 있지만 한번 올린 본문은 수정할 수 없습니다.
  Subject에 각 사용자 계정을 입력하고 Action에서 각 권한을 선택하여 설정해 주면, 각 사용자 별로 권한을 다르게 지정해 줄 수 있습니다.

• Subversion 권한 설정
  trac.ini → trac으로 이동합니다.
  
  
  그림 13-11 authz_file, authz_module_name, default_charset 설정
  authz_file에 C:\Repos\authz, authz_module_name에 hello, default_charset에 cp949로 설정되어 있는지 확인합니다.
  이제 저장소의 권한을 설정해 주어야 합니다. C:\Repos\authz 파일을 열고 다음과 같이 수정합니다. Trac에서 소스 코드를 볼 수 있는 권한을 조정한다고 해서 끝나는 것이 아닙니다. 아래 authz 파일을 설정해 주지 않으면 Trac에서는 소스 코드를 볼 수 없게 설정했다 하더라도, Subversion 저장소에서 소스 코드를 체크아웃 하여 가져갈 수 있습니다. 따라서 아래와 같이 모든 사용자(*)의 읽기, 쓰기 권한을 막고 developer 그룹을 지정한 뒤 deveoper 그룹에만 읽기 쓰기 권한(rw)을 설정해야 합니다.
  다음은 leejaehong, michael, thomas를 developer 그룹으로 지정하였습니다. hello 저장소에는 developer 그룹만 읽기 쓰기가 가능하도록 설정하였습니다.

[groups]
developer = leejaehong, michael, thomas

[example:/]
*=rw

[release:/]
*=rw

[hello:/]
* =
@developer = rw

이 authz 파일은 developer 그룹에 소속된 사용자 별로 권한을 지정해 줄 수도 있습니다.

[hello:/]
* =
@developer = rw

[hello:/branches]
* =
leejaehong = rw

이렇게 설정하면 hello 프로젝트의 branches 디렉터리에는 leejaehong 사용자만 접근 할 수 있고 나머지 사용자는 접근 할 수 없습니다. @developer = r 처럼 읽기 권한만 줄 수도 있습니다. 이 권한 설정은 Subversion 저장소에서 소스 코드를 체크아웃할 때도 적용되며, Trac의 Browse Source에도 적용됩니다. 즉 leejaehong으로 로그인하면 branches 디렉터리가 표시되지만 developer 그룹의 다른 사용자로 로그인 하면 branches 디렉터리가 표시되지 않습니다.

티켓 설정

프로젝트를 진행하면서 사용할 티켓의 속성을 설정해 줄 차례입니다. 개발 계획, 요구 사항이나 버그가 발생하면 티켓을 올리게 되는데, 개발 계획, 요구 사항, 버그를 구분할 수 있도록 설정을 해줘야 합니다. 그리고 티켓에 해당하는 결과물(실행 파일, DLL, 라이브러리 등)을 지정할 수 있도록 컴포넌트, 버전 설정을 합니다. 프로젝트 전체의 목표점을 지정하기 위해서는 마일스톤을 설정합니다. 개발 프로세스에 따라 티켓 완료(Resolutions) 부분도 설정해 줄 필요가 있습니다.

• 컴포넌트
  Trac에서는 컴포넌트라는 개념을 사용하고 있습니다. 이 컴포넌트는 프로젝트에서 하나의 기능을 담당하는 일부분을 지칭할 때 사용합니다. 버그 보고나 요구 사항이 있을 때 티켓을 생성하는데 문제가 되는 부분이 어느 부분인지 지정할 때 사용합니다. 또는 기능 개발을 할 때 개발하고자 하는 부분을 지정할 때에도 사용합니다.
  예를 들면 인스턴트 메신저를 개발한다고 할 때 코어 프로그램, 유저 인터페이스(UI), 네트워크 프로토콜, 서버 프로그램 등으로 나눈 것을 컴포넌트라고 할 수 있습니다. 이렇게 소스 레벨에서 컴포넌트를 구분할 수도 있고, messenger.exe, protocol.dll 처럼 빌드된 파일별로 컴포넌트를 구분할 수도 있을 것입니다.
  소스 레벨에서 컴포넌트를 구분하는 것은 순수 개발 단계에서 사용하는 것이 좋습니다. 그리고 제품이 어느 정도 완성된 시점에서는 파일별로 컴포넌트를 구분하는 것이 좋습니다. 개발자들끼리 Trac을 사용한다면 소스 레벨에서 구분 된 컴포넌트를 쉽게 알아볼 수 있습니다. 하지만 소스 코드를 볼 수 없는 테스트팀이나 기술 지원 인력들은 소스 레벨에서 구분 된 컴포넌트를 알아보기가 힘들 수 있습니다. 테스트팀이나 기술 지원 쪽에서 보고되는 버그나 요구 사항은 언제나 빌드된 파일이 기준이기 때문입니다.
  따라서 티켓 사용자의 특성을 고려하여 컴포넌트를 지정하는 것이 중요합니다.
  이번 예제에서는 소스 레벨에서 컴포넌트를 구분하지 않고 빌드된 파일별로 컴포넌트를 구분하겠습니다.
  
  
  그림 13-12 컴포넌트 설정
  Trac 프로젝트를 처음 만들면 component1, component2가 만들어져 있는데 이것은 필요 없으므로 지워도 상관 없습니다. 오른쪽 Add Component 부분에서 Name에는 실행 파일(DLL 또는 기타 결과물)의 이름을 입력하고, Owner에는 해당 결과물의 담당자를 지정합니다. [그림 13-12]와 같이 hello.exe를 추가합니다. Owner에는 각자 만든 사용자를 지정합니다.
  hello.exe를 클릭하면 컴포넌트의 이름과 Owner를 수정할 수 있습니다. Default로 지정한 컴포넌트는 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

• 마일스톤
  다른 이슈 트래커와는 달리 Trac에서는 마일스톤이라는 개념을 사용하고 있습니다. 이 마일스톤은 프로젝트를 진행하면서 도달해야 하는 목표점을 지정할 때 사용합니다.
  일반적인 소프트웨어로 치면 마일스톤은 프로젝트의 주 버전(Major Version)이라고 할 수 있습니다. 하나의 프로젝트 안에는 여러 가지 파일들이 포함될 것이고 각 파일들은 각자의 버전과 빌드 넘버를 가지고 있을 것입니다. 이것을 모두 묶어 제품화했을 때의 버전입니다. 마이크로소프트 윈도우를 예로 들면 Windows NT 4.0, Windows 2000(NT 5.0), Windows XP(NT 5.1), Windows Server 2003(NT 5.2), Windows Vista(NT 6.0) 처럼 NT 4.0, NT 5.0 하는 것들이 마일스톤이라 할 수 있습니다. 물론 제품화 되기 전에 Alpha, Beta 및 내부 버전들도 포함됩니다.
  
  
  그림 13-13 마일스톤 설정
  Trac 프로젝트를 처음 만들면 milestone1, 2, 3, 4가 만들어져 있는데 이것들도 필요 없으므로 지워도 상관 없습니다. 오른쪽 Add Milestones 부분에서 Name에는 마일스톤 이름을 입력하고, Due에는 해당 마일스톤의 예상 완료 일자를 입력합니다. 예상 완료 일자는 2008-01-01 형식으로 입력합니다. [그림 13-13]과 같이 Beta, 1.0, 2.0을 추가합니다.
  마일스톤 이름을 클릭하면 마일스톤의 이름과 예상 완료 일자를 수정할 수 있습니다. Default로 지정한 마일스톤은 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

• 우선순위
  우선순위는 말 그대로 티켓을 처리할 우선순위를 지정하는 것입니다. 개발팀은 이 우선순위의 높낮이에 따라 어떤 일을 빨리 처리할지 결정합니다.
  
        1. 프로그램은 잘 실행되는데 메뉴에 오타가 있다. - 낮음
        2. 특정 메뉴를 실행하면 에러 메시지가 출력되면서 종료된다. - 높음
  
  메뉴의 오타 보다는 프로그램이 종료되는 버그가 더 심각하므로 우선순위를 다르게 지정하여, 프로그램이 종료되는 버그를 먼저 처리하도록 할 수 있습니다.
  
  
  그림 13-14 우선순위 설정
  Trac 프로젝트를 처음 만들면 blocker, critical, major, minor, trivial이 만들어져 있습니다. 이 부분은 그대로 사용해도 되고, 각자 상황에 맞게 설정하여 사용해도 됩니다. 오른쪽 Add Priority 부분에서 Name에 우선순위의 이름을 입력합니다. Order는 우선순위를 지정하는 것인데 숫자가 낮을 수록 우선순위는 높습니다. 위 화면과 같이 높음, 중간, 낮음을 추가합니다.
  우선순위 이름을 클릭하면 우선순위 이름을 수정할 수 있습니다. Default로 지정한 우선순위는 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

• 티켓 완료
  티켓 완료(Resolutions)는 티켓에 대한 일을 끝냈을 때 티켓을 완료하는 동작을 지정하는 것입니다. 요구 사항이나 버그를 모두 처리하였다면 수정 완료(fixed), 좀더 두고봐야 할 때에는 보류(pending), 요구사항이나 버그가 이미 수정되었거나 버그가 아닐 때에는 해당 안됨(invalid)과 같이 티켓에 지정하는 것입니다. 티켓 완료 동작을 지정하면 해당 티켓은 닫히게(closed) 됩니다.
  
  
  그림 13-15 티켓 완료 설정
  Trac 프로젝트를 처음 만들면 fixed, invalid, wontfix, duplicate, worksforme가 만들어져 있습니다. 이것 또한 그대로 사용해도 되고, 각자 상황에 맞게 설정하여 사용해도 됩니다. 오른쪽 Add Resolution 부분에서 Name에 티켓 완료 동작을 입력합니다. 위 화면과 같이 수정 완료, 보류, 해당 안됨을 추가합니다.
  티켓 완료 동작을 클릭하면 해당 동작의 이름을 수정할 수 있습니다. Default로 지정한 완료 동작은 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

• 티켓 타입
  티켓을 생성할 때 개발 계획, 요구 사항, 버그 등으로 티켓의 종류를 지정할 수 있습니다. 이런 것들 이외에도 필요에 따라서 여러가지 티켓 타입을 추가 할 수 있습니다.
  버그 티켓 타입은 말 그대로 버그를 보고할 떄 사용합니다.
  요구 사항 티켓 타입은 프로그램의 기능 추가 요청, 메시지 추가 요청 등에 사용합니다. 프로젝트에 따라서 한 번 설계를 끝내면 더 이상의 요구사항을 받지 않을 때에는 이 요구사항 티켓 타입을 사용하지 않을 수도 있습니다.
  개발 계획 티켓 타입은 개발자들만 사용하는 티켓 타입입니다. 프로젝트에서 특정 부분의 개발을 진행하고자 할 때 사용합니다.
  
  
  그림 13-16 티켓 타입 설정
  Trac 프로젝트를 처음 만들면 defect, enhancement, task가 만들어져 있습니다. 이것들을 그대로 사용해도 되고, 각자 상황에 맞게 설정하여 사용해도 됩니다. 오른쪽의 Add Ticket Type 부분에서 Name에 티켓 타입을 입력합니다. [그림 13-16]과 같이 버그, 요구 사항, 개발 계획을 추가합니다.
  각 티켓 타입을 클릭하면 해당 티켓 타입을 수정할 수 있습니다. Default로 지정한 티켓 타입은 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

• 버전
  요구 사항이 있거나 버그가 발생하였을 때 어느 버전의 것인지 알 수 있도록 버전을 설정해주어야 합니다.
  
  
  그림 13-17 버전 설정
  Trac 프로젝트를 처음 만들면 1.0, 2.0이 만들어져 있습니다. 이것들은 필요 없으므로 지워도 됩니다. 우리는 버전 자동 업데이트 스크립트를 이용하여 자동으로 버전을 증가시키고 Trac에도 버전을 등록하도록 설정을 하였습니다. 따라서 이 부분은 직접 추가해 줄 필요는 없습니다.
  마찬가지로 각 버전을 클릭하면 해당 버전을 수정할 수 있습니다. Default로 지정한 버전은 티켓을 생성할 때 기본적으로 선택되어 있게 됩니다.

최초 소스 업로드

Trac과 Subversion 프로젝트 생성이 끝났으니 이제 최초 소스를 저장소에 업로드해야 합니다. Visual C++ 2005로 프로젝트를 처음 생성한 것 그대로 저장소에 커밋 할 것입니다. 절대 어느정도 개발을 하고 업로드 한다는 생각은 하지 않기를 바랍니다. 최초 순간부터 빈 소스를 저장소에 넣어두고 프로젝트를 시작하도록 합니다.

이제 개발자 PC로 이동합니다. 그리고 TortoiseSVN으로 http://192.168.1.100/svn/hello/trunk (https 프로토콜을 사용한다면 https://192.168.1.100/svn/hello/trunk)를 체크아웃 합니다. 개발자들은 대부분 특정한 디렉터리에 프로젝트들을 모아 놓을 것입니다.

여기서는 C:\project 디렉터리 아래에 체크아웃 하겠습니다. 현재 체크아웃한 디렉터리인 C:\project\hello 안에는 아무 파일도 들어있지 않습니다.


그림 13-18 hello 프로젝트를 C:\project\hello에 체크아웃

Visual C++ 2005로 콘솔 프로젝트를 만듭니다(Visual C++ 6.0은 부록 참고). Visual C++ 2005를 실행하고 File → New → Project를 선택합니다.


그림 13-19 Visual Studio 2005 새 프로젝트 생성

Finish를 눌러 프로젝트를 생성합니다.


그림 13-20 Win32 Application Wizard

버전 정보도 필요하기 때문에 Solution Explorer에서 Resource Files를 선택하고 마우스 오른쪽 버튼을 누른 뒤 팝업 메뉴에서 Add → Resource...를 선택합니다.


그림 13-21 Visual Studio 2005에서 리소스 추가 방법

Version을 선택하고 New 버튼을 누릅니다.


그림 13-22 추가할 리소스 선택

이제 버전 정보가 추가되었습니다. 모든 파일을 저장하고 Visual C++ 2005를 닫습니다.


그림 13-23 프로젝트 생성 완료

프로젝트를 생성하면 위와 같은 모습이 되어 있을 것입니다. 이제 소스 코드를 추가하여 저장소에 커밋합니다. 파일과 디렉터리를 모두 선택하고 TortoiseSVN → Add...를 실행합니다.


그림 13-24 Visual Studio 2005로 생성된 프로젝트 파일 추가

그림 13-25 추가할 파일 선택

여기서 주의할 점은 확장자가 .ncb, .aps, .user인 파일은 제외합니다.

.ncb 파일은 VS 에디터 창에서 변수와 함수를 빠르게 찾아갈 수 있도록 해주는 임시 파일입니다. 이 파일은 삭제해도 VS를 실행하면 다시 생성되므로 저장소에는 추가할 필요가 없습니다. .aps 파일은 리소스의 순서를 저장하고 있는 임시 파일입니다. 마찬가지로 삭제해도 VS를 실행하면 다시 생성되므로 저장소에 추가할 필요는 없습니다. .user 파일은 vcproj.컴퓨터 이름.사용자 이름.user 형식으로 만들어지는데 개인 설정을 저장하는 파일입니다. 어떤 파일들을 열었고 브레이크 포인트는 어디에 설정했는지 저장하고 있습니다. 따라서 이 파일도 삭제하고 VS를 실행하면 다시 생성되고, 매번 수정되는 파일이기 때문에 저장소에 추가할 필요는 없습니다.

그림 13-26 커밋 로그 메시지 입력 화면

커밋 로그 메시지를 입력하고 커밋합니다.

빌드 스크립트 작성

다시 Trac, Subversion, CruiseControl.NET 서버로 돌아옵니다. 이제 방금 만든 hello 프로젝트를 위한 자동 빌드 스크립트를 작성해야 합니다.

http://192.168.1.100/svn/hello/trunk (https://192.168.1.100/svn/hello/trunk)를 C:\build\hello 디렉터리에 체크아웃 합니다.

그림 13-27 hello 프로젝트를 C:\build\hello에 체크아웃

C:\Program Files\CruiseControl.NET\server\ccnet.config 파일을 열고 다음과 같이 작성합니다.

<cruisecontrol>
    <project name="hello.exe">
        <!-- 기본 레이블로 지정 -->
        <labeller type="defaultlabeller">
            <prefix>1.0.0.</prefix>
        </labeller>

        <!-- Subversion 저장소 주소 및 작업 디렉터리 설정 -->
        <sourcecontrol type="svn">
            <trunkUrl>http://192.168.1.100/svn/hello/trunk</trunkUrl>
            <workingDirectory>c:\build\hello</workingDirectory>
        </sourcecontrol>

        <!-- 매일 20:00에 자동 빌드 하도록 설정 -->
        <triggers>
            <scheduleTrigger time="20:00" buildCondition="ForceBuild" name="Scheduled" />
        </triggers>

        <tasks>
            <!-- 자동 버전 업데이트 스크립트 -->
            <exec>
                <executable>powershell.exe</executable>
                <baseDirectory>C:\tools</baseDirectory>
                <buildArgs>C:\tools\rcversion.ps1 "hello.exe" "C:\build\hello\hello\hello.rc"</buildArgs>
            </exec>

            <!-- Visual Studio 2005 빌드 설정 -->
            <devenv>
                <solutionfile>C:\build\hello\hello.sln</solutionfile>
                <configuration>Release</configuration>
            </devenv>

            <!-- 수정 된 소스 코드를 원래대로 되돌림 -->
            <exec>
                <executable>powershell.exe</executable>
                <baseDirectory>C:\tools</baseDirectory>
                <buildArgs>C:\tools\revert.ps1 "C:\build\hello"</buildArgs>
            </exec>

            <!-- trac에 버전을 등록 -->
            <exec>
                <executable>powershell.exe</executable>
                <baseDirectory>C:\tools</baseDirectory>
                <buildArgs>C:\tools\tracversion.ps1 "hello" "hello.exe"</buildArgs>
            </exec>

            <!-- PDB 파일에 Subversion 저장소 정보를 인덱싱 하고, 압축 한 뒤 심볼 서버에 등록 -->
            <exec>
                <executable>powershell.exe</executable>
                <baseDirectory>C:\tools</baseDirectory>
                <buildArgs>C:\tools\symbols.ps1 C:\build\hello C:\build\hello\release hello.exe</buildArgs>
                <buildTimeoutSeconds>10</buildTimeoutSeconds>
            </exec>

            <!-- 빌드된 결과물을 Releases 디렉터리 아래 각 프로젝트 디렉터리로 복사 -->
            <buildpublisher>
                <sourceDir>C:\build\hello\release</sourceDir>
                <publishDir>C:\Releases\hello</publishDir>
                <useLabelSubDirectory>true</useLabelSubDirectory>
            </buildpublisher>

            <!-- 빌드된 결과물을 Release 저장소로 커밋 -->
            <exec>
                <executable>powershell.exe</executable>
                <baseDirectory>C:\tools</baseDirectory>
                <buildArgs>C:\tools\release.ps1 C:\Releases\hello C:\build\hello</buildArgs>
            </exec>
        </tasks>
    </project>
</cruisecontrol>

• 전체 목차
• 1장 - 소프트웨어 개발 자동화
• 2장 - Subversion으로 소스코드 관리하기
• 3장 - PowerShell로 자동화하기
• 4장 - Subversion과 Symbol 파일 연동
• 5장 - CruiseControl.NET으로 빌드 자동화하기
• 6장 - Apache와 Subversion 연동
• 7장 - Trac
• 8장 - CruiseControl.NET
• 9장 - Release Server
• 10장 - 백업
• 11장 - Subversion 관련 도구
• 12장 - 문서화
• 13장 - 프로젝트 준비
• 14장 - 프로젝트 진행
• 15장 - 실전에서 발생하는 문제들
• 부록