Continuous Integration Server Setup: From Dev to Production

Answer 1

To answer your questions:

• I would put SVN on a different server to the dev server. Often all sorts of rubbish is installed on dev servers.
• TeamCity can be on the same server as the SVN server. (Call it your build server)
• You don't have any resilience built into your production system.
  I would suggest having a minimum of two more servers, another web server and a hot standby DB server which is mirrored from your live DB server.
  These should not be at the same data center as the rest of your servers, and should use alternative gateways to the internet.

Answer 2

I've just set up TeamCity using SQL Server DB and an instance of our webapp running on Tomcat all on the same Windows VM.

• The TeamCity web server runs on Tomcat itself, and uses a good deal of memory (like any Tomcat app).
• The TeamCity Build agents, since they compile, use a ton of memory.
• SQL Server is a memory hog.

JetBrains mentions that Build agents should not be running on the same server as the web server optimally. I'd suggest that the database be separated as well (onto a physical box, not just a VM), so that the CI setup itself uses 3 systems (TeamCity web server, TeamCity database, TeamCity build agent). If your builds take more than a few minutes, I'd add another build agent server so that developers aren't queued up on commits, especially if you are using TeamCity's remote run/personal build feature from IDEA or Eclipse.

I wouldn't have a problem putting the SVN server on the same system as the TeamCity web server.

Keep in mind that compiling is an activity that is typically CPU-bound or disk access-bound. Build Agents will benefit from being separated onto separate CPUs and/or disks. However, being on separate VMs that are sharing disks and CPUs may be more wasteful than helpful due to the overhead of multiple VMs.