Team Development with Visual Studio Team Foundation Server

More documents

Recommendations

Info

Create One Team Project per Application if You Want to Migrate Work Items and Other Assets Between Application Versions If you want to carry forward not only source code but also work items and other TFS assets between releases, consider using one team project per application. When you use a single team project for multiple versions of the application, all of the TFS assets are carried forward automatically for the next release. When you are ready to release a new version of your application, you can create a branch within the project to represent the release and isolate that code. Keep the following key points in mind when using one project per application: • Parallel releases are forced to share work items schema, check in policies, and process guidance. • Reporting is more difficult; because reports default to the entire project, you must add filtering by release. • If you have hundreds of applications, each in its own project, you will run up against TFS performance and scale limits. • You will accumulate ‘baggage’ over multiple releases. The easiest way to address this issue is to create a new project and branch the code you want to carry forward into that project. Additional Resources • For more information about 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 with New Work Items and Other Assets 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 schema, 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. Keep the following key points in mind when using one project per release: • 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. Because 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 as follows: 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 MSF Agile process template or 250 projects using the MSF CMMI process template. If you create your own process template or customize an existing process template, keep in mind that the work item schema has the largest impact on server scalability. A complex schema will result in a server capable of supporting fewer projects. • You will have to carry over all the areas from the original project; and perhaps also change the permissions in source control. Additional Resources • For more information about 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 Grant Only Required Permissions on Project Assets When creating team projects, review the default security groups created by the process and, if necessary, create security groups with appropriate permissions. You then assign the project members to appropriate groups to ensure that each member gets only the permissions he or she requires on project assets. Additional Resources • For more information about granting permissions, see “How To – Manage Projects in Visual Studio Team Foundation Server” in this guide. Structure Your Source Tree to Support Branching When creating your source tree structure, make sure that it supports branching. Keep separate folders for source and for other project assets, so that if isolation development is required in the future, you can simply branch the source folder. Also make sure that you maintain separate folders for each component within the source folder, so that partial branching can be performed if required. Segregate other entities such as shared code, unit tests, library dependencies, and so on by using folders so that they can be excluded or included during branching as required. The following is an example of a source tree structure that supports branching: • Main – Container for all assets you need to ship the product o Source – Container for everything you need in order to build • Code – Container for source code • Shared Code – Container for source code that is shared from other projects • Unit Tests – Container for unit tests • Lib – Container for binary dependencies o Docs – Container for documentation that will ship with the product o Installer – Container for installer source code and binaries o Builds – Container for Team Build scripts o Tests – Container for test team test cases
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 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: You can create security groups for
Page 201 and 202: a. Set the Type to an appropriate v
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 and 242: The Tf move, delete, and rename com
Page 243 and 244: • If the shared dependency is cle
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 253 and 254:
Additional Resources • For more i
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?