I recently sent round a list of broken builds at SSW and asked for them to be fixed or deleted if they are not being used. My colleague Peter came back with a couple of questions which I love as it tells me that at least one person reads my email
I think first we need to answer a couple of other questions related to builds in general.
Why do we want the build to pass?
What could a failed build signify?
Now we know why, lets answer Peters questions:
You can normally only see the builds listed for each project. But, you have a little application called “Build Notifications” on your computer. It is installed when you install Visual Studio 2010.
Figure: Staring the build notification application on Windows 7.
Once you have it open (it may disappear into your system tray) you should click “Options” and select all the projects you are involved in.
This application only lists projects that have builds, so don’t worry if it is not listed. This just means you are about to setup a build, right?
I just selected ALL projects that have builds.
Figure: All builds are listed here
In addition to seeing the list you will also get toast notification of build failure’s.
The only thing worse than breaking the build, is continuing to develop on a broken build!
Figure: I have highlighted the users who either are bad for braking the build, or very bad for not fixing it.
To find out what is wrong with a build you need to open the build definition. You can open a web version by double clicking the build in the image above, or you can open it from “Team Explorer”.
Just connect to your project and open out the “Builds” tree. Then Open the build by double clicking on it.
Figure: Opening a build is easy, but double click it and then open a build run from the list.
Figure: Good example, the build and tests have passed
Figure: Bad example, there are 133 errors preventing POK from being built on the build server.
For identifying failures see:
So, Peter asked about blame, let’s have a look and see:
Figure: The build has been broken for so long I have no idea when it was broken, but everyone on this list is to blame (I am there too)
The rest of the history is lost in the sands of time, there is no way to tell when the build was originally broken, or by whom, or even if it ever worked in the first place. Build should be protected by the team that uses them and the only way to do that is to have them own them. It is fine for me to go in and setup a build, but the ownership for a build should always reside with the person who broke it last.
This is an example of a pointless build. Lets be honest, if you have a system like TFS in place and builds are constantly left broken, or not added to projects then your developers don’t yet understand the value. I have found that adding a Gated Check-in helps instil that understanding of value. If you prevent them from checking in without passing that basic quality gate of “your code builds on another computer” then it makes them look more closely at why they can’t check-in.
I have had builds fail because one developer had a “d” drive, but the build server did not. That is what they are there to catch.
If you want to know what builds to create and why I wrote a post on “ Do you know the minimum builds to create on any branch? ”
Technorati Tags: TFS 2010 ALM VS 2010 TFBS Silverlight SSW SP 2010 SharePoint
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.