Update on our TFS adoption

Hello again! Yes, I'm still alive and kicking. Sorry for not writing any updates lately. I've been working on some other things outside of TFS. In addition, I've got a number of colleagues who are taking over the primary role as TFS administrators. I still get involved at times, but it's good to see others taking an interest in supporting the product.

I do have to share with you some tough news about TFS. TFS is kind of taking a public relations beating in my new group. In fact, so much so, there has been a "TFS Improvement" team created to look at changes we can make to both, our use of the tool, and possible suggestions for the vendor on how to make TFS better.

I'm a bit confused on where the movement is coming from, as I'm not part of the "improvement team," however, in reviewing the meeting notes, it looks like Work Items used to support an Agile development effort are a primary target. Here is a sampling of some of the complaints.

- Need a hierarchical representation of work items that shows partial completion
- Enable users to find and track dependencies more easily
- Need to map work items to current priorities, in/out list
- Need to make it easier to set up alerts on work items for yourself and others
- People should be able to create a Team Query
- TFS should auto-complete stories when all tasks are marked as completed. Or, depending on workflow, it should auto-magically assign the story to the business partner for final validation
- TFS should do the same to backlog stories when the associated tech stories in the work stream are completed

Looking through this list, I think there are many things we could do to help solve these, somewhat vague, issues people are complaining about. For example, Alerting is now enhanced with the new Power Tools. And I see TSWA also has a way to setup Alerts. This may have come from the Teamprise people who still are having some trouble with Alerting. We've showed them the TSWA and I think that is helping. The Team Query thing is simply a permission deal that we can work out internally.

However there is one primary feature that I think would solve a number of problems we're having. And that is a hierarchy that can perform "Actions" when parents or children are updated. For example, you can see the two bottom "ideas" (from a former Version One user who recently joined our company) are regarding a parent Work Item State action to take place when Child Task(s) are completed/updated. This, very vocal, person would also like to see Field roll-ups. That is, if the Child Tasks had "Hours Worked On Task," those values should be rolled up into the Parent Work Item so you can see the rolled up values of "Hours Worked On" for the Child Tasks of the Parent (i.e. Product Backlog Item in our case).

We'll see where this goes. There is a lot of movement towards looking at Version One right now. And I see they have a TFS interface so I'm sure that will be talked about at the management ranks. Personally, I like what we have and wouldn't suggest a change. However, I often think decisions get made because a few squeaky wheels start to complain. I guess we'll see what comes of this all. And hopefully Rosario will provide a number of nice new features for Work Item tracking. Personally, I think it will.

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.

Manually Adding Files to Pending changes in Teamprise's Plug-in

There have been a few times recently when users have added files in Eclipse, but the files were not picked up by Teamprise's Eclipse Plug-in as a Pending Change.  If this happens, the new file will have a "?" on it.  It's one of those incidents that we can't seem to reproduce, but happens ever so often.  It also seems to happen to a small subset of users.

If you run into this problem, a work around is to manually add the files.  I'm doing this from memory so the steps might be slightly off.  However, I think it's close.

1. Show the Team Explorer Panel in Eclipse.  Window > View > Teamprise > Team Explorer.
2. Make sure your Team Project is selected and expand it.  There you will see Source Control.
3. Double click on Source Control.
4. In Source Control, path yourself down to the correct directory where the files were indented to be added.
5. Right Click on the directory you're wanting to add the file to and say "Add Files to Source Control" (or something like that).
6. Now select the files that were not added by the plug-in.
7. Back in Eclipse's Package Explorer (or what ever view you're using), Right Click > Team > Synchronize.
8. The Synchronize command should now make the "?" files show up as "+" files and thus added to your Pending Changes.

Hope this helps anyone who runs into a similar situation.

<UpdateBuildNumberDropLocation and NFS File Systems

Our current Team Build drop location is a Common Internet File System (CIFS) mount to some network attached storage (NAS).  To a novice like me, the drop location looks just like a Windows server drive that is shared.  However, on the back end this CIFS mount has all the bells and whistles that the data center offers (e.g. backups, redundancy, etc.).

The issue we have with the CIFS mount is that while our Windows servers can pick code on their for deployment, our Linux boxes can’t see the CIFS mount.  Since a lot of our development is done in Java and runs on Linux, we have an issue.

