R – Continuous Integration Server Setup: From Dev to Production

continuous integrationdeploymentinstallationteamcity

We are in the process of re-configuring our server environment, from Development to Production. All servers will be Windows 2008 servers running as VM's. We will be using TeamCity for Continuous Integration and SubVersion as our Version Control System.

After reading some of the recommendations, here is what I am planning on going with so far (not including any redundancy, disaster recovery, etc…):

  • Production: (1) Web Server + (1) DB Server
  • Staging: (1) Web Server + (1) DB Server
  • Build: (1) SVN + TeamCity Web&DB + (1) TeamCity Agent
  • Development: (1) Web/DB Server

So a total of 2 Production + 2 Staging + 2-3 Build + 1 Dev = 7-8 Servers

My questions were:

  1. Should SVN be on a dedicated Server, or can it live on the Dev server?

    Answer: Concensus so far seems to be that SVN should not be on the Dev server. It should either be standalone, or could be paired up on the same server as TeamCity.

  2. Should TeamCity be on a dedicated Server, or can it live on the SVN server?

    Answer: Concensus so far is that TeamCity could be on the same server as SVN, particularly if the TeamCity Agents and SQL DB are on separate servers.

  3. Any other recommendations, best practices?

    Answer: TeamCity should be split up across 3 server instances: One for TeamCity Web, one for TeamCity Agents, and one for the TeamCity SQL DB.

I'm trying to have a solid best-practice setup while minimize server sprawl.

Best Answer

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.

Related Topic