Enterprise CI (SOA / .Net)

How should I tackle Continuous integration for a SOA platform?

Let me explain the setup. We have 30 web service solutions and 5 client solutions, the web services are quite dependent on each other (references contract dlls) and also share some common utility dlls.

Until now we have been happy with CruiseControl.net (37 CC projects, 5 clients, 30 WS, 1 utility project, 1 integration test project) all building and testing independent of each other. Before each deploy we trigger the builds for all projects in a well-defined order which gives us ready deploy-artifacts to deploy to some 7 different servers.

Until now we haven't had any versioning of services, and each deploy would deploy the complete shebang.

We recently went into production and now we need to branch out the code, so that any further development does n开发者_StackOverflow社区ot mess up our ability to hotfix what is in production now.

Also we want to split up our efforts, spawning separate development efforts creating new clients or adding major functionality into existing clients/services, what I'm thinking is that we need the following

that way we can always hotfix prod with very little effort, we will continue to improve prod based on user feedback on a monthly basis, and we can launch new major efforts on our SOA stack without interfering with the first two (until we merge the code that is :) )

The question is: what tools should we use for CI? options as I see them:

1. duplicate projects within our ccnet instance
2. duplicate ccnet: xcopy CCnet to X locations on build machine, setup new services on different ports, tweak svn source, build location and deploy artifact location
3. use a different CI server more suited to these problems

1: I don't like it (unwieldy, when is it green, all teams use same pool)

2: I could see us doing this, but it feels a bit clunky

3: Which server should we use? So far I've heard the names Hudson and Cruise, would these be applicable?

4: Have I thought completely wrong? How do you other guys do CI on a SOA stack that is meant to support many teams' development efforts?

I would throw Teamcity into the mix. It uses a grid of build agents which may be able to give you a little more horsepower as well as ability to perform simultaneous builds.

With your sheer number of projects it might be tough to replicate your build three times within the same instance of any particular build server. That would be over 100 projects to keep track of on the same page.

Option 2 is definitely viable although I might consider leveraging virtual machines, creating one build server image, and then hosting three instances of that which would result in three nice urls without using different ports as well as three identical setups to maintain.

One other consideration; perhaps you could collapse your 37+ projects into fewer ccnet builds by grouping related components and using nant\msbuild\ruby\powershell scripting. If you can get down to 15 builds then running all three variations in the same server instance becomes more viable.