SVN, TeamCity virtualisation / hardware requirement

Question

I am trying to put a requirement together for a new environment to consist of TeamCity running of Sql Server, a couple of build agents (for now) and an SVN repository.

There are 6 developers and there will be 5 active solutions partaking in the CI process for now which will obviously grow over time. None of the solutions take >10 minutes to build currently so they are not huge in terms of complexity & loc.

The build projects will themselves need an instance of sql server so the automated tests can run - I assume they should be kept separate from the TeamCity sql instance.

Can anyone suggest a hardware config suitable to run these. Is disk i/o going to be more important than actual CPU power.

Can I run all these on a single multi cpu, raid and virtualisation?

Should we be running with windows 2008 and hyper-v?

I have always let others deal with server requirements and build but now I have to get my feet dirty.

Any advice most welcome

Answer 1

A data point:

Our TeamCity environment is on (if I recall correctly) a trio of 8-core servers each with 32Gb of RAM, running Windows 2008 and HyperV. Our SVN repository is on a different server (for historical reasons). I think that everything is on a SAN now, for reliability (if one of the hosts goes down, we can easily move the VMs to another host).

We have 10 build agents, all running in VMs. 4 of them are used for straight builds; 6 of them are used for builds and to run system tests (which involves coordinating other VMs in the tests). We opted for this because some of our system tests take 11 hours to run, and we don't want to hold up the build queue. We have phased releases -- a project ideally doesn't get released to the test department until it passes automated unit and system testing.

We have about a dozen developers actively working on 3 or 4 projects at a time. We also use TeamCity for building hotfix and maintenance releases.

In your scenario, I'd opt for Windows 2008 and HyperV, on the biggest box that you have the budget for. Disk I/O is more important than CPU power, but with more cores you can more easily scale to more VMs. Plenty of RAM assigned to each VM avoids swapping, and aids caching, meaning less Disk I/O. At a certain point, you might consider having two or more boxes, for fail-over, and because it's sometimes cheaper to buy two boxes with 32Gb of RAM than to buy the 64Gb option for a single box.

One advantage of using VMs is that you can snapshot them and revert them periodically. Each project should probably have its own instance of SQL Server.