Bottom line up front: Create a 'root' branch directly under the source control branch associated with a new Team Project.I see this all the time... Someone creates a new source control branch in TFS and starts creating solutions underneath the default project branch. In other words, they end up with this: $/ProjectName /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 Now, the difficult comes when the shop needs to create a second version of the application. Code branches directly under the root (i.e., $/ProjectName) can only be created when a new Team Project is created. If, in the above example, SolutionName1 and SolutionName2 both belong to the current version of the application, then creating a new version of the application will require either the creation of a new team project (with a branch from the $/ProjectName), or a wildly unweildly structure where each solution is branched, resulting in something like: $/ProjectName /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 /SolutionName1_v2 /ProjectName1 /ProjectName2 /SolutionName2_v2 /ProjectName3 /ProjectName4 A MUCH cleaner approach is so simple, yet requires a bit of forethought. Immediately after creating the Team Project, simply go in an create a new directory called 'root' (or 'edge' or whatever you'd like). You can then create a full branch of the V1 off the application by simply branching 'root'. This allows This resulting in the following structure, even after creating a v2 of the project. $/ProjectName /root <-- Create this branch! /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 /ProjectName_v2 <-- This is the branch of 'root' /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 Now, whether you should have your projects under your solution directories... that's for another post...
How many build scripts do you need? There seems to be some massive confusion around TFS Build Scripts, namely, how many a single project needs. If your answer is one, you too have a misunderstanding!  In my experience, one build script is not nearly enough, in fact, I encourage several. Here's the why and how. Why: Visual Studio Team System (VSTS) and Team Foundation Server (TFS) is absolutely brilliant at tracking information related to a series of builds. That information is archived, analyzed and reported in a very useful fashion. BUT, it it reported by the NAME of the build. Thus, if you only have one build type, you can only have one set of reports! And that's no good! You need more. The primary reason for having more than one build type is to get good, easily understandable, accurate metrics.
- First, you need a build script for your continuous integration builds. This script runs every time someone checks in code (with certain restrictions). You likely won't want an aggregate report on these builds, except for rare cases -- there are just too many of them. This build is optional. I'm a fan of CI, but if it's a bridge too far, don't worry. The critical build is the nightly build...
- A TFS Build for your daily / nightly builds. This build runs every night at a set time. This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc. This is one of the most valuable builds, since its reporting is clearly segmented by time -- one build per day. This allows a team to see what is being accomplished on a day to day basis.
- A TFS Build for weekly builds. This runs every weekend. Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week. This allows you to see aggregate changes over a chunkier time sequence, namely weeks.
- An end-of-iteration build. I've found you don't need to go any longer than weeks this for most projects, as far as reporting is concerned. However, you may choose to create a build that runs at the end of every iteration. This gives you metrics on what was accomplished during the entire iteration.
- An on-demand build. This one is used for folks who just need to trigger a build whenever. Unless it's necessary or useful, you may choose to have this build not report anything back to the data warehouse.
How: It's easy! The reason for all these builds was stricktly for the reporting. That means that each of these builds is likely going to be nearly identical! So, all you need to do is create the first build (the hard part), and copy it several times, giving it a different name each time. That's all there is to it! So, go forth and replicate those builds!
It looks like I'll be speaking at BASTA! in a few weeks.
I'll be delivering two regular sessions:
And one full-day workshop:
Thanks to Brian Harry and team for releasing the latest version of the provider.
The enhancements in this latest release include:
- Enable handling branched solutions in Visual Studio 2003
- Fixed issues to enable provider to support TOAD for SQL Server 2.0
- Enhanced the "Choose Folder in Team Foundation Server" dialog
- Fixed bug which prevented Properties Dialog from displaying local path
- Work Items Query list in the Checkin Dialog is loaded and saved on the disk
- "Get" operation performance improvements
- Miscellaneous bug fixes
Download the new provider here, and remember it is for use by anyone who owns a Team Foundation Server Client Access License (CAL). 
If you're upgrading your TFS with SP1 (which you should) and you're using the Workgroup edition, there's a gotcha if you already are using all 5 allowed people. Basically, you'll have to remove on of the users, do the upgrade, then add the user back in. Dave Glover has a good post you'll want to read before you do the upgrade. You can find his post here. Happy upgrading!
Some of you have been beta testing it and, thanks in part to your hard work, it's ready for prime-time ... before the holidays!
Click here to learn more, and download SP1 for Visual Studio 2005, Team Foundation Server, and/or the Express editions. In addition, you can download Visual Studio 2005 SP1 Update for Windows Vista Beta.
Spread the word! 
We got spammed on our comments, and so we've disabled comments on the blog. Soon, we may put up an authorization scheme so that we aren't hammered by bogus comments. But, for now, comments are disabled. In lieu of comments, please send emails to myself. My address, which you'll have to normalize from the awkward way I'm writing it here, is steve_nospam at accentient dot com. (Simply delete the _nospam from my name, and send the emails to steve@..., thanks)
We're about to redo the Team System Widgets page, and are looking for any suggestions on improvements. Some things we'd like to add are comments on each widget, and an icon designating which ones are still 'works in progress'. Any other ideas? Tags? Let us know!
|