Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SVN, TeamCity virtualisation / hardware requirement

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

like image 593
redsquare Avatar asked Dec 31 '08 09:12

redsquare


People also ask

How much RAM does TeamCity use?

The recommended initial size is 4 GB.

Is TeamCity owned by JetBrains?

What is TeamCity? TeamCity is a continuous integration server developed by JetBrains.

What is TeamCity tool used for?

 JetBrains TeamCity is a user-friendly continuous integration (CI) server for developers and build engineers free of charge with the Professional Server License and easy to set up!

How do I run TeamCity?

Install and run on WindowsRun the downloaded .exe file and follow the instructions of the TeamCity Setup wizard. The TeamCity web server and one build agent will be installed on the same machine. During the installation, you can: set the TeamCity Home Directory where TeamCity will be installed.


2 Answers

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.

like image 115
Roger Lipscombe Avatar answered Sep 30 '22 16:09

Roger Lipscombe


You should take a look at the How to section in our documentation: http://confluence.jetbrains.net/display/TCD65/How+To... There you will find "Estimate hardware requirements for TeamCity" topic. Probably it will help.

like image 28
Pavel Sher Avatar answered Sep 30 '22 16:09

Pavel Sher