Visual Studio Application Lifecycle Management 시작

이 항목의 내용은 Visual Studio Team Foundation Server의 뛰어난 가치 제안과 유용한 시작 지침을 제공하는 Jason Zander 블로그의 2009년 10월 게시물에서 발췌하여 업데이트한 것입니다. Team Foundation Server에 이미 익숙하여 바로 시작하기를 원하는 사용자를 위해 이 항목에서는 소프트웨어 개발 팀에서의 역할에 따라 적절한 항목으로 연결되는 링크도 제공합니다.

Zander는 Visual Studio 담당 부사장입니다. 이 항목에 나오는 스크린 샷은 최종 제품 버전에 맞게 업데이트한 것입니다.

항목 내용

  • 자습서: Microsoft Visual Studio Team Foundation Server 2010 시작

  • Team Foundation Server 2010의 역할 기반 작업

자습서: Microsoft Visual Studio Team Foundation Server 2010 시작

Team Foundation Server의 새로운 기본 구성에서는 소스 제어, 작업 항목 및 빌드를 지원하는 설치하기 쉬운 버전의 Team Foundation Server를 제공합니다. 이 구성을 사용하면 Visual SourceSafe 자산을 손쉽게 마이그레이션할 수 있을 뿐 아니라 설치 중에 새 기능을 선택할 수 있습니다. 여기에서는 이 시스템의 사용 방법을 단계별로 설명하고자 합니다. 

이 게시물은 이전에 Team Foundation Server를 설치하거나 사용해 보지 않은 사용자에게 매우 유용할 것입니다. Team Foundation Server는 보고, SharePoint 제품과의 통합, 여러 도메인 간의 지원, 분산 데이터베이스 등을 포함한 복잡한 환경을 지원할 수 있습니다. 여기에서는 이러한 기능에 대해 설명하는 것이 아니라, "Team Foundation Server가 어떤 점에서 유리한지"를 이해할 수 있도록 돕고 처음 사용하는 사용자를 위해 이 시스템의 사용 방법을 설명하는 것이 목적입니다. 

먼저 "Team Foundation Server가 어떤 점에서 유리한지"에 대해 살펴보겠습니다. Team Foundation Server의 목적은 여러 역할 간의 공동 작업을 정말로 쉽게 해 주는 다양한 도구가 포함된 중앙 리포지토리를 만드는 것입니다. 서로 다른 여러 시스템을 다음과 같이 연결해 볼 수 있습니다.

Team Foundation Server의 이점

이 경우 각 시스템에는 독자적인 자산 ID 집합, 명령 및 도구가 있습니다. 이 상태로는 여러 대의 맞춤형 스테레오 구성 요소를 연결하려는 것과 같습니다. 연결하는 데 성공한다 해도 연결하기까지는 많은 수고가 필요할 것이며 어떤 부분에서는 미흡한 면도 있을 것입니다.

이러한 항목을 모두 통합할 수 있는 시스템이 있고 이 시스템을 통해 기본 워크플로를 수행할 수 있다면 더 좋을 것입니다.

우수한 통합

이 통합은 매우 일반적인 몇 가지 시나리오를 가능하게 해 줍니다. 평소 저는 소스 코드를 편집하고, 제품을 빌드 및 테스트하고, 버그를 정리 및 수정하면서, 말하자면 비누칠하고 헹구고 반복하는 일로 하루를 보내곤 합니다. 하지만 통합된 단일 리포지토리로 전체 워크플로가 지원되는 경우에는 모든 항목이 서로 관련될 수 있습니다. 예를 들어 버그 수정 사항을 체크 인할 때는 변경 집합을 기록하여 해당 오류가 해결되는지 확인하고 싶은 경우가 있습니다(아래 샘플 참조).

Team Foundation Server의 기본 구성을 사용하면 바로 이런 작업이 가능하므로 단순히 소스 제어 기능만 사용하는 것에 비해 매우 유리합니다. 그런 다음 전체 버전의 Team Foundation Server는 자동화된 테스트, 가상 랩 배포, 아키텍처 유효성 검사 등을 비롯한 새 기능을 추가합니다. 이렇게 하면 워크플로가 다음과 같이 확장됩니다.

