SDLC Mangement for TFS Build Scripts

Question

I\'m in the process of developing several custom build scripts for TFS and I\'d like to know if there are any best practices for developing, testing and deploying TFS build

Answer 1

Check out my answer here: Modular TeamBuilds

You can keep core functionality factored out into a common MSBuild file that's included across all builds. Furthermore, all of these files are part of your broader branch structure, so they participate directly in your preexisting SDLC without any extra work. Thus:

1. If you're making risky changes to your build scripts, make them in a "dev" or "private" branch, just as you would with any other risky changes.
2. If you want a build definition that's just for quick validation, set properties like SkipLabel, SkipWorkItemCreation, etc to False in the *.targets file imported by that build definition.

To expand on #2 a bit, let's take your example of "production" vs "test" builds. You only want to turn on features like labeling in production builds. So you would remove the SkipLabel property from TFSBuild.proj (and also TFSBuild.Common.targets if it's defined there) and instead set it in TFSBuild.Production.targets and TFSBuild.Test.targets -- using two different values, of course.

As mentioned in the earlier question, TFSBuild.proj is the master msbuild file that controls how the rest of the build will operate. Here's what mine looks like:

By doing something similar, you can ensure that all builds from the Dev branch are "quick" builds (which for you means no labeling, etc), all builds from the Release branch are "full" builds, and builds from the Main branch can be either depending on which build definition the user launches from Visual Studio / TSWA. Myself, I have "quick" builds set up with Continuous Integration and "full" builds running nightly.