Monthly Archives: May 2009

Video Interview: Code Coverage with Atlassian Clover

How do you measure the success of your TDD efforts?

Evaluating the quality of a codebase can be difficult. A tasteful amount of emphasis on code coverage is a useful indicator though. Too little and it’s too late to turn the oil tanker around. Too much and your developers focus on writing tests that provide line or block coverage, and not on providing value.

To do their bit,Atlassian have recently released version 2.5 of Clover, their code coverage tool. As well as doing classic code coverage, they’ve added some useful features:

  • You can measure coverage across multiple Java VM’s. This means that you can measure the code coverage that your functional tests give you.
  • The tool can run just the tests that exercise the code you’ve changed, shrinking your build times.

On Tuesday I went to pub to meet Michael Studman, one of the Clover developers, and Atlassian’s Man in London. We talked about what he’s been doing with Clover and why you might want to use it for your Continuous Integration services. The gory detail is in the ten minute video [we’re working on the transcription].

Thanks to the kind people at The Counting House, for sorting us out with a room to do the interview in. I had a headache the next morning; Michael did not.

Tagged , ,

Sweet iPhone Continuous Integration App

Douglas and John from Higher Order Bit have written an iPhone app that tells you what your Continuous Integration server is doing.

That isn’t so unusual, I wrote about one some time ago. But rather than just focus on one CI server, they’ve done the legwork to support four different servers, and they plan to keep going. Right now they support every flavour of CruiseControl (.java, .NET and .rb), Hudson and they are looking for opinions (see the poll on their website) on which to do next.

Says Douglas:

our goals were to allow users to check build statuses as quickly as possible and to accommodate “special” CI setups. To those ends we wanted to make it easy to navigate to builds on different servers, hide builds that you aren’t actively monitoring and support one-click updates. By one-click updates, I mean that on many occasions you should just have to open the app to see what you care about.

I tried a review copy it against my CruiseControl server and it worked nicely. The CruiseControl dashboard has an issue where it displays projects in the RSS feed that are long dead. You can drop these by using the ‘Edit’ button and unticking these builds that just won’t die.

Adding servers is very straightforward. You do need to know the proper RSS feed to use. That caught me out. Ideally it would take a guess at the kind of server it’s connecting to and guess the gory details of the URL. The blog editor that I am writing this post in (Blogo) does this. You just need to pass the basic URL of your blog service. Anyway, I suggested this change to the guys.

I think there may be a need for some organisations to publish some build state to the public internet, which might prevent some corporate use for the moment.

On the whole I’m quite happy with the app. It’s worth more than the $1/£0.59 that it costs right now, so go and buy it now!

Stack Overflow days look promising

We all lose when we are corralled into vendor or technology specific segments. Spolsky and Atwood are doing a conference to bring together developers who just want to be good. Not Java developers, not .NET developers, just developers.

Remember Byte? Every issue covered a wide range of topics and technologies. Sadly, Byte disappeared, to be replaced by Mac-only magazines, IBM-PC only magazines, even Microsoft SQL Server-only magazines.

link: Stack Overflow DevDays – Joel on Software

Guest Post: Test First in Operations

Today’s post is by Matthias Marschall of the fantastic Agile Web Operations blog. Matthias is the CTO of Autoplenum, when he’s not blogging.

Monitoring a server is very similar to continuously building and testing code.

In development, you write tested code, commit it to version control and the CI server tries to build and deploy the code to a test system and executes all tests.

In operations, you write a script (e.g. a puppet manifest or a capistrano recipe) describing the desired setup of your server and commit it to version control. A daemon like puppetd deploys the configuration changes to a test system. But who takes care of testing your new setup?

Testing Configuration Changes with Monitoring Tools

Just like development, it’s a good idea to make sure that there’s a way to verify every critical aspect of your server’s configuration. In operations, monitoring services like Nagios act as tests. They are the last step of your operations build chain: Verifying that your deployed configuration changes work as expected and have no undesired side effects.

Test First In Operations

In operations, the fundamental guiding principle is often never touch a running system.

In development, you tend to think the same only about untested legacy code. Having tests, you can touch your code anytime as you know that your CI system will catch any mistakes.

A test driven approach is possible in operations as well, but I’ve hardly seen it anywhere:

  1. Write a monitoring service for the config change you want to make and ensure that monitoring goes red.
  2. Implement the config change on the system and watch your monitoring system go green.
  3. Rinse and repeat until you’ve implemented all desired configuration changes.
  4. Like in development, you should have a test server for deploying and testing your configuration changes before deploying them to production. No shortcuts here.

Having tests makes you fast and safe, no matter whether you’re developing your web application or operating it.

Image by Docklandsboy

VIDEO: Big Visible Build Status at YouDevise

I had pizza with the guys at YouDevise on Tuesday. It’s always a pleasure; they are constantly inspecting and adapting what they do. The team had a talk about acceptance testing and CI, and I was privileged enough to join in.

They wrote their own build status visualizer and have been using it for quite some time, so I got a very quick video explanation. Thanks to Douglas Squirrel for pizza and presentation.