Team Development with Visual Studio Team Foundation Server

More documents

Recommendations

Info

• If you have features that are causing stability issues, or teams causing stability issues among each other, create separate feature or team branches beneath a development container folder in source control. Do not branch unless it becomes necessary for your development team. Branching introduces additional source tree maintenance and merging tasks. Most development teams such as those building line of business applications, working on short release cycles do not need to branch. Development teams working on longer release cycles such as Independent Software Vendors (ISVs) building packaged applications are more likely to need branching as part of the development process. If you have one stream of development, or are performing incremental and continuous releases, you might not need to create branches unless you frequently experience breaking changes that are destabilizing your development efforts. Common Scenarios in Practice The following are the most common branching scenarios: • Scenario 1 – No Branches. Your team works only from the main source tree. In this case, you do not create branches and you do not need isolation. This scenario is generally for small or medium size teams that do not require isolation for teams or for features, and do not need the isolation for releases. • Scenario 2 – Branch for Release. Your team creates branches to support an ongoing release. This is the next most common case where you need to create a branch to stabilize for a release. In this case, your team creates a branch before release time to stabilize the release and then merges changes from the release branch back into the main source tree after the software is released. • Scenario 3 – Branch for Maintenance. Your team creates a branch to maintain an old build. In this case, you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. You may or may not merge changes from the maintenance branch back into the main tree. For example, you might work on a quick fix for a subset of customers that you do not want to include in the main build. • Scenario 4 – Branch for Feature. Your team creates branches based on features. In this case, you create a development branch, perform work in the development branch, and then merge back into your main source tree. You can create separate branches for work on specific features to be completed in parallel. • Scenario 5 – Branch for Team. You branch to isolate sub-teams so they can work without being subject to breaking changes, or can work in parallel towards unique milestones. You may encounter one or more of these scenarios. Use these scenarios as a reference point to see what guidance may or may not apply to you.
Example Folders and Their Purpose The following folders are examples of folders you might create in Microsoft® Visual Studio® Team Foundation Server (TFS) source control when structuring your source tree for branching and merging scenarios. • Development is branched from Main and used to isolate active development. Development branches may be temporary, in order to develop risky changes without impacting Main. • Main contains your main source tree. Changes from other branches are integrated here. • Releases contains branches you have already shipped but now need to maintain for customers. This provides isolation from the active development occurring in your development branch. It also contains a current release branch which is branched from Main and contains the version you are currently locking down prior to release. You work in this branch to prepare your software for release, while others continue to work in the Development branch working on new features. The following sections show the use of branching in each of the preceding scenarios with concrete examples. Scenario 1 – No Branches This scenario generally applies to smaller teams for whom isolated development is not a concern. By labeling builds, you are able to retrieve the source corresponding to a particular build. There is no need to introduce branching complexity because you can work directly from Main folder. The following is a view depicting the no-branch scenario: My Team Project Main Source Scenario 2 – Branch for Release In this scenario your team creates a branch to stabilize the release and then merges the release branch back into the main source tree after the software is released. The following is a view showing branching for releases: My Team Project Main Source Releases Release 1 Source Main integration branch Release branch
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: Chapter 5 - Defining Your Branching
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:
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:
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 233 and 234:
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:
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:
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?