확장된 워크플로

Visual Studio를 사용할 때 이러한 새 구성 요소 중 어떤 구성 요소를 추가할지 결정할 수 있습니다.

Team Foundation Server에 액세스하는 방법에는 여러 가지가 있습니다. 엔지니어는 대개 Visual Studio 버전 중 하나에서 액세스합니다. 그러나 테스터의 경우에는 새로운 Test Manager 제품(Visual Studio 설치가 필요하지 않음)을 사용할 수 있습니다. 프로젝트 관리자의 경우에는 웹 인터페이스, Microsoft Excel, Microsoft Project, 또는 Visual Studio 2010에서 새로 추가된 대시보드용 Microsoft Office SharePoint Server 2007 지원도 사용할 수 있습니다. 이에 대해서는 나중에 다시 설명하겠습니다(Team Foundation Server 2010의 역할 기반 작업 참조 - 편집자 주).

이 게시물의 나머지 부분에서는 처음 만드는 프로젝트에 기본 구성을 사용하는 Team Foundation Server를 사용해 보는 방법을 단계별로 설명하겠습니다.

시작

개념적인 내용을 이해했으면 이제 본격적으로 연결을 해 볼 차례입니다. 먼저 Brian Harry의 Team Foundation Server 게시물(게시물 보기)에 설명된 단계를 수행하여 DefaultCollection이라는 충분히 독창적인 이름의 기본 컬렉션과 함께 필요한 모든 소프트웨어를 컴퓨터에 설치해야 합니다.

이때 Visual Studio에서 Team Foundation Server 컬렉션에 연결할 수 있습니다. 가장 쉬운 연결 방법은 팀 메뉴를 사용하는 것입니다. 홈 페이지의 링크를 사용해도 됩니다.

Team Foundation Server에 연결

Team Foundation Server가 있는 서버를 찾기 위한 대화 상자가 표시됩니다. 이 예에서 Windows 7 컴퓨터의 이름은 JLZW7입니다. 추가 단추를 사용하여 목록에 서버를 추가하고 닫기를 클릭합니다.

서버 추가

이제 콤보 상자에서 서버를 선택하고 DefaultCollection을 선택한 다음 연결을 클릭하면 됩니다.

연결 클릭

이제 팀 탐색기 탭에 선택한 서버 연결과 DefaultCollection이 표시되지만 항목을 저장할 Team Foundation Server 프로젝트는 아직 없습니다.

팀 탐색기

저는 이 자습서에서 샘플 솔루션으로 사용하기 위해 새 Windows Form 프로젝트를 만들었습니다(파일, 새 프로젝트, Windows Forms). 이 새 코드 프로젝트를 소스 제어에 추가하려고 하면 오류가 발생합니다. 예를 들면 다음과 같습니다.

새 Windows Form 프로젝트 추가

"소스 제어에 솔루션 추가" 메뉴 항목을 선택하고 나면 다음과 같이 "TF206018: 팀 프로젝트가 설정되지 않았거나 사용자에게 현재 컬렉션에 있는 팀 프로젝트에 액세스할 수 있는 권한이 없으므로 소스 제어에 항목을 추가할 수 없습니다."라는 오류가 발생합니다.

팀 프로젝트 소스 제어 폴더가 없음 오류

이 오류는 그렇게 직관적이지는 않습니다. 특히 프로젝트라는 용어는 Team Foundation Server와 Visual Studio 코드 솔루션 내부 모두에 사용되었지만 이 둘은 상이합니다. 이 오류는 작업을 위한 모든 자산을 포함할 실제 Team Foundation Server 프로젝트를 만들어야 한다는 것을 의미합니다. 다음과 같이 팀 탐색기에서 컬렉션을 마우스 오른쪽 단추로 클릭하고 새 팀 프로젝트를 선택합니다.

