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

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

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

• 生产：（1）Web服务器+（1）DB服务器
• 暂存：（1）Web服务器+（1）DB服务器
• 构建：（1）SVN+TeamCity网站和DB+（1）TeamCity代理
• 开发：（1）Web/DB服务器

因此，总共有2台生产服务器+2台暂存服务器+2-3台构建服务器+1台开发服务器=7-8台服务器

我的问题是：

SVN应该位于专用服务器上，还是可以位于开发服务器上？ 回答：目前的共识似乎是SVN不应该在Dev服务器上。它应该是独立的，或者可以与TeamCity在同一台服务器上配对

TeamCity应该位于专用服务器上，还是可以位于SVN服务器上？

答案：目前的共识是TeamCity可能与SVN位于同一台服务器上，特别是如果TeamCity代理和SQL DB位于不同的服务器上

还有其他建议、最佳做法吗？

回答：TeamCity应分为3个服务器实例：一个用于TeamCity Web，一个用于TeamCity代理，一个用于TeamCity SQL DB

---

我正在尝试建立一个可靠的最佳实践设置，同时最大限度地减少服务器扩展。

要回答您的问题：

• 我会将SVN放在与dev服务器不同的服务器上。 dev服务器上经常安装各种垃圾
• TeamCity可以与SVN服务器位于同一台服务器上。（将其称为构建服务器）
• 您的生产系统没有任何弹性。
  我建议至少增加两台服务器，另一台web服务器和一台热备用DB服务器，该服务器从live DB服务器镜像。
  这些服务器不应与其他服务器位于同一数据中心，而应使用通向internet的其他网关

---

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

• TeamCity web服务器在上运行 Tomcat本身，并且使用了大量 内存不足（就像任何Tomcat应用程序一样）
• TeamCity构建代理，因为他们 编译，使用大量内存
• SQL Server是一个内存占用者

JetBrains提到构建代理不应该与web服务器在同一台服务器上运行。我建议将数据库也分开（放在一个物理框上，而不仅仅是一个VM上），这样CI设置本身就使用3个系统（TeamCity web服务器、TeamCity数据库、TeamCity构建代理）。如果构建时间超过几分钟，我会添加另一个构建代理服务器，这样开发人员就不会在提交时排队，特别是如果您使用的是来自IDEA或Eclipse的TeamCity远程运行/个人构建功能

将SVN服务器与TeamCity web服务器放在同一个系统上不会有问题

---

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

关于故障切换的优点。目前，我们在VMWare环境中运行，依靠VMWare的高可用性功能，如VMotion等。。。然而，如果整个数据中心崩溃，我们就完蛋了。但这将是我们服务器重新配置项目的第2阶段。所以我想问题是，TeamCity是否可以/应该使用现有的SQL服务器作为其数据库？（即：开发服务器或暂存数据库服务器）。仅为TeamCity DB提供一台separte服务器似乎是一种耻辱。它可能不需要这样做。但是，例如，拥有dev数据库服务器是否会同时承担TeamCity数据库的双重职责，从而引发问题？当dev运行缓慢时，您是否必须决定是否应归咎于TeamCity？我的猜测是否定的，尤其是在一个开发实例上，但您必须为自己的项目做出决定，权衡减少一台服务器的便利性和潜在的资源争用。说SQL server是内存占用者是错误的，但它确实倾向于消耗所有可用内存。如果对它的内存分配设置了限制，那么它通常会愉快地生活在这个范围内。根据对服务器的要求，这一限制实际上可能相当低，我已经看到限制在70Mb的SQL实例非常愉快地运行，并完成了它们设计的任务。不受限制的SQL server只会使用meory，直到其他应用程序尝试分配它，这时它就会产生内存。吹毛求疵：“并将SubVersion用于我们的SVN存储库”-SVN是SubVersion的缩写。。“为我们的SCM使用subversion”更有意义..将SVN更改为修订控制系统。：）