| Comments

It seems like a daily question I’ve been answering lately when working on internal email discussion groups and folks report an issue, my initial response is: what build combination are you working on? 

As a part of my job, I like to ensure the fastest resolution (or awareness depending on how you look at it) to issues that affect our product.  This involves staying on top of ‘latest bits’ as we call them.  Every morning I come in and install the latest Windows build as well as the latest Visual Studio build.  We have an automated Hyper-V environment that makes it easy to get the initial Windows builds up and going and then I selectively apply VS on top of that.

So if it sounds so simple, why do I ask that question to people that ask?  Allow me to show you a few diagrams.

The above is a *snapshot* of just a few of the branches that affect the tools area that I work on.  This is not representative of the entire branching structure, which is huge. 

NOTE: This diagram is automatically created for you from Team Foundation Server…you select the branches of interest and it visualizes for you.  There is also an awesome feature to track changes which I’ll note below.

The red box items make up the different teams working to bring together the holistic view of some of the core developer experiences.  Since they aren’t *just* working on my stuff, nobody can live in a single branch together in harmony.  You can see that the spread of varying levels of branches required to get something working is pretty broad.  And merge (we call them RI/FI) processes are on different schedules and managed to reduce conflicts as much as possible.  The above is just one piece of the puzzle – the developer tools.  Windows has a similar ancestry view we have to deal with:

The red boxes here are basically other Windows teams that we need stuff from to get our product working as well.  These RI/FI process go through many, many checks and if any regressions, they don’t allow merging, which can cause issues if you are waiting on a fix to come to your branch!

So the answer to whether something should work at any given time during development milestones has different answers depending on where you got your bits from.  I’ve personally resorted to hosting a page on our team wiki with the title Tim’s Guide to Finding a Build Combination™.  I’ve also added a few helpful scripts to get any missing pieces aligned for builds.  So now I’ve got my daily build routine down to a science.

Occasionally there are times where a fix is completed and I look back at my tracking bugs.  Sometimes you’ll get a team that just fixes things and you aren’t given a chance to test out private bits, or whatever…so you have to go hunt down where the fix is at and when it will come to you.  In most source control systems there is a good mechanism for viewing/following a changeset.  In TFS I think they’ve nailed the feature to do this in two ways of visualization.  You can “track changeset” and choose a timeline view or branch view…it is awesome for pinpointing just where a fix is working the way through the source depots.  Here is a view of a bug using the branching view.  Green shows which branches has the fix (changeset):

Here is another bug using the timeline view showing me when the fix made it to certain branches:

For me, this has been invaluable to really identify when/where things are and determine a predictable path for resolution on issues as they converge.

Managing a process to get a Good Daily Build™ is not always easy when you need pieces coming from two different organizations which are very large and working in many, many branched source depots.  But staying on top of things so you can quickly help your customers/partners move forward progress is a very rewarding experience.  My daily routine has helped me stay on top of the core issues at hand and determine a daily quality on the mainstream scenarios as our customers see them, which isn’t always caught with test automation or unit tests all the time (but yes, we have those too).

Well, a new build just came out…time to update my wiki!

| Comments

wow, some great news from the tfs group... i'm not sure how this slipped my feeds, but must have been while i was out...at any rate, if you want to hear some good news on the team foundation server front.  i love it when companies listen.

from bharry's blog (emphasis mine):

We made one significant licensing change for TFS with the release of TFS 2008.  We've gotten a lot of feedback over the past 2 years that there are classes of users who make very light use of TFS and for those users a $500 CAL (list price) is just too much.  Most of these scenarios involve some kind of very infrequent access to work item tracking.  We've decided to tackle one of the scenarios with licensing changes in 2008.

The new licensing provisions are designed to make it easy if you want to allow lots of people in your company to use TFS to file bugs, feature requests, etc and have them available for your development team.  Specifically they allow an unlimited number of users in your company to create any work item, query for work items they have created and view or update any work item they have created all without a CAL.  This right comes with your Team Foundation Server Standard Edition server license and requires no additional purchase.

Please keep in mind that this is focused narrowly at this scenario.  If this works well, customers like it, people understand the restrictions and use it properly, I expect we'll look at trying to simplify licensing around other similar scenarios in future versions of TFS.

The bad news part of this is that we really don't have any UI that restricts users to exactly this scenario right now so it's hard to know you are in compliance.  We have committed to producing software changes within the next year that would allow organizations to feel comfortable that their users are in compliance.  We've talked about permission changes and UI changes.  My favorite option (which we are pursuing) is to add a new page to Team System Web Access that focuses precisely on this scenario and enable permissioning the site appropriately so that organizations can point their broad user base at that page and feel comfortable that users are staying within their license rights.  For now, you may consider building your own custom web page for doing something similar or you may just try to explain to your users what they are and are not allowed to do.

I hope this change addresses a concern that many of you have expressed to me.  Please read the updated End User License Agreement that comes with Team Foundation Server 2008 for an official statement of the licensing terms.  If you have questions or comments on this licensing change or others you would like to see, please let me know.

very cool.

| Comments

the patterns and practices team released the final version of the TFS Guide, a guide to using team foundation server effectively in development environments.

it includes:

    • fundamentals
    • source control
    • builds
    • large project considerations
    • project management
    • process templates
    • reporting
    • setting up/maintenance
    • vs2008 tfs

pretty cool, check out more details and download on the TFSGuide codeplex site.