How do you get up and running with a build server?

Question

I think everyone here would agree that in order to be considered a professional software house there are number fundamental things you must have in place.

There is no doubt that one of these things is a build server, the question is, how far do you need to go.

• What are the minimum requirements for the build server? (Somewhere to just compile?)
• What is the ultimate goal for your build server? (Scheduled, source control integration, auto deployment to test / live servers)
• Where is a good place to start assuming you have nothing at the moment?

It would be great if we could list out a few simple tasks that an amateur developer could take on board in order to set them on the right track to a fully functional build server.

It would also be good to hear about people that feel they have a "complete" system setup that performs all the functionality they require and how they went about setting it all up from scratch.

Answer 1

You can start by looking into Cruise Control.

There's also CruiseControl.net if that's your poison.

Essentially though, you need the following ingredients:

• A dedicated environment (Virtual Machine/server. Don't use a developer's machine, unless it's just you. Even then, run a VM if you can. Much easier to move it to a server when/if one becomes available in your organisation)
• A source control system that supports labelled/tagged revisions (for example, Subversion+TortoiseSVN)
• Build scripts. These can be batchfiles that start the devenv.exe or msbuild.exe applications with a command line, or you can use something like Ant or NAnt.

In this scenario, CruiseControl acts as the Continous Integration server, and can make sure that you have builds done as you check in your code. This means you know whether the build is broken quicker than if you just had nightly builds. You should probably also have nightly builds, though.

Answer 2

If you're using Cruise Control, the place to start is an Ant build.xml that does the job manually.

You need a version control system that can do labeled check-outs.

You need JUnit tests to run using the Ant task and generate HTML reports.

Answer 3

I couldn't give you all the details about how we set our build server up (I was only involved at the start), but:

1. We started with an in-house system, implemented in ASP.NET and a .NET Windows Service, using NAnt to do the actual builds. Actually, most of the workflow was implemented in NAnt (e.g. emailing people, copying stuff around, etc.).
2. We moved to JetBrains TeamCity (there's a free cut-down version available), which is still serving us well.

We use it for builds triggered by a commit: these just build the binaries and run the unit tests. From here, we can do a complete build, which does the MSI as well. From there, we have system test builds that run more in-depth tests, across an environment built with virtual machines (with a separate domain controller, SQL Server box, etc.). When the system tests pass, the build is made available to our QA department for manual testing and some regression tests that we've not automated yet.

Answer 4

Id say you'd have to start by implementing a build strategy so you can build your code in a structured way - I use NANT.

For a basic build server - use one of the CI offerings out there that monitors your source control and triggers a build whenever a change is detected. eg: cruiseControl.

Once you get the basic build together - add the running of your unit tests after a successfuly build.

The most successful system i've had in place had 3 different builds :- - one that fired on a check in - all this did was build the code. - an on demand one that would build the application, generate the installer and then put the installer into a shared drive for the testers to pick up - a daily build that fired at 10pm. This: - ran some code generation to build DB and C# code from a UML model - build the code - created a new build verification test user on a test oracle instance - ran the application schema into the db - fired off a bunch of unit tests - cleaned up the db user (if the tests were successful) - ran coverage analysis to build a report of the unit code coverage

Software we used for this was NANT, CruiseControl.NET, a custom code generation system, custom app to build an oracle schema, and NCover for the code analysis.

Answer 5

Start by having a read of Martin Fowler's excellent paper on Continuous Integration.

We built such a system for a major project >2,000 kSLOC and it proved itself to be invaluable.

HTH

cheers,

Rob

Answer 6

In the java space I've tested most of the available build environments. The issue with automatic build is that you quite often end up spending a fair amount of time following it up. After we switched to the commercial bamboo from atlassian, we found that we have to spend a lot less time pampering the build box, which in our case turns out to be very good economy. Bamboo also supports clustering, so you can add inexpensive boxes as needs evolves.

Answer 7

I'm using Cruisecontrol.NET and an msbuild buildscript.

I can use the buildscript manually so that I can get the latest version of the codebase, built the codebase very easily using the commandline. (This is very interesting if you are working on an application that consists of multiple solutions).

Next to that, my CruiseControl.NET buildserver uses this buildscript as well. It checks on a regular interval if there have been changes committed to the source-control.
If that happens, CC.NET performs the 'get-latest' task that I've defined in the buildscript, builds everything, executes unit-tests and performs a statical code analysis (fxcop).

My 'buildserver' is just an old workstation. It's a PIV, 3Ghz with 1gb RAM, and it does its job perfectly.

One additional thing that I would find interesting, is to have the ability to automatically deploy a new version, or build a setup. I haven't done that yet, since I'm not sure whether it is a good idea, nor have I found a good strategy yet to do so ... I mean; is deploying a new version of some components into production for a mission-critical application a good idea ? I don't think so ...

I think this is a good place to start: [http://confluence.public.thoughtworks.org/display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]

At least, that's where I started looking when setting up my build server. :)

[1]: Home of CruiseControl

Answer 8

Try & find something that fits in with your existing practices in terms of building - e.g. it's not going to be a good fit to try & use an Ant-based buildserver if you're using Maven, for instance!

Ideally, it should just be able to monitor your source-control system, checkout the code, build, run some tests & publish the results without you being aware of it, or at least not 'till it's reporting a failure. Personally, I'd suggest Hudson (https://hudson.dev.java.net/) as a good starting point as it's easy to get installed & running & has a decent UI.

Answer 9

Hi,

Hudson is a great CI.

We run farm locally, but we started by downloading hudson.war and doing

java -jar hudson.war

It integrates with SCM, bug trucking systems it is really awesome.

You'll need some disk space if you want to keep old build.

Enjoy it is most straightforward CI solution so far.

HTH, Hubert.

Answer 10

Cruise, Maven, Hudson etc are all great but its always worth having a stopgap solution.

You should have a batch file, shell script or simply written instructions that will allow you to run a build from any machine. We have had build servers unavailable in the past and the ability to switch quickly to another machine was invaluable!

The spec of the build machine need not be important unless you have a monster project. We try and keep our build times down to 10 minutes (including unit tests) and we have a pretty big project.

Don't be tempted to create or write your own build system because "none of the tools out there are good enough". All modern build systems allow you to write plugins to do custom stuff.

Answer 11

Roughly in order - minimal/least sophisticated through more sophisticated

• able to get a specific set of source onto any machine
• able to build that source (with no problems)
• able to (schedule) build each night/or some other defined period with no user intervention
• One (or more) dedicated build server (not shared as qa or dev machine)
• able to do a build after each check-in/commit
• Notify interested parties of the build status after a build
• Provide build status at any time
• Create installers as part of the build
• ability to deploy/live if build is good
• Run unit tests
• Run tests on the product
• Report the results of those tests
• Static code analysis and reporting ... And the list goes on and on

Don't be afraid to just start with batch files or shell scripts or other ad-hoc means. People made perfectly good software before the CI craze. there were plenty of good processes before Hudson and Cruise Control - ( I am not knocking those or others - I use Hudson among others) - but don't miss the point - these things are here to help you - not become overbearing process)

Answer 12

We start by writing batch scripts that will run on the developers machine. Once we have all the processes automated, we move them to the build server.

On the tools side we are currently moving from Cruise Control to TFS.