当前位置: 动力学知识库 > 问答 > 编程问答 >

deployment - Continuous Integration Server Setup: From Dev to Production

问题描述:

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.

网友答案:

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.

网友答案:

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.
分享给朋友:
您可能感兴趣的文章:
随机阅读: