Team Development with Visual Studio Team Foundation Server

More documents

Recommendations

Info

• Customers. Each consumer has different needs in terms of build quality and frequency. In general, build consumers can be divided into two groups; those who need predictable, scheduled builds and those who need rapid, event-driven builds. Scheduled builds are most commonly daily builds but can occur more or less frequently. Event-driven builds are usually initiated by a check-in and are designed to give the development team rapid feedback. If your development team has problems with breaking builds, consider using a gated check-in model, where check-ins are tested before they are allowed into the source tree and are rejected if the tests fail. Review Solution Scenarios Choose solution scenarios based on how closely their purpose and build consumers match your team’s situation. When in doubt, use the simplest build scenario possible, such as a scheduled build, and add more complex scenarios only if necessary. Build Scenarios The following are the most common Team Build scenarios: • Team with single daily builds. Most teams rely on a scheduled build in order to provide consistent binaries to their test team and other users. • Team with daily builds and continuous integration builds. Some teams choose to use continuous integration builds in order to provide rapid feedback to their developers upon every check-in. Although a pure continuous integration build works well for small teams, larger teams are likely to overload their build server due to highfrequency check-ins and longer build times. When this happens, a rolling build can be used to build less frequently without giving up too much time between check-in and build feedback. • Team with multiple build labs, each performing daily build and continuous integration builds. Very large teams are likely to require more complex solutions to improve build quality and timeliness. You can use gated check-ins to reduce build breaks by rejecting bad check-ins before they make it into source control. Teams that branch can use multiple build servers, one per branch, to keep the builds focused on each branch’s purpose. For example, integration branches create integration builds, while development branches create development builds. Scheduled Builds A scheduled build is a time-based build based on a fixed time frequency. The purpose of a scheduled build is to produce consistently reliable builds that can be used to gain feedback on the quality of the build. Scheduled builds are usually daily builds, but they could occur more or less frequently depending upon your needs. The consumers of a scheduled build are most often: • Test team. • Internal build adopters.
• External adopters. Use the following steps to create a scheduled build: 1. Create a batch file with a command line build. 2. Use Windows Scheduled Tasks to execute the batch file on a schedule. For more information, see “Chapter 9 - Setting Up Scheduled Builds with Team Build.” Continuous Integration Build A continuous integration build is triggered any time a check-in occurs. The purpose of a continuous integration build is to gain rapid feedback about build quality as soon after a check-in as possible. Development teams are typically the consumers of a continuous integration builds. Depending on the size of your team, the length of your build, and the number of checkins, choose one of the following strategies: 1. Continuous integration build immediately following each check-in. 2. Rolling build after a specified number of check-ins, or a specified time period (whichever comes first). For more information, see “Chapter 8 - Setting Up Continuous Integration with Team Build.” Gated Check-ins Gated check-ins is a process that requires each check-in to meet some quality standard before it can be added to the source tree. The purpose of a gated check-in is to reduce the number of build breaks and improve the quality of the build by requiring that each checkin be run through a set of tests before it can be admitted. Understand Common Stumbling Blocks There are several common scenarios that Team Build does not fully support by default. Review the following scenarios and consider whether your team is likely to face any of them: • Building a project with external dependencies. If you use branching to bring external dependencies into your team project, you can use project references and the build will work on the build server without any additional steps. If you use client-side workspace mapping to reference external dependencies, you need to maintain the mapping on the build server in order for the build to complete successfully. For more information, see “Chapter 6 – Managing Source Control Dependencies in Visual Studio Team System.” • Building a setup project. Team Build does not support setup projects by default. Use a custom post-build step to compile the setup project and copy the binaries to the build drop location. For more information, see “Walkthrough: Configuring Team
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: • The TFSBuild.rsp file contains
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

Create successful ePaper yourself

Delete template?

Save as template?