Check in comment to dynamically enable or disable CI builds.

I just got done adding in some custom MSBuild changes to automatically check in a Jar file to another build type (i.e. MainBuild in this example) after the Jar file build type (i.e. CommonBuild in this example) is finished.

Buck showed me a really cool way to "enable" or "disable" continuous integration (CI), which is turned on for us, in the MainBuild. That is, when CommonBuild checks in the Jar file to MainBuild, we can control whether we want to fire off a MainBuild.

First we set a Property called ExecuteMainBuildCIBuild to true|false. If true, we set the check in comment equal to /comment:"AUTO CHECKIN FROM TFS FOR COMMON JAR BUILT IN $(BuildNumber)". If false, we set the check in comment to /comment:"$(NoCICheckinComment)". $(NoCICheckinComment) resolves to the string ***NO_CI*** which tells Team Build to not fire a CI build.

End users can also use ***NO_CI*** if they want to control the CI build behavior. For example, if you're wishing to check in a change and not execute a CI build, you can simply put ***NO_CI*** in the Comments section. I'm not sure if management will enjoy us sharing this back door, however I've found it to be a valuable tool for solving some unique problems.

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.