When to use a build tool?

Question

A beginner question, bear with me: I'm just wondering under what circumstances one should use a build tool like nant or msbuild? I'm working on a medium sized application (.net 3.0), every developer is doing his work and builds on his machine checking his code changes into the repository as he goes. Once we're all done, I'll get all the code from the repository, make a clean build on my machine and we deploy the binaries. Just out of curiosity, where comes the build tool in?

Answer 1

The short answer is always.

Each developer should be building using the build script before checking code in. The people building the release should be using the build script to build the release. Your buildbots should be using the build script to build and test the code that's been checked in.

Doing this allows all the developers, testers and buildbots to have a consistent, repeatable build. After all, The F5 Key Is Not a Build Process.

Answer 2

If you want to automate anything it's good to use nant/msbuild. For example: 1. check in 2. build 3. test and code coverage

Answer 3

Are you developing with Visual Studio? In that case, you are already using msbuild, since that is the underlying build engine of Visual Studio. Actually, a Visual Studio project file is nothing more than a msbuild script.

Apart from that, you can use the build engine on a dedicated build system, so that your binaries can be built unattended and without having Visual Studio installed. You can also use that for unit-testing.

Answer 4

I think any non-trivial application needs a 'build tool'. We use the term Continuous Integration where I work. There are very exceptional cases (e.g.: I'm building a sample app to learn how feature X works), but aside from those, you'll never regret having a solid build process.

I guess that if the development team was made up of one person... I'd still set up a build system including a repository, a building tool, and multiple suites of tests. Yes, maintaining the build system costs time and money, but it will pay off (I've been working for 40 months now on a project that started with 6 developers, and includes about 30 developers now; it did pay off for us a number of times) in terms of quality control, and the sooner quality issues are detected, the cheape they are to fix.

Answer 5

A build tool should be used when your process for building becomes longer than one command. It should be used to get your standard build process back down into one command. If your build process is longer than one command, then you have the opportunity for errors to creep in from missed/duplicated/incorrect commands being done during a build.

Answer 6

Agreeing with and expanding on zacherates' answer ... Yes, you should always have some repeatable build process. While technically Visual Studio projects are MSBuild files, it's better to have the "official" build process be separate of the development environment.

In my mind, this is true no matter how big (or small) the team is. I use NAnt and CruiseControl.NET at home, where all I tend to work on are scratch projects and experiments. At work, we use a similar setup, but a bit more structured in how the NAnt scripts are put together.

It's definitely worth your time to look into it. It's not a cure-all, but it is a best practice for knowing exactly which build was released when, and what's in the wild. Being able to identify your compiled code is half the troubleshooting battle! :)

Answer 7

It sounds like you are using an IDE to do your build. It essentially is a build tool; you are already using one. You should switch tools when the one you are using becomes more of a problem than a solution.

Answer 8

When you start doing releases or when your build exceeds certain number of manual steps (you'll notice when it starts getting annoying.) I've written an old blog entry on this topic which you might find interesting.