Точка данных:
Наша среда TeamCity включает (если я правильно помню) трио 8-ядерных серверов, каждый из которых имеет 32 ГБ ОЗУ, работает под управлением Windows 2008 и HyperV. Наш SVN-репозиторий находится на другом сервере (по историческим причинам). Я думаю, что теперь все в сети SAN для надежности (если один из хостов выйдет из строя, мы можем легко переместить виртуальные машины на другой хост).
У нас есть 10 агентов сборки, все работают в виртуальных машинах. 4 из них используются для прямых сборок; 6 из них используются для сборки и запуска системных тестов (что включает в себя координацию других виртуальных машин в тестах). Мы выбрали это, потому что некоторые из наших системных тестов занимают 11 часов, и мы не хотим задерживать очередь сборки. У нас поэтапные релизы - проект в идеале не поступает в отдел тестирования до тех пор, пока он не пройдет автоматизированное модульное и системное тестирование.
У нас около дюжины разработчиков, активно работающих над 3 или 4 проектами одновременно. Мы также используем TeamCity для создания исправлений и выпусков обновлений.
В вашем сценарии я бы выбрал Windows 2008 и HyperV, на самой большой коробке, на которую у вас есть бюджет. Дисковый ввод-вывод важнее, чем мощность процессора, но с большим количеством ядер вы можете легко масштабировать до большего количества виртуальных машин. Большое количество оперативной памяти, выделенной для каждой виртуальной машины, предотвращает перестановку и помогает кэшировать, что означает меньшее количество дисковых операций ввода-вывода. В определенный момент вы можете рассмотреть возможность использования двух или более блоков для восстановления после сбоя, и потому что иногда дешевле купить два блока с 32 ГБ ОЗУ, чем вариант 64 ГБ для одного блока.
Одним из преимуществ использования виртуальных машин является то, что вы можете снимать их и периодически возвращать. Каждый проект, вероятно, должен иметь свой собственный экземпляр SQL Server.