Automated Builds

I’ve been on several different projects across various organizations and one thing that I notice consistently is that they do not have an automated build in place for their projects.  Either the developers do not understand the concepts and benefits behind using an automated build or they choose to neglect it because it’s extra work.  Automated builds is an important aspect of a project similar to source control.

What would an automated build do?

• Clean build artefacts
• Build the application binaries
• Tear down and rebuild development and test databases
• Run Unit Tests, Integration Tests, etc.
• Run Code Coverage, Metrics, etc.
• Deploy application to specific environment (i.e. dev, test, prod)
• Recompile libraries and binaries used by the application
• Notifications
• Version application binaries
• Branching / Releasing your application
• Perform daily builds (via scheduled task or Cruise Control .NET)

At the beginning of the project, spend a day or two setting up an automated build to at least clean, compile, and test your application.  As the project matures, when required, you can add extra features such as code coverage, deployment, etc to the build script.  Trust me, starting off the project with an automated build will save you a lot of time and headaches as the project continues.

The benefits of using automated builds are:

• Reduce time and effort to build the application
• Reliable builds of your application at any time
• Avoid tedious, repetitive, and error-prone work
• Reduce the risk of creating unknown dependencies

Some tools to help with automated builds are:

• MSBuild (Bundled with .NET Framework)
• NAnt (Open Source)
• Cruise Control.NET (ThoughtWorks)
• TeamCity (JetBrains)
• Team Foundation Server (Microsoft)

* The tools stated above are for projects built on the .NET Framework.  There are similar and/or equivalent tools for other development platforms.

Hopefully in the next week or two, if time permits, I will post some NAnt and MSBuild samples.