#2782

Big Visible Charts,Continuous Integration and Distributed Teams

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.

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 Analysis – FxCop 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.