So we decided it was time to perhaps investigate alternatives.  The obvious choice for Symfony would be to use Sismo, but sadly it hasn’t been released yet… Fabien, any clues as to a release date? ;-) It looks at the moment as if we’re stuck with a Java-based solution, so we decided to look at Hudson as an alternative.

Setting up Hudson was straightforward using Nicolas Perriault’s blog post on exactly what we were trying to achieve, linking in with our Subversion repository.  The configuration of the projects took a bit of faffing – for some reason, Hudson liked to check out the whole repository rather than just eg the trunk folder  as specified, so this screwed up some of the paths.  A bit of trial and error later and we were up and running with a build every 30mins if there are new commits, as this pretty graph shows… (using the jUnit XML output available in Symfony 1.4).  Total number of tests in blue, failures in red.

One thing to bear in mind if you’re getting test failures randomly, or perhaps always after a certain developer checks in (and it’s not a result of broken code) is to ensure that the permissions are correct for Symfony, as SVN likes to store permissions where it can.  The fix for this, apart from committing new permissions, is to add a build step in Hudson that carries out ./symfony project:permissions (Symfony 1.3+) shortly before the build.  This seems to solve it nicely, and explained the small red peaks in the graph above.

If you focus on Quality, through effective refactoring and test coverage, speed will be maintained in the long term. When the code base gets quite large, speed of change can be difficult when there is poor quality code and little test coverage to support the code base.

You would be fooling yourself if speed was more important.
[Adrian Richte]

This has got me thinking about Test Driven Development (TDD) all over again.

Writing tests upfront for projects always  seems like a massive over head, but as any project gets larger, and more functionality is added, without any tests you just wont know what effect those changes are having on the rest of the system.  To run tests and see them fail means you can deal with an unexpected corner case before a client discovers it, and you know they will.  This will save time in the long run, and will also leave you with happy clients.

Scrum is an Agile method and allows us to develop features iteratively.  This means we’re best placed to be proactive about your changing priorities.