The introduction to this series can be found at https//blog.mavnn.co.uk/getting-started-with-fake-an-introduction-tag or just check out my Fake tag.
The scenario
So, you’ve written your brave new F# 3.0 solution, and now you want to build, test and package it with a shared build setup between your CI environment (which, of course, doesn’t have Visual Studio installed) and your developer’s machines.
Hopefully this will walk you through most of the potential pitfalls you might find along the way.
This post has been written using an actual build.fsx script that we use for a utility project at 15below. We’re hiring, so if you’re interested in this kind of thing, drop me a line.
Set up
There is no installer for the F# 3 compiler, so we’re going to be playing some games to support building on a TeamCity build agent without VS 2012 installed.
The script assumes a few things about your repository:
- a tools directory with the same NuGet and FSharp directories as at https://github.com/fsharp/FAKE/tree/develop/tools (basically a recent nuget.exe in one, and a recent build of the open source F# compiler project in the other)
- a tools/FAKE directory with a recent build of FAKE (I prefer to have a known version checked into git, but you can read instructions on how to bootstrap it via nuget at http://www.navision-blog.de/blog/2009/04/01/getting-started-with-fake-a-f-sha…
From here on down is just a heavily commented build.fsx file. I was going to use FSharp.Formatting to nicely format this, but unfortunately the combination of FSharp.Formatting itself and Posterous have defeated me. Something to play with more at a later date.
Hopefully this example will give you a start on using FAKE in real projects.
In future posts I’d like to address some of the more esoteric bits and pieces we’ve been using FAKE for, such as building Octopus deployment packages, running integration tests (with full setup and database deployment) and running unit tests in parallel. Stay tuned…