我正在尝试将一个新环境的要求放在一起，该环境由运行 Sql Server 的 TeamCity、几个构建代理（目前）和一个 SVN 存储库组成。
有 6 名开发人员，目前将有 5 个活跃的解决方案参与 CI 流程，显然会随着时间的推移而增长。目前没有一个解决方案需要超过 10 分钟的时间来构建，因此它们在复杂性和位置方面并不是很大。
构建项目本身需要一个 sql server 实例，以便可以运行自动化测试 - 我假设它们应该与 TeamCity sql 实例分开。
任何人都可以建议适合运行这些的硬件配置。磁盘 i/o 是否会比实际的 CPU 能力更重要。
我可以在单个多 CPU、RAID 和虚拟化上运行所有这些吗？
我们应该使用 windows 2008 和 hyper-v 运行吗？
我总是让其他人处理服务器要求和构建，但现在我必须弄脏自己的脚。
欢迎任何建议
一个数据点：
我们的 TeamCity 环境位于（如果我没记错的话）三台 8 核服务器上，每台服务器都有 32Gb 的 RAM，运行 Windows 2008 和 HyperV。我们的 SVN 存储库位于不同的服务器上（出于历史原因）。我认为现在一切都在 SAN 上，以提高可靠性（如果其中一台主机出现故障，我们可以轻松地将虚拟机移动到另一台主机）。
我们有 10 个构建代理，都在虚拟机中运行。其中 4 个用于直接构建；其中 6 个用于构建和运行系统测试（这涉及在测试中协调其他 VM）。我们之所以选择这个，是因为我们的一些系统测试需要 11 个小时才能运行，而且我们不想耽误构建队列。我们分阶段发布——理想情况下，项目在通过自动化单元和系统测试之前不会发布给测试部门。
我们有大约十几个开发人员一次积极地从事 3 或 4 个项目。我们还使用 TeamCity 构建修补程序和维护版本。
在您的方案中，我会在您有预算的最大机器上选择 Windows 2008 和 HyperV。磁盘 I/O 比 CPU 能力更重要，但使用更多内核，您可以更轻松地扩展到更多 VM。分配给每个 VM 的大量 RAM 避免了交换，并有助于缓存，这意味着更少的磁盘 I/O。在某个时候，您可能会考虑拥有两个或更多的盒子以进行故障转移，因为有时购买两个具有 32Gb RAM 的盒子比购买单个盒子的 64Gb 选项更便宜。
使用 VM 的优点之一是您可以对它们进行快照并定期恢复它们。每个项目可能都应该有自己的 SQL Server 实例。
您应该查看我们文档中的 How to 部分： http: //confluence.jetbrains.net/display/TCD65/How+To ... 在那里您将找到“估计 TeamCity 的硬件要求”主题。可能会有所帮助。
上一篇文章中的链接已损坏以下是正确的链接。 http://confluence.jetbrains.com/display/TCD65/How+To...#HowTo...-hardwarerequirements