Setup of a Continuous-Integration server for C# web-applications and libraries

Question

I have been testing Jenkins CI, and now it is time to build a server. What is the best way to go? There are plenty of options, and I don't know what one to choose.

• a shared machine, with other server running with it,
• a virtual machine, inside a machine used for other servers
• a stand-alone machine
• use multiple machines with different OS, on each to test each platform? (I have some web UI tests, based on selenium)

And also, I want a suggestion of the OS to use. I use msbuild, and probably that is only available on Windows... but maybe a linux server, with some sort of builder from mono may be the best way to go.

I am not tied to Jenkins, but it seems to be the best. If you know of better options, let me know.

I need opinions, I need to know what possibilities exist, and if possible, to know what others are doing, and what experiences you have with various setups, so that I can make a solid decision.

Thanks!

Answer 1

First things first. My CI server is a VM running CruiseControl.NET. I dont use Jenkins so I cant really comment on it. From the looks of things, Jenkins is more well-developed than CC.NET.

Per the virtual vs physical question: ultimately, it doesnt really matters as far as CI is concerned. As long as it is visible on the network and has enough resources to perform it's function, the rest is just administration. Personally, I find benefits of virtualization to be worth the extra effort. You can easily add resources, move its physical location, stand up additional VMs to run a cluster. The benefits of virtualization are well known and everybody is doing it these days.

My CI server is on a VMWare ESX server that has a ton of CPU and RAM to dish out. It runs many other VMs on it. I have about 35 sites running through CI and probably 20 are hosted on the machine itself and another 70 sites that are set to build by manually triggering them through the CI dashboard. I have never had any relevant performance issues with it.

Your build server should ideally have the same setup as whatever machine(s) you are planning on deploying your code to. For websites, that would be the same OS as your production servers (probably Windows 2003 or 2008). For desktop applications, I would probably just pick the latest and greatest OS that you are targeting for support and can afford.

Using multiple machines with multiple OSes would only be relevant when you are building desktop applications that you are trying to support on multiple OSes. In this case, having multiple servers would be ideal, but I see that as being a lot of work to get set up. Personally, I would start simple, get everything running and start adding pieces on when they become truly necessary.

As I mentioned, I use CruiseControl.NET. It's been great so far and I am happy with it. Since it is written in .NET and you are using .NET, there are less moving parts that your server needs to get running (I see Jenkins is built on Java). Writing plugins/extensions would be theoretically easier since you already have .NET people in house. I've never written an extension for CC.NET so I cant say that with certainty, though I know it is possible. The down side is the community is small and active development is slow.

Finally, I'll add that it will be A LOT of work to get started. It took me over 6 months to get my CI server ready for production, a few more to migrate all of our projects over to run through it and many more to train the rest of the developers on how to use it or work with it.

So, in summation,

• Virtualization is good! (but it doesnt really matter).
• You should match you CI environment to whatever envirnoment you are deploying to, if possible.
• You better be ready to commit for the long haul.
• Continuous integration is great and you wont regret setting up a CI server. Whatever you choose, it will be better than the "cowboy coding" that used to go on :)

EDIT Other answers are posting their process, so I guess I should have done that too! :)

My shop builds LAMP and .NET websites so we needed something that could work effectively with both. We have CC.NET running as the core framework but nearly all of the functionality is performed by custom Nant scripts. We use Nant because it is 1) .NET based and has built in .NET commands and 2) is easy to perform command line operations which form the core of all of our build steps.

CC.NET listens to the SVN server and grabs updates as they are made. CC.NET checks them out and fires off the NANT task that performs all the actual work. For .NET, that means mstest to unit test and msbuild to build and publish. PHP usually just moves the files straight to the destination environment. Then, if all steps were successful, Robocopy will copy the files to the destination server, which was mapped as a network drive during a Group Policy startup script (Windows servers are mapped with net use and LAMP servers are mapped with Webdrive).

We have development servers, staging/QA servers and production servers. Since we work in .NET and LAMP, we have one server per environment for each of these stages - 6 in total and all are virtual. Our development servers are the only ones that are set to a continuous integration build. Staging and production are force-build only along with some other SVN wizardry to prevent accidental deployments. We also build and unit test AcrionScript using MXMLC but that is rare for us.