Автоматическое развертывание на многих серверах с различными настройками app.config?

Question

Я знаю, что есть много вопросов, подобных этому, на SO, но я пока не нашел хорошего решения.Лучшие решения, которые я видел, являются доморощенными, но прежде чем приступить к реализации специального инструмента, я хотел бы услышать ваше мнение.Итак, начнем:

У меня есть решение .NET с парой веб-приложений и несколькими службами Windows.Я хочу автоматизировать развертывание этих приложений, скажем, на 10-20 различных серверах, но файлы app / web.config на каждом сервере могут иметь разные значения.

Microsoft ответит на этот вопросиметь 10-20 различных файлов web.config локально на компьютере разработчика, а затем с помощью диспетчера конфигурации выбрать правильный.Но этого недостаточно, потому что разработчики не знают ни о настройках рабочего сервера, ни о них!

Идеальным решением было бы включение какой-либо "модели развертывания"где определены рабочие серверы и их настройки, и которые можно использовать с некоторым сценарием развертывания (может быть Powershell) в качестве шага на сервере сборки (я использую TeamCity).Это можно сделать, заменив параметры конфигурации перед XCopying решения на удаленном сервере.Но это утомительная и трудоемкая задача.

Другим решением может быть использование «configSource» для указания на папку с фиксированным именем, но проблема здесь в том, что некоторые части файлов конфигурации (например, serviceModel)) нельзя использовать с configSource.

Так что я не нашел лучшего ответа на этот вопрос.Есть идеи?

Answer 1

Часть нашей модели развертывания (также централизованная сборка TeamCity, предназначенная для множества различных серверов) заключалась в автоматическом создании сценариев развертывания как части файла MSBUILD и базировании развертывания на развертывании MSDEPLOY / web 2.0.

При сборке автоматически создается кандидат на сборку, подходящий для развертывания с помощью MSDEPLOY, а также запускается скриптлет powershell / cmd, который выбирает соответствующий файл конфигурации и копирует его на место.

Развертывание на всех серверах становится просто случаем объединения этих отдельных сценариев развертывания (т. Е. С помощью пакетного файла). Поскольку MSDEPLOY отправляет только изменения файла, это обычно довольно быстро и может использоваться для создания резервных копий, а также для развертывания, поэтому как часть сценария развертывания он будет:

1. Сделайте резервную копию соответствующего сервера (например, Web1) и прикрепите его к сетевому ресурсу
2. Разверните соответствующий пакет на сервере (Web1), преобразовав при необходимости любые файлы (например, Web.Web1.Config -> Web.config)
3. Пишите любые необходимые журналы

В процессе сборки также появляется сценарий отмены, который восстанавливает соответствующий сервер в резервную копию.

Больше о MSDEPLOY здесь . Может также использоваться с базами данных и т. Д.

Просто предложение, это может быть полезно:)

Answer 2

Я использую XmlPreprocess tool для манипулирования файлами конфигурации.Он использует один файл сопоставления для нескольких сред / серверов.Вы можете редактировать файл сопоставления в Excel.Он очень прост в использовании.Вызовите XmlPreprocess в своих пользовательских сценариях PS и передайте имя сервера в качестве параметра среды.

Answer 3

[Откровенный пост поставщика] Мы используем именно такую ​​модель развертывания в нашем продукте uDeploy .

Основная идея состоит в том, что вы определяете единый процесс развертывания, который включает в себя этапы обновления файлов конфигурации (app.config и web.config являются наиболее нормальными для приложений ASP). Эти отклонения могут быть для каждого сервера или логической среды (dev test, qa, stage, prod ...). Кроме того, вы можете поместить файл шаблона app.config непосредственно в uDeploy, и мы выпишем его во время развертывания.

Инструмент интегрируется с TeamCity для извлечения сборок, а также IIS для развертывания и настройки пулов приложений и серверов. Он также предназначен для отслеживания того, как несколько сервисов и веб-приложений, которые могут быть разными сборками TeamCity, объединяются в виде набора релизов.

На первый взгляд, это может звучать так, как будто мы прилично подходим. Не стесняйтесь обращаться ко мне напрямую по eric@urbancode.com. Ура! [/ явная почта продавца]