팀 프로젝트 만들기

이 예에서는 지불 계정 시스템을 위한 Team Foundation Server 프로젝트를 만들려고 합니다. 이 프로젝트에는 전체 시스템에 필요한 모든 솔루션, 데이터 등이 포함됩니다. 데이터를 입력한 후 다음을 클릭합니다.

팀 프로젝트 이름 지정

Agile 템플릿이 기본값이지만 CMMI를 선택해도 됩니다. 프로젝트 템플릿 형식에 대한 자세한 내용은 MSDN에서 찾아볼 수 있습니다. TDD 같은 Agile 방법론을 사용하는 경우에는 Agile 템플릿을 사용하는 것이 좋습니다. 템플릿을 선택한 후 마침만 클릭하면 됩니다.

프로세스 템플릿 선택

프로젝트가 만들어지는 동안 상태가 다양하게 업데이트됩니다.

팀 프로젝트 작성 시 상태 업데이트

다음과 같이 프로젝트가 만들어진 후 닫기 단추를 클릭합니다.

팀 프로젝트 만들기 성공

이제 팀 탐색기에 작업 항목, 빌드 및 소스 제어를 저장할 수 있는 프로젝트가 표시됩니다.

팀 탐색기에 표시된 새 프로젝트

이 시점에서 프로젝트 컬렉션을 업데이트할 수 있습니다. Team Foundation Server에 새 솔루션을 다시 추가해 봅시다. 다음과 같이 솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 "소스 제어에 솔루션 추가"를 선택합니다.

소스 제어에 솔루션 추가

이때 Team Foundation Server에 솔루션을 위한 새 폴더를 만들거나 기본 폴더를 그대로 사용할 수 있습니다. 그런 다음 확인 단추를 클릭합니다.

Team Foundation Server에 솔루션 저장

소스 제어에 솔루션이 추가되고 나면 솔루션 탐색기에서 소스 제어가 적용되는 파일 앞에 '+' 기호가 표시됩니다.

새로 추가한 솔루션이 포함된 솔루션 탐색기

솔루션을 게시하기 위해 수행되는 목록 소스 제어 동작도 볼 수 있습니다. 다음과 같이 설명을 추가하고 체크 인을 클릭합니다.

소스 제어에 솔루션 체크 인

예를 클릭하여 체크 인을 확인합니다.

체크 인 확인

이제 새 솔루션이 Team Foundation Server에 추가되어 작업 항목용으로 사용할 수 있습니다.

작업 항목

웹 프런트 엔드와 Test Manager 도구를 통해 팀 탐색기를 사용하여 Visual Studio 내에서 직접 작업 항목을 만들 수 있습니다. 작업 항목을 보려면 팀 탐색기를 열고 작업 항목, 팀 쿼리, 반복 1을 차례로 확장합니다. 그런 다음 활성 버그 등의 쿼리를 두 번 클릭하면 사용 가능한 모든 항목을 볼 수 있습니다.

작업 항목 만들기

예제 Team Foundation Server 프로젝트는 비어 있으므로 목록에 활성 버그가 표시되지 않습니다.

활성 버그가 없는 팀 프로젝트

이제 실무에 사용할 새 항목을 만들어 보겠습니다. 팀, 새 작업 항목 메뉴를 선택합니다. 이 메뉴에서 기능, 오류 등을 추적하기 위한 몇 가지 유형의 작업 항목을 만들 수 있습니다. 여기에서는 버그를 선택해 봅니다.

새 작업 항목 메뉴

새 버그에 필요한 데이터를 입력하고 작업 항목 저장을 클릭하여 해당 내용을 데이터베이스에 커밋합니다.

버그 작업 항목 만들기

이제 활성 버그 쿼리 목록을 새로 고치면 새 버그가 표시됩니다.

쿼리를 새로 고쳐 새 버그 확인

실제 버그를 추가하여 프로젝트를 수정해 보겠습니다. 예제에서는 기본 Windows Forms 응용 프로그램을 만들었습니다. 다음과 같이 제목을 업데이트해 봅니다.

