持续集成服务器设置：从开发到生产

Question

我们正在重新配置从开发到生产的服务器环境。所有服务器都是作为VM运行的Windows 2008服务器。我们将使用TeamCity进行持续集成和SubVersion作为我们的版本控制系统。

在阅读了一些建议之后，这是我计划到目前为止所做的事情（不包括任何冗余，灾难恢复等等）：

• 制作：（1）Web服务器+（1）数据库服务器
• 暂存：（1）Web服务器+（1）数据库服务器
• 构建：（1）SVN + TeamCity Web＆amp; DB +（1）TeamCity Agent
• 开发：（1）Web / DB服务器

总共2个生产+ 2个阶段+ 2-3个构建+ 1个开发= 7-8个服务器

我的问题是：

1. SVN应该在专用服务器上，还是可以在Dev服务器上运行？

     

   答案：到目前为止，共识似乎是SV​​N 不应该在Dev服务器上。它应该是独立的，或者可以在与TeamCity相同的服务器上配对。

2. TeamCity应该在专用服务器上，还是可以在SVN服务器上运行？

     

   答案：目前的一致意见是TeamCity 可以与SVN位于同一服务器上，特别是如果TeamCity Agents和SQL DB位于不同的服务器上。

3. 任何其他建议，最佳做法？

     

   答案： TeamCity应分为3个服务器实例：一个用于TeamCity Web，一个用于TeamCity Agent，另一个用于TeamCity SQL DB。

我正在努力实现可靠的最佳实践设置，同时最大限度地减少服务器蔓延。

Answer 1

回答你的问题：

• 我会将SVN放在与开发服务器不同的服务器上。 通常在开发服务器上安装各种垃圾。
• TeamCity可以与SVN服务器在同一台服务器上。 （称之为构建服务器）
• 您的生产系统中没有任何弹性 我建议至少再安装两台服务器，另一台Web服务器和一台备用数据库服务器，它是从您的实时数据库服务器镜像的。
  这些数据中心不应与其他服务器位于同一数据中心，并应使用其他网关连接到互联网。

Answer 2

我刚刚在同一个Windows VM上使用SQL Server DB和Tomcat上运行的webapp实例设置了TeamCity。

• TeamCity Web服务器运行 Tomcat本身，并使用了很多优惠 内存（就像任何Tomcat应用程序一样）。
• TeamCity Build代理商，因为他们 编译，使用大量内存。
• SQL Server是一种记忆困境。

JetBrains提到Build代理不应该与Web服务器在最佳运行在同一台服务器上。我建议将数据库分开（放在物理盒上，而不仅仅是VM上），这样CI设置本身就会使用3个系统（TeamCity Web服务器，TeamCity数据库，TeamCity构建代理）。如果您的构建需要花费几分钟的时间，那么我将添加另一个构建代理服务器，以便开发人员不会在提交时排队，特别是如果您正在使用TeamCity的IDEA或Eclipse远程运行/个人构建功能。

将SVN服务器放在与TeamCity Web服务器相同的系统上我不会有问题。

请记住，编译是一种通常受CPU限制或磁盘访问限制的活动。构建代理将受益于分离到单独的CPU和/或磁盘上。但是，由于多个VM的开销，位于共享磁盘和CPU的单独VM上可能比有用的更浪费。