How do you effect a build on an integration server?

Question

Assuming you have two developers working on a project locally on their laptops (A and B). They each have working copies of the SVN repo, and they're coding away in VS. Each one has a fully-functioning copy of the app. They commit back to SVN at every stopping point.

You have an integration/test server (C) which has another working copy which is updated whenever you want to test.

You also have production server (D) which has a post-build xcopy from C.

Say the code is a Web Application Project, so it requires an explicit build (as opposed to a Web Site Project which just takes the source code and builds on-the-fly).

How do you manage this on the integration server (C)?

If the developers build on their machines (A and B), then push the DLLs to the integration server (C)...this won't work, because the integration server has to take code from both of them and develop a common DLL. So, all the source code has to get to the integration server (C), be built there, and just the required files and DLL pushed to production (D).

How do you manage the build on the integration server (C)? Do you have a timed build from the command line? Do you install VS on the integration server (C) and build that way? If doing it from the command line, how to do manage the required references and other settings that VS normally manages in a CSPRJ or an SLN file?

Answer 1

The best solution to this question is to use a continuous build solution such as CruiseControl. You're correct in identifying all the pitfalls of doing it yourself, and in the end it will be far simpler to set up a third party package and not have to solve these problems yourself.

CruiseControl can be configured to build based on a subversion commit, on a timed basis, or on demand. In addition, it can also run all of your unit tests and alert people when things go wrong. It's altogether a pretty great package.

Answer 2

We also use a subversion commit hook from out svn repo, which activates the unit test build on each commit. We chain the different builds, so the integration test and the web tests run when the unit tests build green. Furthermore we'd really like to chain the release build at the end of all of these, but our integration tests aren't stable enough for this (flaky back-end environments with bad SLAs in development - I hate it!). At the moment we manually start the release builds. From a quality perspective we could go straight from all green lights to acceptance test servers, but that means you probably want alternating images running in acceptance test, since the build system can be creating quite a lot of down-time if it redeploys every time a successful commit has gone all the way through. (In our project we'd be down most of the time from 10am to 2pm, since there's a continious stream of commits around that time ;)

Answer 3

We use Cruise Control for continuous integration on the Integration server. Our cruise control script executes the following steps :

• Downloads the latest code from SVN on the cc.net server
• Executes MSBUILD file for compiling the latest code downloaded
• copy the release build in a separate folder
• We maintain a separate folder for "Release" builds, so the same script also commits the latest build in SVN "Release" branch
• Execute the Test cases [built using nUnit]
• Send out an email containing the build status & test execution results

The above commands are all configured on our CC.net server and scheduled for 1.00 am execution. For ease of maintenance we have deployed our CC.net server on our Integration server itself. that also helps us in executing our test cases automatically and sending out the results, if its a web application. Any code breakage is sent out in an email to configured subscribers and appropriate actions are taken the very next day.

Once everything is fine on Integration server, we simply "update" the "release" branch on Production server.

you can find more info about cc.net here

if you need help with the scripts, i can surely assist you.