새 프로젝트의 두 번째 버그

이제 버그를 수정해야 합니다. 솔루션 탐색기로 돌아가서 Form1.cs를 선택하고 "편집하기 위해 체크 아웃"을 선택합니다.

소스 제어에서 파일 체크 아웃

체크 아웃 단추를 클릭하여 작업을 확인합니다.

체크 아웃 확인

이제 파일 옆에 확인 표시가 나타나므로 해당 파일이 편집을 위해 열려 있음을 알 수 있습니다.

소스 제어에서 체크 아웃된 파일

주 창의 Text 속성을 업데이트하면 Visual Studio에서는 종속 파일을 자동으로 체크 아웃합니다.

Visual Studio에서 추가 파일 체크 아웃

이 예제는 Windows Forms 응용 프로그램이지만 모든 솔루션/프로젝트 형식에서 작동합니다. 코드를 적절하게 변경했으므로 이제 Visual Studio의 맨 아래에서 보류 중인 변경 내용 탭을 선택합니다.

보류 중인 변경 내용 선택

이 예제에서는 버그를 수정할 것이므로 작업 항목 아이콘 단추를 클릭합니다.

작업 항목 선택 단추

제목 오류를 추적하는 버그 2를 선택합니다. 이번 체크 인에서는 이 버그를 수정할 것입니다.

체크 인과 버그 연결

필요한 설명을 추가하고 체크 인을 클릭한 다음 예를 클릭하여 작업을 확인합니다.

체크 인에 메모 추가

체크 인 확인

버그 2를 새로 고치면 상태가 해결됨으로 변경되고 기록이 업데이트됩니다.

연결된 버그가 자동으로 해결됨

기록에는 변경 집합(소스 제어 변경 내용의 집합)이 자동으로 포함되어 있습니다.

기록에 추가된 변경 집합

솔루션을 제공하기 위해 필요할 경우 이 시점에서 작업을 계속하여 버그를 만들고 수정할 수 있습니다.

Team Foundation Server를 탐색하는 다른 방법

앞에서 설명한 대로 Visual Studio를 사용하지 않고도 Team Foundation Server 리포지토리에 액세스할 수 있습니다. 이는 웹 및 Microsoft Office 같은 다른 클라이언트와의 긴밀한 통합을 통해 구현되었습니다. 예를 들어 웹 브라우저를 실행하고 http://jlzw7:8080/tfs/라는 서버 이름(여기서 8080은 기본 포트)을 사용하기만 하면 서버로 바로 이동할 수 있습니다.

Team Web Access로 이동

이제 컬렉션과 프로젝트를 탐색할 수 있습니다. 앞에서 만든 새 AccountsPayable 프로젝트를 선택한 다음 계속 단추를 선택하면 자세한 내용이 표시됩니다. 이 예제에서는 작업 항목 탭으로 이동하여 새로 해결된 버그를 포함한 시스템의 버그를 찾을 수 있습니다.

Team Web Access의 팀 프로젝트

이 방법은 Visual Studio를 설치하지 않고도 모든 컴퓨터에서 프로젝트를 탐색할 수 있는 매우 쉬운 방법입니다. Microsoft Excel, Microsoft Project 등을 사용하기 위한 유사한 지원도 있습니다. 이러한 유형의 액세스 방법을 통해 프로젝트에 참여하는 모든 사람(엔지니어 및 프로젝트 관리자)이 쉽게 공동 작업을 수행할 수 있습니다.

이제 작업을 완료하는 데 사용할 수 있는 매우 유용한 자산 집합을 갖게 되었습니다. 현재 Visual SourceSafe를 사용하는 사용자라면 이 정도의 지원만으로도 매우 만족할 것입니다. 이제 이 자습서는 내려 놓아도 되며, 나중에 이 자습서에서 베타 1을 사용하여 보여 준 테스트 시나리오와 같은 고급 기능을 사용해 보려는 경우 다시 자습서를 참조할 수 있습니다.

