Team Development with Visual Studio Team Foundation Server

More documents

Recommendations

Info

Additional Resources • For more information on using team projects, see “When to use Team Projects” at http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx Create One Team Project per Version if You Want to Start Fresh With Each Application Version If you want each release to start fresh without carrying forward work items and other TFS assets, consider using one project per release. When you use a new project for each release, you can modify work item schemas, workflow, check-in policies, and other assets without impacting the old release. This can be especially useful if the old release will be maintained by a separate team such as a sustained engineering team who may have a different process and workflow than your main development team. When using one project per release, keep the following in mind: • Although it is very easy to move the source code from one project to another, it is difficult to move work items and other TFS assets from one project to another. Work items can only be copied one at a time to another project; if you want to copy sets of work items, you will need to write your own utility. • If you have hundreds of applications and releases, each in its own project, you will run up against TFS performance and scale limits. • Choose a structure you can live with in the long term because restructuring existing team projects is difficult. • Source can be easily shared among team projects: o Branch source from one project to another. o Map source from another project into your workspace. • Team Foundation Server can scale to ~500 projects by using the Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) process template or to 250 projects by using the MSF CMMI process template. If you create your own process, or customize an existing process, keep in mind that the work item schema has the greatest impact on server scalability. A complex schema will result in a server capable of supporting fewer projects. Additional Resources • For more information on using team projects, see “When to use Team Projects” at http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx Use Branching to Share Code and Binaries that Require Integration Testing Managing shared code or binaries involves two steps: 1. Determine a location in which to store the dependency. 2. Branch the dependency into your project. 1. Determine a location in which to store the dependency. Options for storing:
• If the shared dependency is clearly owned by a particular team, store it in that team’s team project. • If the shared dependency has no clear ownership, create a team project specifically for the shared code. 2. Branch the dependency into your project. Once you have stored the dependency, branch the shared source or binaries into your project. Every time you perform a merge from shared to consuming project, you will pick up the latest source. This allows you to pick up changes on a regular schedule and to perform integration testing before impacting your main source tree. Additional Resources • For an introduction to branching and merging, see “Branching and Merging Primer” at http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx • For more information about branching, see “How to: Branch Files and Folders” at http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx • For more information about merging, see “How to: Merge Files and Folders” at http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx • For additional descriptions of how to branch and merge in Visual Studio 2005, see “Branching and Merging Team Foundation Source Control” at http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx Avoid Workspace Mapping to Support Cross-Project Dependencies In general, you should avoid dependencies that cross team projects and try to have all the related/dependent solutions/projects under the same team project. This reduces the need for build script customization. If you have a dependency, use project references to define it, or branch the dependency from a shared project into your project. You should avoid file references because they are more difficult to manage. The exception is when the dependent project is developed in parallel and you need real-time changes. In this case, you can consider using workspace mapping. However, you can still use branching in this case to create a buffer of isolation, if the dependent code is causing too many breaking changes. Additional Resources • For more information about creating a workspace, see “How to: Create a Workspace” at http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx • For more information about editing a workspace, see “How to: Edit a Workspace” at http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx Create Workspace Mappings at the Team Project Root Level For new team projects, map your team project root ($/MyTeamProject) to a folder with the same name on your local drive; for example, C:\TeamProjects. Because mappings are recursive, your entire local folder structure is created automatically and will be exactly the same as the structure in source control.
Page 1 and 2:
Team Development with Visual Studio
Page 3 and 4:
Information in this document, inclu
Page 5 and 6:
All the best! Jeff Beehler Chief of
Page 7 and 8:
on the increasingly complex develop
Page 9 and 10:
• Guidelines, provide concise rec
Page 11 and 12:
development environment. The follow
Page 13 and 14:
“How To” Articles • How To: A
Page 15 and 16:
Version Control Team Foundation Ser
Page 17 and 18:
Chapter 1 - Introducing the Team En
Page 19 and 20:
Figure 1.2 Logical Workflow Showing
Page 21 and 22:
If your development team accesses T
Page 23 and 24:
Figure 2.1 TFS Components and Tiers
Page 25 and 26:
• Work item tracking. This stores
Page 27 and 28:
Summary Team Foundation Server arch
Page 29 and 30:
Chapter 3 - Structuring Projects an
Page 31 and 32:
configurations (debug/release) sync
Page 33 and 34:
• /Source • /WinFormsProject
Page 35 and 36:
Use a partitioned solution for logi
Page 37 and 38:
Server-Side Structure Most team pro
Page 39 and 40:
• Use SharePoint for internal tea
Page 41 and 42:
For more information about project
Page 43 and 44:
Note: At run time, the Visual Studi
Page 45 and 46:
Chapter 5 - Defining Your Branching
Page 47 and 48:
Example Folders and Their Purpose T
Page 49 and 50:
Main Feature A Source Feature B Sou
Page 51 and 52:
1. A feature branch is created to i
Page 53 and 54:
• Release 2- Active maintenance b
Page 55 and 56:
Chapter 6 - Managing Source Control
Page 57 and 58:
Branching adds additional merge ove
Page 59 and 60:
Figure 6.2 Using Branches Your work
Page 61 and 62:
Figure 6.4 Using Workspace Mapping
Page 63 and 64:
The client side workspace folder st
Page 65 and 66:
• Use project references whenever
Page 67 and 68:
http://localhost/someservice/Serv
Page 69 and 70:
• Do not add your User.config fil
Page 71 and 72:
System.Configuration.ConfigurationM
Page 73 and 74:
PART III Builds In This Part: Team
Page 75 and 76:
Architecture This section introduce
Page 77 and 78:
• The TFSBuild.rsp file contains
Page 79 and 80:
• External adopters. Use the foll
Page 81 and 82:
The TFSBuild.proj file contains muc
Page 83 and 84:
Build on Each Check-In Building imm
Page 85 and 86:
Integration” at http://msdn.micro
Page 87 and 88:
Nightly Builds This is the most com
Page 89 and 90:
PART IV Large Project Consideration
Page 91 and 92:
Figure 10.1 Large Project Scenario
Page 93 and 94:
• Forward integration, such as me
Page 95 and 96:
For large teams, the branching stru
Page 97 and 98:
Chapter 11 - Project Management Exp
Page 99 and 100:
• Quality assurance. Predicting t
Page 101 and 102:
Team Project per Application This i
Page 103 and 104:
specific set of permissions to a gr
Page 105 and 106:
provide integrated data from across
Page 107 and 108:
How you use work items depends on t
Page 109 and 110:
Figure 12.2 Transition States for M
Page 111 and 112:
PART VI Process Templates In This P
Page 113 and 114:
• Read the “Customizing Process
Page 115 and 116:
• Version Control XML - This proc
Page 117 and 118:
customize work item types to fit yo
Page 119 and 120:
Chapter 14 - MSF for Agile Software
Page 121 and 122:
• Work items • Groups and permi
Page 123 and 124:
• Regressions. This report shows
Page 125 and 126:
5. Captures the test tasks in TFS a
Page 127 and 128:
Summary The MSF Agile process templ
Page 129 and 130:
Chapter 15 - Reporting Explained Ob
Page 131 and 132:
• Builds. What is the quality of
Page 133 and 134:
Creating a Report Server project in
Page 135 and 136:
Summary The MSF Agile and MSF CMMI
Page 137 and 138:
Chapter 16 - Team Foundation Server
Page 139 and 140:
• Dual-server deployment Single-S
Page 141 and 142:
Figure 16.3 Typical Dual-Server Ins
Page 143 and 144:
Figure 16.5 Moderate Team Foundatio
Page 145 and 146:
One server; 20 to 100 users Two ser
Page 147 and 148:
Having a mirrored server enables yo
Page 149 and 150:
want to support. After you have cho
Page 151 and 152:
Chapter 17 - Providing Internet Acc
Page 153 and 154:
• This approach supports the use
Page 155 and 156:
• Your remote users cannot add Mi
Page 157 and 158:
Internet Internal TFS Server Workst
Page 159 and 160:
Internet Internal Workstation TFS S
Page 161 and 162:
PART IX Visual Studio 2008 Team Fou
Page 163 and 164:
Build • Continuous Integration bu
Page 165 and 166:
Studio 2005 TFS and Visual Studio 2
Page 167 and 168:
Guidelines: Team Build Index Strate
Page 169 and 170:
Strategy • Use a scheduled build
Page 171 and 172:
Additional Resources • For more i
Page 173 and 174:
This is important because it provid
Page 175 and 176:
• To see sample code that will en
Page 177 and 178:
Page 179 and 180:
Deployment • On larger teams, ins
Page 181 and 182:
3. Check in WorkspaceMapping.xml. T
Page 183 and 184:
• For more information about edit
Page 185 and 186:
Although the Team Build feature in
Page 187 and 188:
3. Copy the RunTestWithConfiguratio
Page 189 and 190:
Guidelines: Project Management Inde
Page 191 and 192: 1. In Team Explorer, click your tea
Page 193 and 194: Use Check-in Policies to Ensure Tha
Page 195 and 196: You can easily edit the MSF Agile p
Page 197 and 198: You can create security groups for
Page 199 and 200: • Team Foundation Server can scal
Page 201 and 202: a. Set the Type to an appropriate v
Page 203 and 204: Additional Resources • For more i
Page 205 and 206: Administration • Ensure that user
Page 207 and 208: Make Sure That the Server Name Is C
Page 209 and 210: Team Foundation Reporting Resources
Page 211 and 212: • Detect when a policy has been o
Page 213 and 214: Accessing Version Control • Consi
Page 215 and 216: 3. Add or delete files 4. Run the T
Page 217 and 218: Deny Check-in Permissions to Develo
Page 219 and 220: • For more information about merg
Page 221 and 222: • For more information about bran
Page 223 and 224: Merge Frequently Eliminate the late
Page 225 and 226: • For more information about merg
Page 227 and 228: Check-in and Check-in Policies •
Page 229 and 230: 2. Click the Check-in Policy tab an
Page 231 and 232: lines of code. Conflicts on the sam
Page 235 and 236: Use Dynamic URLs When Referencing W
Page 237 and 238: saving these statistics. The ProxyS
Page 239 and 240: from, you can use the TFS Migration
Page 241: The Tf move, delete, and rename com
Page 245 and 246: Any branches that you create off of
Page 247 and 248: Practices at a Glance: Team Build I
Page 249 and 250: Administration • How to secure yo
Page 251 and 252: Check-in Policies • How to use ch
Page 255 and 256: Additional Resources • For ano
Page 257 and 258: $(SolutionRoot)\YourApp $(Solutio
Page 259 and 260: can install multiple build servers
Page 261 and 262: c. Add an AfterCompile target to cr
Page 263 and 264: • For more information about usin
Page 265 and 266: solution builds. The build folder i
Page 267 and 268: $(SolutionRoot)\YourApp $(
Page 269 and 270: To verify that a build succeeded 1.
Page 271 and 272: How to Use a Single-Solution Strate
Page 273 and 274: If you are using the Microsoft Solu
Page 275 and 276: 1. Create a TFSBuild command line a
Page 277 and 278: 3. Use the Test Manager to group te
Page 279 and 280: Practices at a Glance: Project Mana
Page 281 and 282: How to Set Up Check-in Policies to
Page 283 and 284: To publish a project plan to TFS 1.
Page 285 and 286: 8. In the folder where the template
Page 287 and 288: Additional Resources • To downloa
Page 289 and 290: How to Create an Area Create areas
Page 291 and 292: 5. From the Web Part List, select R
Page 293 and 294:
Practices at a Glance: Reporting In
Page 295 and 296:
Page 297 and 298:
5. Modify the report as follows: a.
Page 299 and 300:
8. Click the OLAP Cubes tab. 9. Sel
Page 301 and 302:
Additional Resources • You can do
Page 303 and 304:
How to Review Scheduled Work versus
Page 305 and 306:
How to Generate Workspace Metrics S
Page 307 and 308:
Practices at a Glance: Source Contr
Page 309 and 310:
Accessing Version Control • How t
Page 311 and 312:
How to Automate Common Version-Cont
Page 313 and 314:
2. Add the required project to Team
Page 315 and 316:
• For more information about find
Page 317 and 318:
• How to perform a baseless merge
Page 319 and 320:
never need a branch. Development te
Page 321 and 322:
Additional Resources • For an int
Page 323 and 324:
• Build frequency on branch - Con
Page 325 and 326:
You should use the External branch
Page 327 and 328:
How to Perform a Baseless Merge To
Page 329 and 330:
Additional Resources • To downloa
Page 331 and 332:
• For more information about retr
Page 333 and 334:
How to Undo a Check-in To undo the
Page 335 and 336:
change or the destination change, i
Page 337 and 338:
• To learn how to customize a che
Page 339 and 340:
• Select the Check In lock type t
Page 341 and 342:
1. In Source Control Explorer, righ
Page 343 and 344:
1. Add a configSource="user.config"
Page 345 and 346:
4. Ensure that the User.config file
Page 347 and 348:
To configure and optimizing proxy p
Page 349 and 350:
Notice the addition of the D
Page 351 and 352:
• You will accumulate ‘baggage
Page 353 and 354:
To view an existing workspace mappi
Page 355 and 356:
Page 357 and 358:
Source Control Resources • For mo
Page 359 and 360:
• What is a check-in policy? •
Page 361 and 362:
Accessing Version Control • What
Page 363 and 364:
made in a specified changeset. Not
Page 365 and 366:
Administration • How do I grant p
Page 367 and 368:
Page 369 and 370:
• For additional descriptions of
Page 371 and 372:
final release build has been create
Page 373 and 374:
Additional Resources • For an int
Page 375 and 376:
• For more information about merg
Page 377 and 378:
Additional Resources • To learn h
Page 379 and 380:
• Development - Container for iso
Page 381 and 382:
When and how can I override a check
Page 383 and 384:
• A baseless merge is being condu
Page 385 and 386:
1. The server determines which file
Page 387 and 388:
2. Edit files. You can now freely e
Page 389 and 390:
• Make sure that caching is enabl
Page 391 and 392:
Page 393 and 394:
• Choose a structure that will su
Page 395 and 396:
• Use a unique local folder path
Page 397 and 398:
• If the shared binaries have no
Page 399 and 400:
Page 401 and 402:
How To: Add a New Developer to Your
Page 403 and 404:
5. Click New Role Assignment. 6. En
Page 405 and 406:
• Your Team Foundation user ID mu
Page 407 and 408:
How To: Create a Custom Report for
Page 409 and 410:
1. In Solution Explorer, right clic
Page 411 and 412:
How To: Create a “Risk over Time
Page 413 and 414:
6. Select the TFSWarehouse database
Page 415 and 416:
Additional Resources • For more t
Page 417 and 418:
example policy ensures that develop
Page 419 and 420:
Step 2 - Register the Custom Policy
Page 421 and 422:
How To: Create Your Source Tree in
Page 423 and 424:
6. Click the ellipsis button beneat
Page 425 and 426:
To add a new Web site to your solut
Page 427 and 428:
How To - Customize a Process Templa
Page 429 and 430:
1. Install DSL Tools for Visual Stu
Page 431 and 432:
The new work item type will be crea
Page 433 and 434:
a. Under Group - Status, right-clic
Page 435 and 436:
Step 6 - Modify the Default Work It
Page 437 and 438:
1. In the Process Template Explorer
Page 439 and 440:
The customization process is now co
Page 441 and 442:
How To: Customize a Report in Visua
Page 443 and 444:
4. Click Properties. 5. Select Edit
Page 445 and 446:
How To: Manage Projects in Visual S
Page 447 and 448:
TFS provides following two process
Page 449 and 450:
5. Click Add. 6. In the Select User
Page 451 and 452:
Step 9 - Plan Your Iteration In thi
Page 453 and 454:
• Velocity. How quickly is the te
Page 455 and 456:
How To: Migrate Source Code to Team
Page 457 and 458:
\DATA \Temp \USERS 5. Copy the foll
Page 459 and 460:
…. Add the element directly af
Page 461 and 462:
How To: Perform a Baseless Merge in
Page 463 and 464:
Example Tf merge /baseless c:\data\
Page 465 and 466:
Continuous Integration build provid
Page 467 and 468:
1. Open a command prompt and naviga
Page 469 and 470:
How To: Set Up a Scheduled Build in
Page 471 and 472:
1. As the TFSBuild command utility
Page 473 and 474:
Page 475 and 476:
Summary of Steps • Step 1 - Creat
Page 477 and 478:
3. Type the name ClassLibrary, set
Page 479 and 480:
Source Control Folder Local Folder
Page 481 and 482:
Summary of Steps • Step 1 - Creat
Page 483 and 484:
Step 7 - Check Your Local Folder St
Page 485 and 486:
code from this location, you map bo
Page 487 and 488:
• Development. This is an optiona
Page 489 and 490:
Step 2 - Create Your Main Folder In
Page 491 and 492:
Step 5 - Create a Branched Developm
Page 493 and 494:
• The above folder structure is i
Page 495 and 496:
• Business Process Modeling from
show all

Team Development with Visual Studio Team Foundation Server

Create successful ePaper yourself

Delete template?

Save as template?