This is the first post in what will be a series about how we moved to using Fake for our build and testing at 15below. Feel free to follow along for the ride. It’s partly there as a way of keeping the full development group within the company informed of what’s going on, so it will get pretty detailed and gritty in the later sections, but we decided that there wasn’t anything too company specific in here. So we’re sharing it with you all…

At my current employer, we have a wide range of code all the way from automatically translated vb6 (to vb.net) to brand spanking new F# and C#. At the end of the day though, everything runs on .net 4.0 (currently).

With the newer components, we could in theory be building and testing them independently: messaging based and developed in a TDD style they tend to have an existing test harness around them and be easy to add further tests to if it proves necessary.

The legacy code on the other hand, is a bit of a different matter. It’s still in the code base because it works. We know it works, because customers are using it and getting value from it. The bits that didn’t, or looked like they were getting flaky, are the bits that have been refactored as we went along. But they are old enough that what is now considered basic testing hygiene was still a little more than a twinkle in Kent Beck’s eye. (Ok, ok, so the book had been released. But it wasn’t exactly considered common best practice yet). So until the refactoring work is complete, we’re stuck with a system where the only feasible way of testing some aspects of it is to actually deploy it somewhere and run some jobs through.

So what does this all have to do with Fake?

Well, basically our continuous integration was getting out of control. To get the level of functionality and control we needed, we were ending up with somewhere in the region of 500 lines of re-entrant, recursive MsBuild scripts. I seriously considered starting the alt.ms.build.die.die.die newsgroup. A full build on a developer’s machine could take upwards of 45 minutes. Even more painfully, as the refactoring continued we ended up with TeamCity build configurations tightly coupled to specific versions of our software, and it was becoming clear that the whole CI system was going to rapidly collapse under it’s own weight unless things changed.

We needed a solution.

It had to be:

• Powerful. Programming in MsBuild is… not fun. Xml is for data.
• Storable in git along with our source code.
• .net based. We’re a .net shop, and our specialist knowledge is .net; rake wasn’t going to cut it. We also didn’t want the management overhead of even more tooling on the build agents.
• In active development.
• Preferably open source, so even if external development stopped we could continue to maintain it.

As both the company F# evangelist and one of the two people doing most of the CI work, I was very interested to hear about Fake, especially after having a chance to chat to it’s author (Steffen Forkmann) and having it recommended by Don Syme (who wrote F#).

It met all of the criteria above. It’s scripts are full F# – a language fully supported by Microsoft within it’s flagship Visual Studio product. The scripts can easily be stored in git. It’s actively being worked on, and accepting contributions as a fully open source product.

Time to give it a try.

Next post: how to set up your “HelloWorld.fsx” Fake script with your source, with all the niceties like intellisense that you would want.