Big Visible Charts,Continuous Integration and Distributed Teams

Thursday, August 13, 2009 – 4:11 AM

What are Big Visible Charts? Ron Jeffries defines them as:

“A simple chart on the wall can bring important information to the attention of the team, the customer, and everyone else who passes through the area.”

– Ron Jeffries

You’ll see these pretty much any team room you care to walk into. It might be a burndown chart, a graph showing the number of stories in progress or even the Nelly threat level.

CI and Big Visible Charts

It turns out that you can also use a CI server to publish big visible charts related to the software you’re building.

Here’s a big visible chart from the CI server for a personal project showing the build duration.

A big visible chart.

So what’s going on here? The short story. I added some slow running tests to my CI build (red arrows) and the total time per build crept up to nearly six minutes. Finally the graph shamed me into fixing the problem and getting my build time down to under two minutes (green arrow). In other words the big visible chart is doing it’s job – making me address the problem.

The whole thing is completely automated as part of the CI build. If need be you can also set certain conditions to fail the build, which puts things front and center for the team even if they’ve ignored the graph (by not looking at the CI server). CI servers like TeamCity and CruiseControl.NET will let you create graphs like this and your MSBuild or NAnt script can generate warnings or errors when conditions aren’t met (example of this for FxCop here).

I currently have graphs for:

Build Success Rate – How many times did some idiot (me) check things in and break the build?

Build Duration – Did the same person add some poorly written tests which slowed everything down? This is the graph above.

Test Count – How many tests do I have? Does the number of tests grow as I add more code/features?

Static AnalysisFxCop warnings and errors. StyleCop warnings and errors. Duplicate code analysis. Are these acceptably low (close to zero in my case).

Code Coverage – Overall coverage for all modules and the coverage of the worse covered module in the solution. Do they meet my criteria for “done”? When they don’t do I understand why and is this OK?

Code Size – Line counts for managed and native product and test code.

In a lot of cases the absolute numbers aren’t what’s important it’s the direction of the lines and how they correlate. You can add and remove charts as issues come and do. It’s a good idea to keep this to things you want to focus on. Too many charts and things start to get lost in the numbers.

CI and distributed teams

On a distributed team the CI server acts as a lynch pin for the whole team (more details).

  • It prevents the “it works on my machine” because the CI server is the only machine that counts.
  • It can enforce team wide rules as to coding practices. For example FxCop or StyleCop checked practices or even filename conventions or layouts. I’ve often written custom MSBuild scripts or tasks for this.

Putting it all together

If your team is distributed putting something up on the wall in the team room isn’t going to work as a Big Visible Chart if half the team can’t see it. Obviously you could put it on a wiki or SharePoint site or even have someone mail the updated chart to the whole team every day.

However, in a lot of cases your CI server can do the heavy lifting for you. The CI server publishes Big Visible Charts and they’re available to the whole team. It can be completely automated and configured to fail the build if certain conditions are met. For example serious static analysis errors are logged.

We’ve experimented with similar graphs and reports—specifically around code coverage and static analysis—on most of our projects at patterns & practices. All our teams have CI servers which publish various charts for the team and will fail the build when certain conditions aren’t met.

  1. 6 Responses to “Big Visible Charts,Continuous Integration and Distributed Teams”

  2. care to share more details on how you created these reports with ccnet?

    By moke on Aug 13, 2009

  3. Moke,

    I was using TeamCity, although p&p teams have used both CC.NET and VS Team Build. There’s some documentation on how to do this.

    I can also dig through one of our CI servers and write another blog post at some point if this is insufficent.


    By Ade Miller on Aug 13, 2009

  4. Atlassian Bamboo can display a build monitor dashboard w/ pass/fail status for the last run of selected builds. We use this internally within each of our dev teams:

    By Jesse Gibbs on Aug 18, 2009

  5. Jesse,

    I’ve not used Bamboo but I’ve heard good things about it.

    By Ade Miller on Aug 18, 2009

  6. Ade,

    I wrote a tangential blog post on Tuesday about big visible CI status:

    By Julian Simpson on Aug 19, 2009

  1. 1 Trackback(s)

  2. Nov 25, 2009: Distributed Agile Development at Microsoft Updated | #2782 - Thinking about agile (small 'a') software development, patterns and practices for building Microsoft .NET applications.

Sorry, comments for this entry are closed at this time.