1

我们正在重新配置我们的服务器环境，从开发到生产。所有服务器都将是作为 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。

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

4

2 回答 2

2

要回答您的问题：

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

我刚刚使用 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 上可能浪费多于帮助。

于 2009-05-15T15:52:06.187 回答