Enter the fine storage and system admin teams who have tested the use of Network File System (NFS), as a replacement for the CIFS mount, which is accessible by both Windows and Linux servers.  We’ve tested the NFS mount and sure enough, both our Windows servers and Linux servers can mount to the same drop location and pick up the build output used for deployment.  Perfect right?  Unfortunately there is a small issue.

According to this post, Team Build’s <UpdateBuildNumberDropLocation Task has code in it which needs to update permissions on the drop location.  From what I understand, the code will change the permissions so the App Tier service account has access to the drop location (it needs access to delete builds and such).  To see this, Right Click on a file located on the drop location and notice how the App Tier service account has full access to the folder and any sub files or directories.  The <UpdateBuildNumberDropLocation is doing this.

The issue that I’m running into is, when the drop location is a NFS system, there are no permissions at the file or directory level.  For Windows, the permissions are at the share level.  I’m assuming Linux permissions are dependent on wether the mount is a write or read mount.  So when the <UpdateBuildNumberDropLocation Task runs, it gets a message back saying permissions can’t be set and thus throws this friendly message back to the user: “TF209025: The build process is unable to set the permissions on the drop directory <actual drop location>(Detail Message: Attempted to perform an unauthorized operation.). Make sure that the build service account has proper permissions on the build drop directory and try again.”

What’s interesting is, the share is wide open thus the NFS mount is wide open.  And Team Build actually writes files to the location.  So functionally everything should work fine if we could get past the feature in the <UpdateBuildNumberDropLocation Task where it tries to adjust permissions.

I’m not sure what a good solution is for this.  However, I think the current implementation needs adjusting.  In my Connect submission to Microsoft, I’ve asked them to provide a Property (e.g. UpdatePermissions=”false”) where you can turn off the permission change when you want to use a NFS mount for your drop location.

Team Explorer "did not load because of previous errors"

My colleague installed TFS 2008 SP1 on our app tier.  He then uninstalled it because we were having some issues, which we're tracking down. However, after uninstalling, we were unable to open Team Explorer due to the following error.

The Microsoft.TeamFoundation.Client.ServicesHostPackage, Microsoft.VisualStudio.TeamFoundation.TeamExplorer, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a ({8E01EC3E-2928-4AA5-B720-E28C163818E6}) did not load because of previous errors. For assistance, contact the package vendor. To attempt to load this package again, type 'devenv /resetskippkgs' at the command prompt.

I'm not sure what /resetskippkgs does, but I ran it and Team Explorer is now back to being functional.  If you run into a similar problem, I’d be interested to see if this /resetskippkgs works for you.

"Find in Source Control"

It's fall which means all the interns from MIT, University of Wisconsin and University of Minnesota (I'm an alumni) head back to school.  It's also time for us full time employees to pick up the messes they left.

For me, their messes usually include having thousands of files checked out in TFS (or VSS back when we used that).  In the past, I just deleted their workspace from a command line.  That works pretty well and to be honest, should be the way we do this.

However, my colleague showed me a really cool feature called "Find in Source Control" where you can search on a person's ID to see all their pending changes.  Then you can undo them from there from a nice gui.  Works great when you've got some lead engineer breathing down your neck because they can't update source code because some intern had an exclusive lock on the file.  Nice feature Microsoft.  Keep up the good work.

HintPath and Team Build

Very long week so I've got to keep this short. For some reason when a developer added a Reference to his csproj file it didn't add a <HintPath. The build worked locally and it worked on the build machine when we ran the build manually through Visual Studio. However, when trying to run the build via Team Build, we got the error "Could not resolve this reference. Could not locate the assembly." We could see that when Csc.exe was called, our Reference was not referenced.

The fix was to add a <HintPath to the csproj file. After doing that, Team Build ran fine and we could see it added to the Csc.exe Reference command line. I didn't get time to figure out why, but thought I'd document it here for when it happens again.

Source Control Cache Hits on our server.

I enjoy reading Grant's blog. In this Cache Hits post, he shows how to get your Cache Hit Ratio.

We're currently hitting our local Source Control cache 96.06% of the time. What are your numbers? I'm interesting in comparing.