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

Question

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

在阅读了一些建议之后，下面是我到目前为止计划要做的事情(不包括任何冗余、灾难恢复等)：

• Production: (1) Web服务器+ (1) DB Server
• Staging: (1) Web服务器+ (1) DB Server
• Build: (1) SVN + TeamCity Web&DB + (1) TeamCity Agent
• Development: (1) Web/DB Server

因此，总共有2个生产+2阶段+ 2-3构建+1 Dev = 7-8服务器

我的问题是：

1. Should SVN位于专用服务器上，还是可以驻留在Dev服务器上？回答:到目前为止，仍然认为SVN 不应该在Dev服务器上。它应该是独立的，或者可以与TeamCity.

在同一台服务器上配对。

1. Should TeamCity位于专用服务器上，还是可以在SVN服务器上运行？

回答:到目前为止，TeamCity可能与SVN位于同一台服务器上，特别是如果TeamCity代理和SQL DB位于单独的服务器上。

1. Any其他建议，最佳实践？

回答： TeamCity应该分为三个服务器实例:一个用于TeamCity Web，一个用于TeamCity代理，另一个用于TeamCity SQL DB.。

我试图有一个坚实的最佳实践设置，同时尽量减少服务器蔓延。

Answer 1

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

• TeamCity web服务器运行于Tomcat本身，并使用大量内存(就像任何Tomcat应用程序一样)。
• TeamCity构建代理程序编译后使用大量内存。
• server是内存占优势。

。

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

如果将SVN服务器放在与TeamCity web服务器相同的系统上，我就不会有问题了。

请记住，编译是一个通常是CPU绑定或磁盘访问绑定的活动。将构建代理分离到单独的CPU和/或磁盘中将受益。但是，由于多个VM的开销，处于共享磁盘和CPU的单独VM上可能会更浪费而不是更有帮助。