Team Companion

I'm actually on vacation today, but wanted to share this. So the business and management folks don't like to use an IDE when using TFS. Turns out even going to TSWA is a struggle for some.

My colleague was doing some digging and came across Team Companion, which is a TFS plug-in to Outlook. We've been piloting it for a few weeks. The users most likely to never use TFS, have been enthralled with having Work Items within their Outlook. From what I hear, they can't say enough great things about it. We're actually getting people interested in normalizing the paper work behind software development.

If you're having a hard time getting management and business folks working in TFS, give Team Companion a try. With TFS being embedded in the only software package they use (i.e. Outlook), TFS becomes even more critical in our business process.

"Mac, how do I compile Java with Team Build?"

In the past week, I've fielded a number of questions from people within my company regarding how to get started compiling Ant based Java projects within TFS. Here is what I tell them. And it would be what I'd tell you if you asked.

My Colleagues: "Mac, can you provide us some information on how to get started using Team Build to compile our Java projects?"

Mac: "There are a number of different ways to solve the problem, but I'd suggest looking at Teamprise's Team Build Extensions. This is an open source project, supported by Teamprise, to run Ant scripts via Team Build (which is nothing more than MSBuild behind the covers). They have a very good tutorial (as part of the distribution if I remember) and support forum.

I'd start by trying to get one of your simpler Java projects to build. Then once you build that, you can get a better understanding of how the tooling can best solve your problem. What we do is have one parent Ant script that calls all the other tier Ant scripts. So basically Team Build is just the high-level driver and we let Team Build Extensions and Ant take care of the rest. This seems to work pretty well for both [MY CURRENT BUSINESS UNIT] and [MY OLD BUSINESS UNIT]. Also, I think if you have JUnit tests that you run as part of the build, and follow some simple rules, Teamprise Build Extensions will publish the results back to TFS. Pretty cool!
"

So if you're looking for help getting started, consider this my response to you. Let me know how it goes.

Be careful with the TFS 2008 Retention Policy

Be careful with the TFS 2008 Retention Policy.  With TFS 2008, when you set the Retention Policy to remove old builds, it also removes the Label on the source code.  Bad!  In SP1 Microsoft allows for a configuration override to change the behavior of this (i.e. <add key="PreserveLabelsOnBuildDeletion" value="True"/>).  However, since we’re only on TFS 2008 right now, we just got burnt by this.

What happen was, we needed to branch off a build that was in our customer’s hands.  I informed my colleague to simply branch off that build and let the developers make the appropriate fix.  However, when he looked for the Label he couldn’t find it.  I told him that was simply not true.  Then I read the post Retention Policy and missing labels and started to get very, very nervous.

We ended up with a work around that helped us solve our problem.  We have a Build report that shows all builds and when they ran.  We were able to find the build number and then using the time that it started execution, find the Changeset which was before the build initiation.  That allowed us to track down where we needed to branch the code from.