Subversion，TeamCity和开发服务器的服务器体系结构

Question

我为一家较新的.Net CMS网络开发公司工作，我们现在正在制定一个版本控制策略。我们目前正倾向于将subversion作为TeamCity的版本控制系统，以保持我们的dev服务器更新（并将我们的构建控制到QA和生产）。

我正在尝试找到为此类设置建议的架构类型。我们应该为每个服务器分别设那么TeamCity Server和构建代理呢？在我看来，最好的方法是设置一个服务器来运行subversion，一个运行TeamCity Server，另一个运行TeamCity Build Agent。但是，我们希望避免为此运行三个单独的服务器。

任何人都可以告诉我他们以前使用过什么，效果如何？你有什么建议和原因？

更新：我们需要支持大约10位开发人员。我们现在处于这种状态之下，但预计明年会雇用一对/几人。

更新：还有一个问题。根据我们采用的开发人员数量，通过阅读文档，我们似乎不需要超过与专业服务许可一起提供的三个Build Agent。如果我们有更多的开发人员，这似乎需要增加，但不一定是活跃项目的数量。这准确吗？

Answer 1

这取决于您团队的规模。我的公司有12名开发人员。

• 我们有一个TeamCity Web服务器，它也是一个构建代理。
• TeamCity数据库位于我们已有的另一台SQL Server上。
• Subversion在我们已经拥有的另一台服务器上。
• 我们使用两台开发者机器作为第二和第三个构建代理。

但是对于一个小团队，你可能会将它们全部放在一个相当强大的服务器上。你必须看看什么对你有用。

Answer 2

我们有

• 一台承载TeamCity并充当构建代理的服务器
• 一个用于sql server存储的服务器。 TeamCity数据库不是那里唯一的数据库。
• 另外两个构建代理的服务器。

我们为多个团队建立了许多项目。

最初，一个团队中只有少数开发人员。我们很好，有一台服务器充当TeamCity服务器，TeamCity代理和数据库服务器。

除非您想一次构建多个项目，或者您的构建时间很长，否则您不需要多个代理。我们发现开发人员的数量并不是直接因素。并发运行的构建数量更为重要。这可能与开发人员的数量有关，但不是我们的情况。我们的构建时间很短（3分钟），我们一次限制为每个项目一个构建。