| 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

As I patiently awaited, here’s what was presented to my browser:

Build successful image

I’ve made my first official “commit” to an open source project that I didn’t start.  I feel good.  I feel like cracking open a Mt. Dew and going crazy.  Honestly though it does feel good (and fun). 

My blog engine I use is .  It’s the blog engine I’ve used almost exclusively (I actually started with .Text before scottw sold out went to Telligent to make Community Server.  I kid of course, Scott is a great guy, and very smart.  But when .Text was seemingly going to get stale, others stepped in.  Notably Phil Haack started Subtext which was an initial fork of .Text.  I’ve used it ever since and haven’t looked back.

SubText logoSubtext has a great community of developers that communicate regularly, share ideas, get feedback…all the things you’d expect out of an OSS project but don’t always get.  As I mentioned this was the first project I really got dirty in that wasn’t mine in the OSS world.  Over the past year or so I’ve been giving feedback, making some modifications to fit my needs, etc. but hadn’t really contributed much literally beyond “you guys should do this” comments.  Most of that was because of time and because I had fixed things for my own needs.

Until today.  This past week I had been submitting patches to the team with feedback and things that I really felt valuable and used in my custom build.  Yesterday I got an email from Phil asking if I wanted commit rights to the SVN repository.  I admitted my nervousness, but he let me in anyway :-).  I have to admit that the image above wasn’t the first one I received :-).  I was quickly met after my first commit with a failed build.

Sunofa...I broke the build.  Well, I will go to my grave saying that I didn’t, but something did.  I believe the popular thing is to blame Vista…so I do that too.

At any rate, with some hand holding I figured out the error of my way (had one file wrong) and got my changes into Subtext 2.0 trunk.  I'm really excited to be a part of this community with Subext even on the smallest scale compared to all the others who do the real work.  I'd encourage you all to find an OSS project and help out...with feedback and resolutions.

I'm not sure when my stuff will make it into the next Subtext build for release but I've previously written about what modifications I've made, but here's what I committed today:

    • Enhanced MetaWeblog API implementation to support providing a "slug" URL name for the post.  This gives the user the option to use the default URL naming, the "auto-friendly" or now to override that with your own slug name.
    • Fixed a bug in the SiteMap handler for blogs not hosted at root domains.  Would love people to test this out.
    • Added support for WordPress API functions of: newPage, editPage, getPages, newCategory
    • Simple modification to the Windows Live Writer manifest to prevent those who think they can future post :-)
    • Tag-based RSS syndicator

In all honest, most of my submissions were self-motivated.  I think that is really what starts getting people involved in OSS projects...not an interest, but selfishness.  All the changes I made are there to make Subtext+Live Writer the best experience it can be.  With the WordPress API implementation you can now create new "pages" in Writer that are Articles in Subtext.  It also supports adding new categories on the fly within the API.  It may not affect many who use Subtext, but I was happy to contribute and hopefully add some small value to the project!

Related Post: