Have Geek Brain

Continuous Integration Server Installation: From Developer to Production

We are currently rebuilding our server environment - from development to production. All servers will be Windows 2008 servers running as virtual machines. We will be using TeamCity for continuous integration and SubVersion as our source control.

After reading some guidelines, here's what I'm planning so far (not including redundancy, disaster recovery, etc.):

  • Products: (1) Web Server + (1) Database Server
  • Stage: (1) Web server + (1) Database 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:

  • Does SVN have to be on a dedicated server or can it run on a Dev server?

    Answer: Competition so far it seems that SVN should not be on the Dev server. It must either be standalone or can be paired on the same server as TeamCity.

  • Should TeamCity be on a dedicated server or can it live on an SVN server?

    Answer: . The consensus so far is that TeamCity can be on the same server as SVN, especially if the TeamCity and SQL DB agents are on different servers.

  • Any other recommendations, recommendations?

    Answer: TeamCity should be split into three server instances: one for TeamCity Web, one for TeamCity agents, and one for SQL Server TeamCity.

I am trying to have a solid best practice setup and minimize server sprawl.

+1


a source to share


2 answers


I just installed TeamCity using SQL Server DB and an instance of our webapp running on Tomcat on the same Windows VM.

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

JetBrains mentions that Build agents should not run on the same server as the web server, optimally. I would suggest also partitioning the database (into a physical field, not just a virtual machine) so that the CI installation itself uses 3 systems (TeamCity web server, TeamCity database, TeamCity build agent). If your builds are taking more than a few minutes, I'll add another build agent server to keep developers from queuing up to commit, especially if you're using TeamCity's remote run / personal build feature from IDEA or Eclipse.



I would have no problem installing the SVN server on the same system as the TeamCity web server.

Keep in mind that compilation is an activity that is usually CPU bound or limited to disk access. Build activators will benefit from splitting into separate processors and / or disks. However, having separate virtual machines that share disks and processors can be more useless than beneficial due to the overhead of multiple virtual machines.

+1


a source


To answer your questions:



  • I would put SVN on a different server on the dev server. Often all sorts of garbage is installed on dev servers.
  • TeamCity can be on the same server as the SVN server. (Call it build server)
  • You don't have resilience built into your production system.
    I would suggest having at least two servers, another web server and a hot standby DB server that is mirrored from your Live DB server.
    They do not have to be in the same datacenter as the rest of the servers and must use alternative gateways on the Internet.
+2


a source






More articles:


All Articles