| 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

I was searching my archives for sending something to my team this morning after looking at various bugs logged from customers, internal partner teams and ourselves.  I had an old post from 2005 but it unfortunately used a Shrinkster URL that appears not to be working.  So here’s the mail I sent to my team this morning.  This is purely my opinion but things that I think make a great bug report for fastest resolution:

------

As we triage and such I know that there are likely times that you are frustrated with not enough detail to even determine if this is a bug or needs investigation. This leads to feature teams spending time doing unnecessary things getting more data…and the cycle of time eventually delays product quality. To that end, when *we* log bugs I’d ask that you take into account my opinion of the “anatomy of a good bug”:

  • Title: Required. This is obvious. The title should be concise but describe the problem in one line so that someone can quickly glance at it and get a feel of the issue immediately. Something like “control doesn’t work” is not helpful. Something like “TreeView shows blank nodes when binding to hierarchical data” is much more descriptive, yet concise.
  • Path: Required. Almost every bug system requires and area/path assignment. You should do your best to assign this to where you think appropriate. If you are crystal clear, select the specific path. If you aren’t, then don’t guess too deep. Putting something at Product\Feature-Team\Feature-Area\Functional-Area\Control-Name might be too “deep” of a guess and would get bounced around. When in doubt, get up to the feature level and let triage teams who likely know the right path put it deeper or re-assign.
  • Keywords: Optional. This is helpful for you usually. If there is a place to set keywords, you should consider putting some that might be helpful for searchers or yourself. However don’t spackle keywords all over titles/descriptions.
  • Assigned: This usually defaults in bug systems to something like “Active” or “Not Assigned” – unless you know the specific person it should be assigned to, don’t guess.
  • Priority/Severity: Optional. This usually defaults in systems as well. If you think the default is not correct for your issue, then change it. But if you are changing it to a higher (read: must fix ASAP) then you owe it to someone to send an email out. Logging high-pri bugs without an email is usually not a good idea.
  • Build/Branch/Version: Required. Systems call these things different, and sometimes they are individually separated as well. However, this should be seen as required information. When someone looks at a bug they should know on what version of software you are using. They may immediately know “oh that was version 4.12, cool I know we fixed that in 4.2” and add that information to you back. Absent that information the investigator is left guessing on which build/version you were using and they may be flailing for a while with various versions. Even if there are fields for this in the system I usually always put this at the top of the repro steps as well for greater visibility.
  • Description: Required. Yes you put a title, but you still owe it to the investigator/triage to provide a bit more depth. The description should re-iterate the title, but also provide the scenario and other supporting detail. Things like “it worked in version XYZ” or “works on competitor platform Z and adds significant value to customer” are some additional data points that help understanding why you are logging it. Descriptions maintain history of the bug so pasting emails for context, etc. are entirely appropriate IMO.
    • NOTE: I used an example of “worked on version XYZ” – some systems have specific indicators whether this is a Regression or not. Even if they do I would indicate regression data in the description.
  • Repro Steps: Required. Perhaps the absolute most critical portion of your bug log. IMO this should include:
    • Version/Build/Branch
    • Steps – verbatim – yes I usually write these out with numbered lists:
      • 1. Open VS
      • 2. Create new C# Application
      • 3. Open designer and write this code
    • Once you hit the issue at hand break into Expected/Actual statements. This is where you would note what you Expected (i.e., “Control would render on UI surface”) and what was the Actual (i.e., “UnhandledException of type foo shown and crashed VS”).  In the Actual section would be a good place to paste call stacks, exception messages, etc. in addition to any simple error seen.

Here’s a template I use for the “repro steps” area of a bug report to remind me:

Repro on Version XYZ

Repro Steps:

  1. Step 1
  2. Step 2

Expected:

What did you expect to happen

Actual:

What actually happened

I find this has been helpful to continue to remind me of what is required and helpful.  Most systems allow you to create bug templates.  I have a bug template that includes this primer data in the repro steps for me.

  • Sample Repro: Required. In my opinion, this is required. There is no greater path to resolution or understanding of a given bug then by having your specific issue immediately available. Without it the repro steps are helpful but may not be detailed enough in the code that you are using as well. This sample repro should be isolated to the issue at hand and should be simple to get up and running. If you send me a zip of your ERP system and expect me to fix why text is right-aligned incorrectly, that’s a colossal waste of my time getting a huge app set up trying to find the one issue. Often this exercise of narrowing the repro also identifies some issues where it might be user code. Regardless, provide a repro and keep it simple.
    • Sometimes attaching screenshots of what you are seeing is appropriate as well to help with an issue that might be a visual one and leads to faster understanding than setting up the repro.
  • Close Bugs: When bugs are resolved back to you as fixed do your diligence to verify your bug quickly and close it out. Historically up to 15% of resolved bugs are re-activated. If we re-activate too late, we run the risk of missing key quality points in that area where you logged the bug. If you cannot verify it (because of time, out on vacation, etc.) then reach out to a test lead and indicate you cannot verify soon enough and request assistance to re-assign the Resolved bug to close.

Following these principles helps drive quality into our products. It does this by leading to faster times to get to understood, agreed-upon bugs. Please make sure we help our own team and partner teams when we log bugs to ensure we’re providing good information to help them fix what we think are issues.

------

I hope this helps perhaps as some guiding principles when you log bugs against products that you use and/or within your own team.

| 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.