我试图将一个新环境的要求放在一起，以包含运行 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 上，为了可靠性(如果其中一台主机出现故障，我们可以轻松地将 VM 移动到另一台主机上)。
我们有 10 个构建代理，都在 VM 中运行。其中 4 个用于直线构建；其中 6 个用于构建和运行系统测试(这涉及在测试中协调其他 VM)。我们选择这个是因为我们的一些系统测试需要 11 个小时才能运行，而且我们不想拖延构建队列。我们已经分阶段发布——理想情况下，项目在通过自动化单元和系统测试之前不会发布到测试部门。
我们有大约 12 名开发人员同时积极从事 3 或 4 个项目。我们还使用 TeamCity 来构建修补程序和维护版本。
在您的方案中，我会选择 Windows 2008 和 HyperV，在您有预算的最大机器上。磁盘 I/O 比 CPU 能力更重要，但拥有更多内核，您可以更轻松地扩展到更多 VM。分配给每个 VM 的大量 RAM 避免了交换，并有助于缓存，这意味着更少的磁盘 I/O。在某个时候，您可能会考虑使用两个或更多的盒子来进行故障转移，因为有时购买两个具有 32Gb 内存的盒子比购买单个盒子的 64Gb 选项更便宜。
使用 VM 的优势之一是您可以对它们进行快照并定期恢复它们。每个项目可能都应该有自己的 SQL Server 实例。
关于SVN、TeamCity 虚拟化/硬件要求，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/402633/