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

Question

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

在阅读了一些建议之后，这是我目前计划采取的措施（不包括任何冗余、灾难恢复等...）：

• 生产： (1) Web 服务器 + (1) DB 服务器
• 暂存： (1) Web 服务器 + (1) DB 服务器
• 构建： (1) SVN + TeamCity Web&DB + (1) TeamCity 代理
• 开发： (1) Web/DB 服务器

所以总共 2 个生产 + 2 个暂存 + 2-3 个构建 + 1 个开发 = 7-8 个服务器

我的问题是：

1. SVN 应该放在专用服务器上，还是可以放在开发服务器上？

   答案：到目前为止，似乎一致认为 SVN 不应该在开发服务器上。它应该是独立的，或者可以与 TeamCity 在同一台服务器上配对。

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

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

3. 还有其他建议和最佳做法吗？

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

我正在尝试进行可靠的最佳实践设置，同时尽量减少服务器蔓延。

Answer 1

回答您的问题：

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

Answer 2

我刚刚使用 SQL Server DB 和我们在 Tomcat 上运行的 webapp 实例设置了 TeamCity，所有这些都在同一个 Windows VM 上。

• TeamCity Web 服务器在 Tomcat本身，并使用了很多 内存（与任何 Tomcat 应用程序一样）。
• TeamCity Build 代理，因为他们 编译，使用大量内存。
• SQL Server 是内存大户。

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

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

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