Share
Create bookmark
Team Development with Visual Studio® Team Foundation Server
Do you like this document?
Notes
Please login to add notes
- + Cover
- Contents
- + Foreword
-
+
Introduction
- + Part I: Fundamentals
-
+
Part II: Source Control
- + Chapter 3: Structuring Projects and Solutions in Source Control
- + Chapter 4: Structuring Projects and Solutions in Team Foundation Source Control
-
+
Chapter 5: Defining Your Branching and Merging Strategy
- Objectives
- Overview
- How to Use This Chapter
- Scenarios for Branching and Merging
- Common Scenarios in Practice
- Example Folders and Their Purpose
- Scenario 1 — No Branches
- Scenario 2 — Branch for Release
- Scenario 3 — Branch for Maintenance
- Scenario 4 — Branch for Feature
- Scenario 5 — Branch for Team
- Logical Structure
- Release Scenario
- Isolated Development Scenario
- Branching Considerations
- Large Project Considerations
- Summary
- Additional Resources
- + Chapter 6: Managing Source Control Dependencies in Visual Studio Team System
- + Part III: Builds
-
+
Part IV: Large Project Considerations
-
+
Part V: Project Management
-
+
Chapter 11: Project Management Explained
- Objectives
- Overview
- How to Use This Chapter
- Project Management Summary
- Traditional Project Management Issues
- + Project Management Features in Team Foundation Server
- Creating and Managing Projects with Team Foundation Server
- + Strategies for Team Projects
- + Process Management
- Security and Permissions
- + Work Item Management
- Progress and Reporting
- Summary
- Additional Resources
-
+
Chapter 12: Work Items Explained
-
+
Chapter 11: Project Management Explained
-
+
Part VI: Process Templates
-
+
Chapter 13: Process Templates Explained
-
+
Chapter 14: MSF for Agile Software Development Projects
- Objectives
- Overview
- How to Use This Chapter
- Workflow for MSF for Agile Software Development
- MSF for Agile Software Development Defaults
- Work Items
- Reports
- Groups and Permissions
- Source Control
- Areas and Iterations
- + Examples of MSF for Agile Software Development in Practice
- Customizing the MSF Agile Process Template
- Summary
- Additional Resources
-
+
Chapter 13: Process Templates Explained
-
+
Part VII: Reporting
-
+
Part VIII: Setting Up and Maintaining the Team Enviornment
- + Chapter 16: Team Foundation Server Deployment
-
+
Chapter 17: Providing Internet Access to Team Foundation Server
- Objectives
- Overview
- How to Use This Chapter
- Key Strategies
- Common Scenarios
- + Using a VPN connection
- + Publishing TFS Through a Reverse Proxy
- + Locating TFS in an Extranet (“Hosted Scenario”)
- + Basic Authentication / SSL
- + Team Foundation Server Proxy
- Remote Build Server
- Summary
- Additional Resources
-
+
Part IX: Visual Studio Team System 2008 Team Foundation Server
-
+
Guidelines: Team Build
-
+
Index
- Strategy
- Branching
- Check-in Policies
- Continuous Integration Builds
- Customization
- Deployment
- Performance
- Projects
- Scheduled Builds
- Test-Driven Development
- Work Items
- Strategy
- Use a Scheduled Build to Produce Regular Builds
- Use a Continuous Integration Build to Get Rapid Feedback on Check-ins
- Use a Rolling Build if CI Builds Are Adversely Impacting Build Server Performance
- Use Branching to Reduce Build Breaks
- Use Check-in Policies to Improve Check-in Quality
- Use Build Notification Alerts to Learn When the Build Has Completed
- + Branching
- + Check-in Policies
- + Continuous Integration Builds
- + Customization
- + Deployment
- + Performance
-
+
Projects
- Avoid Dependencies Across Team Projects
- Use Project References Instead of File References
- Use Web Deployment Project for Web Applications
- Use a Single-Solution Strategy if You Are Working on a Small Team Project
- Use a Partitioned-Solution Strategy if You Are Working on a Large Team Project with Multiple Independent Sub-Projects
- Use a Multiple-Solution Strategy if You Are Working on a Very Large Team Project That Requires Many Dozens of Independent Sub-Projects
- + Scheduled Builds
- + Test-Driven Development
- Build Resources
-
+
Index
-
+
Guidelines: Source Control
- + Index
- + Accessing Version Control
- + Administration
-
+
Branch / Label / Merge
- Use Labels to Mark Builds You Might Need to Return To
- Use Branches to Isolate Supported Releases
- Plan Your Branching Structure Along Merge Paths
- Branch at a High Level, Including Configuration and Source Files
- Do Not Branch Too Deeply
- Do Not Branch Unless You Need To
- Avoid Baseless Merges Where Possible
- Prefer Full Merges to “Cherry-Pick” Merges
- Merge Frequently
- Always Create a Top-Level Folder for a New Team Project to Serve as a Main Branch
- Consider Using the Candidate or Preview Switch to Double-Check Before Merging
- When Renames Are Part of the Merge, Pay Close Attention to the Path That the Tool Recommends
- Be Careful When Resolving Merge Conflicts
- Check In the Results of One Merge At a Time
- Build and Run Tests After the Merge and Prior to Check-in
-
+
Check-in and Check-in Policies
- Only Check In Your Code When You Are Ready to Share It
- Use Shelvesets to Back Up or Share Pending Changes
- Resolve One Work Item per Check-in
- Use Check-in Policies to Enforce Coding Standards
- Use Check-in Policies to Enforce a Code Quality Gate
- Detect When a Policy Has Been Overridden
- Plan to Avoid Conflicts
- + Checkout, Get, and Lock
- + Dependencies
-
+
Distributed / Remote Development
- Make Sure That You Get an Appropriately Sized Disk Drive for Your Proxy
- Create a Scheduled Task to Pull the Latest Files on a Periodic Basis
- Periodically Monitor Proxy Performance Counters and the Event Log
- Configure executionTimeout Based on File Sizes and Bandwidth
- Disable the Proxy if It Is Going to Be Down for an Extended Time Period
- Consider Workspace Cloaking to Reduce Unnecessary File Transfers
- + Migration
-
+
Project / Workspace Management
- Isolate a Single Developer Using Workspaces Rather Than Branches
- Delete and Rename Files by Using Source Control, Not Windows Explorer
- Only Delete and Rename with Your Solution Open
- Create One Team Project per Application if You Want to Move Your Assets Between Application Versions
- Create One Team Project Per Version If You Want to Start Fresh With Each Application Version
- Use Branching to Share Code and Binaries that Require Integration Testing
- Avoid Workspace Mapping to Support Cross-Project Dependencies
- Create Workspace Mappings at the Team Project Root Level
- Use a Unique Local Folder Path on Shared Computers
- Consider Mapping Only Part of the Source Tree
- Structure Your Source Tree to Support Branching
- + Shelving
- Source Control Resources
-
+
Guidelines: Reporting
-
+
Guidelines: Project Management
- + Index
- + Areas and Iterations
- + Check-in Policies
-
+
Process Templates
- Use the MSF Agile Process Template When Working on Projects That Only Require a Lightweight or Informal Process
- Use the MSF CMMI Process Template When Working on Projects Requiring a More Formal Process or Conformance with CMMI Standards
- Consider Using a Minimal Process Template
- Modify an Existing Process Template to Match Your Team’s Process
- + Security Groups and Permissions
-
+
Team Projects
- Create One Team Project per Application if You Want to Migrate Work Items and Other Assets Between Application Versions
- Create One Team Project per Version if You Want to Start with New Work Items and Other Assets with Each Application Version
- Grant Only Required Permissions on Project Assets
- Structure Your Source Tree to Support Branching
- + Work Items
- Team Foundation Project Management Resources
-
+
Practices at a Glance: Team Build
- + Index
- + Administration
- + Check-in Policies
- + Continuous Integration Builds
- + Customization
- + Deployment
-
+
General
- How to Build and Deploy an ASP.NET Application with Team Build
- How to Build a .NET 1.1 Application with Team Build
- How to Build Setup and Deployment Projects with Team Build
- How to Create a Team Build
- How to Create Multiple Build Types
- How to Create a Team Build for a Project That References Assemblies from Another Project
- How to Subscribe to Build E-mail Events
- How to Receive Notifi cation When a Build Has Failed
- How to Start a Build
- How to Verify That the Build Succeeded
- How to View the Build Output
- How to Change the Build Server Location
- How to Change the Build Output Location
- How to Determine What Changesets Are Part of the Build
- How to Change the Reported Build Quality
- + Projects
-
+
Reporting
- How to View Build Quality
- How to View All the Check-ins for a Build
- How to View Work Items or Bugs Closed for a Build
- How to View Open Work Items or Bugs for a Build
- How to Track Velocity from Build to Build
- How to Track Test Case Pass/Fail results for a Build
- How to Review Build Status (BVT Results)
- + Scheduled Builds
- + Test-Driven Development
- Team Build Resources
-
+
Practices at a Glance: Source Control
- + Index
- + Accessing Version Control
- + Administration
-
+
Branch/Label/Merge
- How to Use Labels
- How to Branch
- How to Plan Your Branching Structure
- How to Use Branching to Support a Release
- How to Use Branching to Maintain a Previous Release
- How to Use Branching to Stabilize Your Development and Build Process
- How to Use Branching to Stabilize Feature Development
- How to Use Branching to Stabilize Development Across Teams
- How to Use Branching to Isolate External Dependencies
- How to Retire an Old Release
- How to Perform a Merge
- How to Perform a Baseless Merge
- How to Resolve Merge Conflicts
- + Builds
- + Check-ins and Check-in Policies
- + Checkout, Get, and Lock
- + Code Sharing
- + Dependencies
- + Distributed/Remote Development
- + Migration
- + Project/Workspace Management
- + Security
- + Shelving
- Source Control Resources
-
+
Practices at a Glance: Reporting
- + Index
- + Administration
- + Creation / Customization
-
+
Viewing
- How to Analyze the Status of a Project
- How to Analyze Application Quality
- How to Review Remaining Work
- How to Review Build Status
- How to Review Bugs and Test Results
- How to Review Scheduled Work versus Actual Work on an Iteration
- How to Determine the Owner of the Last Edit on a File
- How to Discover All the Code Changes Made by a Developer
- How to Discover All the Code Changes Made to a File
- How to Discover All the Code Changes Associated with a Specific Work Item
- How to Generate Code Churn Metrics
- How to Generate Workspace Metrics Such as Number of Files, Lines of Code, and Number of Projects
- Team Foundation Reporting Resources
-
+
Practices at a Glance: Project Management
- + Index
- + Check-in Policies
-
+
Project Management
- How to Use Microsoft Project to Manage Your Project
- How to Use Microsoft Excel to Manage Your Project
- How to Create a Minimal Process Template
- How to Customize a Process Template
- How to Customize a Work Item Type Within a Process Template
- How to Customize a Work Item Type Within an Existing Team Project
- How to Create an Iteration
- How to Create an Area
- How to Add a Check-in Event Notifi cation
- How to Set Up a Report Dashboard
- How to Create Folders in Your Source Control Repository
- How to Delete a Project from Team Foundation Server
- Team Foundation Project Management Resources
-
+
Questions and Answers: Source Control
- + Index
- + Accessing Version Control
- + Administration
-
+
Branch/Label/Merge
- When should I use labels?
- How do TFS labels differ from VSS labels?
- What is branching?
- When should I consider branching?
- What are the reasons not to branch?
- How do I use branching to release my application?
- How do I use branching to maintain my application?
- How do I use branching to reduce conflicts between teams?
- How do I use branching to reduce conflicts between features?
- What are the proven practices for branching and merging?
- What is the difference between branching and labeling?
- What is the “path space” branching model?
- How does the TFS promotion model work?
- How do I merge two branches?
- Can I merge across team projects?
- What is a baseless merge?
- What is the code promotion model?
- What is the difference between the logical and physical view of branches?
- If I use the code promotion model, how often should I merge?
-
+
Check-in and Check-in Policies
- What is a changeset?
- What is a check-in policy?
- When and how can I override a check-in policy?
- How do I enforce a policy?
- How do I use a check-in verification system?
- If I modify file names or delete files on the disk, does version control get out of sync?
- How does automatic conflict resolution work?
- How do I resolve conflicts manually?
- How do I avoid conflicts?
- + Checkout, Get, and Lock
- + Distributed/Remote Development
- + Migration
-
+
Project/Workspace Management
- How should I organize my team projects?
- How should I manage dependencies between projects?
- What is a workspace?
- How do I use workspaces to isolate the work of a developer?
- What are the proven practices for workspace mapping?
- When should I create a new Team Project versus a new Branch?
- How should I manage source code that is shared across multiple projects?
- How should I manage binaries that are shared across multiple projects?
- How should I organize my source tree?
- + Shelving
- Source Control Resources
- + How To: Add a New Developer to Your Project in Visual Studio 2005 Team Foundation Server
- + How To: Automatically Run Code Analysis with Team Build in Visual Studio Team Foundation Server
-
+
How To: Create a Custom Report for Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Create a new reporting project
- Step 2 — Create the data sources
- Step 3 — Create a new report in your project
- Step 4 — Modify the report
- Step 5 — Deploy the report to your Team Foundation Server
- Step 6 — Test the report
- Additional Resources
-
+
How To: Create a “Risk over Time” Report for Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Create a New Reporting Project
- Step 2 — Create the Data Sources
- Step 3 — Create a New Report in Your Project
- Step 4 — Modify the Report
- Step 5 — Deploy the Report to your Team Foundation Server
- Step 6 — Test the report
- Additional Resources
- + How To: Create Custom Checkin Policies in Visual Studio Team Foundation Server
- + How To: Create Your Source Tree in Visual Studio Team Foundation Server
-
+
How To: Customize a Process Template in Visual Studio Team Foundation Server
- Applies To
- Summary
- Content
- Objectives
- Overview
- Summary of Steps
- Step 1 — Install Process Editor
- + Step 2 — Choose the Process Template
- Step 3 — Download the Process Template
- Step 4 – Open the Process Template in Process Editor
- Step 5 — Modify Work Item Types
- Step 6 — Modify the Default Work Items
- Step 7 — Modify and Manage Queries
- Step 8 — Modify Areas and Iterations
- Step 9 — Modify Groups and Permissions
- Step 10 — Modify Source Control Settings
- Step 11 — Modify the Project SharePoint Portal
- Step 12 — Modify Reports
- Step 13 — Upload the Modifi ed Process Template
- Additional Resources
-
+
How To: Customize a Report in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objective
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Create a New Reporting Project
- Step 2 — Export the Report You Want to Customize
- Step 3 — Create the Data Sources
- Step 4 — Add the Report to Your Project
- Step 5 — Modify the Report
- Step 6 — Deploy the Report to Your Team Foundation Server
- Step 7 — Test the Report
- Additional Resources
-
+
How To: Manage Projects in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objective
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Choose a Process Template
- Step 2 — Create a Team Project
- Step 3 — Create Security Groups (Optional)
- Step 4 — Add Team Members in Team Foundation Server
- Step 5 — Determine Your Iteration Cycle
- Step 6 — Capture Your Project Scenarios in TFS
- Step 7 — Identify the Scenarios for the Iteration
- Step 8 — Define Your Quality of Service Requirements
- + Step 9 — Plan Your Iteration
- + Step 10 — Monitor Progress
- Area and Iteration Consideration
- Additional Resources
-
+
How To: Migrate Source Code to Team Foundation Server from Visual Source Safe
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Before You Begin
- Summary of Steps
- Step 1 — Back Up Your VSS Database
- Step 2 — Analyze Your VSS Database to Resolve Data Integrity Issues
- Step 3 — Analyze Your Projects in VSS
- Step 4 — Prepare to Migrate Your Projects
- Step 5 — Migrate Your Projects
- Additional Considerations
- Additional Resources
- + How To: Perform a Baseless Merge in Visual Studio Team Foundation Server
-
+
How To: Set Up a Continuous Integration Build in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Create and Test your Build
- Step 2 — Install the Continuous Integration Solution
- Step 3 — Configure the Continuous Integration Solution
- Step 4 — Register for the CheckinEvent Event
- + Step 5 — Test the Continuous Integration Build
- Step 6 — Set Up E-mail Alerts
- Additional Resources
-
+
How To: Set Up a Scheduled Build in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Before You Begin
- Step 1 — Create and Test Your build
- Step 2 — Create the TFSBuild Command Line
- Step 3 — Test the TFSBuild Command Line
- Step 4 — Create a Batch File
- Step 5 — Test the batch file
- Step 6 — Add a Scheduled Task
- Step 7 — Test the Scheduled Task
- Additional Resources
-
+
How To: Structure ASP.NET Applications in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Step 1 — Create Local Folders for Your Web Project
- Step 2 — Create a Blank Solution
- + Step 3 — Add a Web Site to Your Solution
- Step 4 — Add a Class Library (Optional)
- Step 5 — Check Your Solution Structure
- Step 6 — Check your Local Folder Structure
- Step 7 — Add Your Solution to Source Control
- + Shared Code Considerations
- Additional Resources
-
+
How To: Structure Windows Applications in Visual Studio Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Step 1 — Create Local Folders for Your Windows Forms Project
- Step 2 — Create a Blank Solution
- Step 3 — Add a Windows Forms Project to Your Solution
- Step 4 — Add a Control Library (Optional)
- Step 5 — Add a Class Library (Optional)
- Step 6 — Check Your Solution Structure
- Step 7 — Check Your Local Folder Structure
- Step 8 — Add Your Solution to Source Control
- + Shared Code Considerations
- Additional Resources
-
+
How To: Structure Your Source Control Folders in Team Foundation Server
- Applies To
- Summary
- Contents
- Objectives
- Overview
- Summary of Steps
- Step 1 — Create a Workspace Mapping
- Step 2 — Create Your Main Folder
- Step 3 — Create Folders for Your Project Artifacts
- Step 4 — Add Your Solution to Your Source Tree
- Step 5 — Create a Branched Development Folder for Isolation (Optional)
- Step 6 — Create a Releases Folder for Release Builds Isolation (Optional)
- Additional Considerations
- Additional Resources
- + Team Foundation Server Resources
- + Index
This guide shows you how to get the most out of Visual Studio 2005 Team Foundation Server to help improve the effectiveness of your team-based software development. Whether you are already using Team Foundation Server or adopting from scratch, you'll find guidance and insights you can tailor for your specific scenarios.
Your free to read time expires in minutes. After that you have to pause for an hour.
Test the closed alpha on paperc.com
Book Details
Authors
Categories
Publishers
Publication year : 2010
License: All rights reserved ©
Times read: 155
