Способ лучший ? Это то, с чем ваша команда чувствует себя наиболее комфортно в вашей конкретной среде развертывания. Точно так же, как отсутствует инфраструктура развертывания «отраслевого стандарта», развертывание «отраслевого стандарта» отсутствует.
Только для конфигурации я видел команды
использовать пользовательский пакетный файл, запускаемый на сервере, для извлечения кода из общего сетевого ресурса, а затем поиска и замены токенов в файлах конфигурации
использовать скрипт Powershell для извлечения кода из репозитория Nexus, поиска и замены токенов, а затем с помощью PSExec вызвать другой сценарий Powershell на сервере для извлечения токенизированного кода
создание пользовательских сценариев Nant, которые заменяют файлы конфигурации, на которые есть ссылки в web.config, а затем копируют на хост
копировать и настраивать файлы конфигурации вручную
Все они имели свои особые преимущества в своей ситуации: например, система, в которой имелись файлы конфигурации, свернутые вручную, имела простой и часто используемый внутренний сайт, который развертывался всего пару раз в год. Это действительно не стоило строить сложное, автоматизированное развертывание.
Поэтому я бы посоветовал вам внимательно взглянуть на то, что на самом деле вам и вашей команде нужно, сколько у вас есть времени и сколько вы можете себе позволить автоматизации.
Полезные инструменты в арсенале:
Преобразование веб-конфигурации , которое может преобразовывать файлы web.config в зависимости от используемой конфигурации сборки. Ссылка на MSDN здесь: http://msdn.microsoft.com/en-us/library/dd465326.aspx - они относительно новые и хорошо работают, как только вы разберетесь с синтаксисом.
Windows Powershell , потрясающий язык сценариев, который динамичен, но имеет все .NET под обложками.
MSBuild, чего нельзя избежать в системах Microsoft
Мое личное предпочтение - создать немного больше средств автоматизации, которые, по вашему мнению, вам изначально нужны, особенно для новых систем, которые требуют частых развертываний для устранения проблем.