빌드 지원

워크플로에서 그 다음으로 일반적인 부분은 대개 제품 빌드를 자동화하는 것입니다. Brian의 설치 지침을 따랐다면 컴퓨터에 Team Foundation Server와 함께 로컬 빌드 지원이 설치되어 있을 것입니다. 첫 번째 단계에서는 팀 탐색기로 이동하여 빌드 정의를 마우스 오른쪽 단추로 클릭하고 새 빌드 정의를 선택합니다.

새 빌드 정의 만들기

그러면 코드 프로젝트 속성 페이지와 같은 정의 집합이 제공되며 이를 채워야 합니다.

빌드 정의 페이지

트리거 페이지에서는 빌드를 시작할 시기를 결정할 수 있습니다. 다음과 같은 여러 옵션 중에서 선택할 수 있습니다.

  • 수동 - 기본값으로, 예제에서는 이 옵션을 사용합니다. 이 옵션으로 빌드를 시작해야 합니다.

  • 연속 통합 - 각 체크 인 후마다 새 빌드를 생성하려는 경우에 매우 유용합니다. 이 옵션을 사용하면 나중에 여러 체크 인이 결합될 때까지 기다리지 않고 즉시 새 변경 내용의 유효성을 검사할 수 있습니다.

  • 빌드 롤링 - 여러 변경 내용을 일괄 처리할 수 있으며, 빌드에 어느 정도의 시간이 소요되기 시작하고 모든 빌드를 수행할 수 없을 때 매우 편리합니다.

  • 제어된 체크 인 - 모든 체크 인이 Team Foundation Server로 커밋되기 전에 빌드되도록 할 수 있습니다. 이 옵션을 사용하면 팀의 다른 멤버에게 빌드 중단이 노출되지 않습니다.

  • 예약된 빌드 - 팀 전체에서 시험하는 동안 매일 빌드를 생성하는 데 유용합니다.

목적에 따라 서로 다른 빌드 형식을 사용할 수 있도록 여러 가지 빌드 정의를 만들어 사용할 수 있습니다.

시간 여유가 있다면 모든 탭을 탐색해 봐도 됩니다(각 탭에 대한 자세한 설명은 제품과 함께 제공됨). 하지만 여기에서는 새 빌드를 저장할 위치(이 예제에서는 컴퓨터에 만든 공용 UNC)를 지정하여 빌드 기본값의 노란색 경고 기호를 해결해야 합니다.

빌드 기본값에 UNC 경로 추가

이제 빌드 정의를 Team Foundation Server에 저장할 수 있습니다. 팀 탐색기로 돌아가면 프로젝트의 빌드를 큐에 대기시킬 수 있습니다.

새 빌드 큐 대기

확인 대화 상자가 표시되면 큐 단추를 선택합니다.

빌드 큐 대기 프롬프트

그러면 아래 상태 페이지에 표시된 것과 같이 빌드가 컴퓨터의 큐에 저장됩니다.

큐에 추가된 빌드

큐에 저장된 빌드를 두 번 클릭하면 다음과 같이 자세한 빌드 상태가 표시됩니다.

큐에 대기된 빌드의 세부 상태

여기에서 경고 및 오류를 확인하고, 로그 파일을 보고, 저장 폴더로 이동하는 등의 작업을 수행할 수 있습니다. 예를 들어 "로그 파일 보기" 링크를 선택하면 다음과 같이 실행된 빌드 스크립트(하위 집합)가 표시됩니다.

로그 파일의 빌드 스크립트

"저장 폴더 열기" 링크를 선택하면 다음과 같이 저장 위치로 이동됩니다.

빌드 저장 위치

이제 누구나 빌드를 선택하고, 테스트하거나 고객에게 릴리스하는 등의 일상적인 작업을 수행할 수 있습니다.

이제 Team Foundation Server의 모든 기본 기능을 사용하는 데 필요한 내용은 모두 배웠습니다. 

Team Foundation Server 2010의 역할 기반 작업

