Это общая проблема (и я хотел бы прочитать ее раньше) для всех разработок, а не только для ASP.NET. Будучи одним из ее разработчиков, моя команда естественным образом использует BuildMaster для всего процесса выпуска, и для большинства сценариев это бесплатно. В рамках этого инструмента мы можем выполнить все стандартные сборки CI для создания артефактов, а затем настроить процесс автоматизации для развертывания этих артефактов на любом из 40+ серверов, которые мы размещаем внутри или снаружи, в зависимости от конкретного приложения или среды. .
Поскольку вы специально упомянули развертывание в различных средах тестирования, это фундаментальный аспект инструмента. Идея состоит в том, чтобы смоделировать рабочий процесс среды (например, Интеграция -> QA -> Производство), который у вас уже есть, и по существу продвигать сборку на всем пути от контроля версий до производства. В большинстве случаев это так же просто, как добавить действие развертывания, которое развертывает артефакт в среде, в других случаях это может быть намного сложнее.
Вы также случайно упомянули, что изменения файла конфигурации являются частью развертывания, которое является еще одним встроенным компонентом BuildMaster. Идея заключалась в том, чтобы использовать сам инструмент в качестве центрального концентратора для всех файлов конфигурации и развертываний, обеспечивая тем самым автоматическое применение последних изменений с помощью простого действия «развернуть файлы конфигурации» в вашем плане развертывания.
Одна вещь, которую вы не упомянули в связи с этим процессом, - это аспект развертывания базы данных. Большинству приложений ASP.NET требуется связанная база данных, в противном случае они могут быть просто статическими файлами HTML. Крайне важно, чтобы схема базы данных обновлялась до соответствующей версии базы данных при каждом развертывании. Неудивительно, что в BuildMaster есть модуль, который обрабатывает это и для вас. Идея состоит в том, чтобы хранить сценарии DDL-DML в самом инструменте, и, выполняя сценарии только один раз для среды, это гарантирует, что все ваши базы данных в каждой среде будут обновлены по мере развертывания ваших сборок. через них. Другие сценарии (например, хранимые процедуры, представления, триггеры и т. Д.) По сути являются файлами кода и, следовательно, относятся к управлению исходным кодом. Эти сценарии типа DROP-CREATE-CONFIGURE можно запускать каждый раз в большинстве случаев с помощью простого действия развертывания.
Другая часть головоломки развертывания, о которой большинство разработчиков не задумываются, - это автоматизация процессов. Многим разработчикам необходимо выполнить подписание или заполнить формы запроса на изменение, чтобы вручную выполнить эти процессы. Опять же, все это доступно как часть автоматической настройки рабочего процесса в BuildMaster. Вы можете настроить блокировщики, которые не позволяют продвижению сказать среду QA, если не пройдены все модульные тесты, или заблокировать продвижение в промежуточную среду, если кто-то из команды QA не утвердит сборку, и все проблемы в вашем инструменте отслеживания проблем не будут решены / закрыты для этот конкретный выпуск.
Хотя я понимаю, что исключил из ответа CC.NET, все наши приложения построены и развернуты через BuildMaster, поэтому мы больше не нуждаемся в них, хотя мы могли бы, однако, так же легко забрать артефакты из места размещения и развернуть их в более поздние среды.