Friday 14 March 2008

Scaleable unit testing and continuous integration in an agile team using GIT

I like agile development, it works, but it does need some pretty clear guide lines and rules. It also needs very good testing systems to ensure no developer breaks anyones elses code.

Up until now, I have been using the same tools as everyone else.

SVN, perforce, CVS, etc... we all know this type of source control management system.

We all know how these systems work.

I take a task, I write my unit test, I make sure it fails, then I write my code until the test passes and all other tests pass as well. Then I can commit my code.

When I commit my code, the continuous integration system kicks in, re-builds the application, runs all the units tests, and then the functional tests.

It is really cool. Especially if you have been developing for some time and remember 'the older days'.

The 'Old Days' when we worked alone were much easier, but we need teams now, and we must have ways to manage and control working together.

However, about half the time, when I check in my code, I break something, and the continuous integration system bleeps loudly and displays an embarrassing photo of me.

So now I have to fix the problem. And that's ok.

However, with any decent sized team, you now have a single point of failure.

The build server itself.

Everything merges at this point, and many regression mistakes are only discovered when the code is checked in. This means that the primary development codebase is now broken.

And this tends to happen often, every day.
A right pain if you are running a tight release cycle.
There is no way you can pass broken code to QA.

It gets even worse, when tasks are larger, the changed code coverage is large, and it has been quite a few days since it was checked out.

Now, it is possible, and good practice, to do a checkout before checking in. But how many times have I seen this forgotten in the rush to get a release ready.

So that's the problem.


The solution that I have recently converted to, is GIT.

This distributed SCM, at first seems rather primitive, but on further examination, this primitive nature hides a great deal of raw power.

Distributed SCM means every developer can commit to their own repository, so they can roll-back their own code if they go in the wrong direction.

Distributed SCM also requires much better branching and merging.

It is simple to create a distributed branch for a micro-project team, each developer can now clone this branch, work locally, commit locally and then check their code back into the branch.

The micro-project team leader can now do code review, unit testing and functional testing, before committing the completed project back into the primary codebase.

So now, at any point in time, you can take a copy of the main codebase and pass it to QA for testing and release. Knowing for certain that only working code ever makes it into the this codebase.

This allows you to move to a fast release cycle. A new feature has been added. Now you can test and release knowing everything will work.

In effect, you have moved the larger scale unit/functional/regression testing further back into the development process.

What you also managed to achieve, is secure asynchronous micro-project development, so each micro-project team can now work independently while still being agile.

And all the effort ends up in a single unified codebase that works!

This is the secret to scalability in agile development.


The title of this little note does promise to let you in on how to integrate the unit and functional testing of continuous integration into GIT.

I love this, it is so simple.

Because GIT is so primitive, it runs scripts, that actually sit in the repository itself.

All you need to do, is edit the scripts to add your testing.

Even better, you can set it up to run pre or post any command.

e.g.: run unit tests post-commit.
e.g.: run functional testing post-merge


With a little thought, you can have an entire workflow mapped out that will only allow unit tested, function tested, regression tested and codebase merged micro-projects to be committed to the primary codebase.

As far as I can see... this is as close to the holy grail as we have ever been.

Have fun.

No comments:

Post a Comment