팀에서 Visual Studio ALM(Application Lifecycle Management)을 사용하기 시작할 경우 관리자는 서버를 설정하고, 프로젝트 관리자는 팀 프로젝트를 만들고, 다른 팀 멤버는 자신의 작업 환경을 설정합니다. 이 항목의 나머지 부분에 나오는 링크에서는 다음과 같은 소프트웨어 개발 역할에 따라 Team Foundation Server를 처음 사용할 때의 작업에 대해 설명합니다.

  • Team Foundation Server의 관리자

  • 프로젝트 관리자

  • 소스 제어 및 빌드 관리자

  • 개별 팀 멤버

Team Foundation 관리자가 수행할 작업

  1. 이 항목의 앞부분에 나온 자습서를 따랐다면 기본 구성을 사용하여 Team Foundation Server를 설치했을 것입니다. 그러나 이전 Team Foundation Server 설치의 업그레이드나 Team Foundation Server 또는 해당 필수 구성 요소 중 하나의 사용자 지정 설치를 비롯한 다른 설치 작업도 수행해야 합니다.

    자세한 내용은 Microsoft 웹 사이트에서 Installation Guide for Team Foundation 항목을 참조하십시오.

  2. 이 항목의 앞부분에 나온 자습서를 따랐다면 Team Foundation Server 설치 중에 프로젝트 작성에 필요한 모든 사용 권한이 자동으로 부여되었을 것입니다. 그 외에도 추가 사용자에게 관리자, 프로젝트 관리자 및 기타 역할을 수행하는 데 필요한 사용 권한을 부여할 수 있습니다.

    자세한 내용은 사용자, 그룹 및 권한 구성을 참조하십시오.

  3. 하드웨어 오류나 그 밖의 이벤트가 발생할 경우 데이터가 백업되도록 하는 유지 관리 계획을 세웁니다. 자세한 내용은 배포 백업 및 복원을 참조하십시오.

  4. 팀의 누군가가 Visual Studio Lab Management를 사용할 경우 Microsoft System Center Virtual Machine Manager를 설치하고 Lab Management를 구성한 다음 가상 환경을 만듭니다.

    자세한 내용은 처음으로 Lab Management 구성을 참조하십시오.

  5. 팀의 누군가가 원격으로 빌드를 배포하고 테스트를 실행할 경우 실제 또는 가상 컴퓨터에 테스트 컨트롤러와 테스트 에이전트를 설치합니다.

    자세한 내용은 테스트를 실행하거나 데이터를 수집할 테스트 컴퓨터 설정을 참조하십시오.

  6. 이 항목의 앞부분에 나온 자습서를 따랐다면 기본 구성을 사용하여 Team Foundation Build를 설치했을 것입니다. 그러나 필요에 맞게 빌드 환경을 구성하려면 몇 가지 관리 작업을 수행해야 합니다.

    자세한 내용은 Team Foundation Build 관리를 참조하십시오.

  7. 작업 요구 사항이 변경될 경우 배포를 변경하거나 수정하기 위한 옵션을 검토합니다. 자세한 내용은 서버 구성 관리를 참조하십시오.

