SVN,TeamCity虚拟化/硬件要求

我正在尝试将一个需求放在一起构成一个新的环境,包括TeamCity运行的Sql Server,一些构建代理(现在)和一个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个小时才能运行,而且我们不想保留构建队列.我们已经分阶段发布 - 理想情况下,一个项目在通过自动化单元和系统测试之前不会发布给测试部门.

我们有十几个开发人员一次积极地处理3个或4个项目.我们还使用TeamCity来构建修补程序和维护版本.

在您的方案中,我选择Windows 2008和HyperV,在您有预算的最大的盒子上.磁盘I/O比CPU功率更重要,但是通过更多内核,您可以更轻松地扩展到更多虚拟机.分配给每个VM的大量RAM可避免交换,并有助于缓存,这意味着更少的磁盘I/O. 在某个时刻,您可能会考虑使用两个或更多的盒子进行故障转移,并且因为购买两个带有32Gb RAM的盒子比购买一个盒子的64Gb选项有时更便宜.

使用VM的一个优点是您可以对它们进行快照并定期还原它们.每个项目应该有自己的SQL Server实例.