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!