프로젝트 관리자가 수행할 작업

  1. 사용할 Team Foundation의 클라이언트를 하나 이상 설치합니다.

    자세한 내용은 Visual Studio 설치을 참조하십시오.

  2. 프로젝트 리소스 요구 사항과 팀 프로젝트를 만들 프로젝트 컬렉션을 결정합니다.

    자세한 내용은 팀 프로젝트 시작을 위한 빠른 시작 가이드를 참조하십시오.

  3. 프로세스 템플릿을 선택합니다.

    자세한 내용은 프로세스 템플릿 선택을 참조하십시오.

  4. 팀 탐색기에서 팀 프로젝트를 만듭니다.

    자세한 내용은 팀 프로젝트 만들기를 참조하십시오.

  5. (선택 사항) 팀 프로젝트의 제품 영역 및 중요 시점을 정의합니다.

    자세한 내용은 영역 및 반복 만들기 및 수정을 참조하십시오.

  6. 팀 멤버에게 팀 프로젝트에서 작업하는 데 필요한 권한을 부여합니다.

    자세한 내용은 팀 프로젝트에 사용자 추가를 참조하십시오.

  7. (선택 사항) 특정 팀 멤버에게 추가 사용 권한을 부여합니다.

    사용자나 다른 관리자가 Team Foundation 버전 제어에서의 소스 코드 관리, 빌드 관리, 테스트 및 테스트용 랩 환경 관리 및 그 밖의 프로젝트 수준 작업을 담당할 팀 멤버에게 추가 사용 권한을 제공해야 하는 경우가 있습니다. 이와 같은 경우 개별 팀 멤버 또는 그룹에 특정 사용 권한을 할당할 수 있습니다.

    자세한 내용은 Team Foundation Server 권한에서 다음 단원을 참조하십시오.

    • 빌드 수준 권한

    • 프로젝트 수준 권한

    • 작업 항목 추적을 위한 영역 및 반복 수준 권한

    • 소스 제어 권한

    • 랩 관리 권한

  8. (선택 사항) 보고서 작성자에게 추가 사용 권한을 부여합니다.

    데이터 웨어하우스에 저장된 데이터에 액세스하는 보고서를 만들거나 수정하려면 팀 멤버에게 해당 데이터 웨어하우스를 구성하는 데이터베이스에 대한 읽기 권한이 있어야 합니다. 자세한 내용은 Visual Studio ALM용 데이터 웨어하우스의 데이터베이스에 대한 액세스 부여를 참조하십시오.

  9. 팀 멤버에게 팀 프로젝트 리소스 및 등록 작업에 대해 알립니다.

    자세한 내용은 팀 멤버에게 팀 프로젝트 리소스에 대해 알림을 참조하십시오.

  10. 제품을 계획합니다.

    팀 프로젝트가 MSF for Agile Software Development v5.0용 프로세스 템플릿을 기반으로 하는 경우 제품 계획 통합 문서를 사용하여 제품 백로그를 만들 수 있습니다. 제품 계획 통합 문서를 사용하여 사용자 스토리의 백로그를 관리하고 작업 부하를 여러 반복(스프린트라고도 함)으로 분산할 수 있습니다. 자세한 내용은 제품 계획 통합 문서를 참조하십시오.

    팀 프로젝트가 MSF for CMMI Process Improvement v5.0용 프로세스 템플릿을 기반으로 하는 경우 제품 요구 사항 팀 쿼리를 사용하여 제품 계획을 시작할 수 있습니다. Office Excel에서 이 쿼리를 열고 요구 사항을 추가한 후 요구 사항을 Team Foundation에 게시할 수 있습니다. Office Project를 사용하여 프로젝트를 계획하고 일정을 예약할 수도 있습니다. 자세한 내용은 다음 항목을 참조하십시오.

버전 제어 및 빌드 관리자가 수행할 작업

  1. 버전 제어를 구성합니다.

    자세한 내용은 Team Foundation 버전 제어 관리를 참조하십시오.

  2. Team Foundation Build를 사용하는 경우 각 팀 프로젝트에 대한 빌드 정의를 만듭니다.

    자세한 내용은 응용 프로그램 빌드를 참조하십시오.

개별 팀 멤버가 수행할 작업

  1. 사용할 Team Foundation의 클라이언트를 하나 이상 설치합니다.

    자세한 내용은 Visual Studio 설치을 참조하십시오.

  2. 버전 제어를 위한 작업 영역을 설정합니다.

    자세한 내용은 팀 프로젝트에 사용할 수 있도록 작업 영역 만들기버전 제어에 파일 추가를 참조하십시오.

  3. 작업 및 기타 작업 항목을 만들고, 수정하고, 찾는 방법을 익힙니다.

    자세한 내용은 초보자를 위한 추적 작업을 참조하십시오.

참고 항목

개념

Visual Studio Application Lifecycle Management