Сборка один раз и развертывание в нескольких средах с помощью msdeploy & Visual Studio 2012

Ответ 1

Мы используем опцию №1, и она работает достаточно хорошо. Используя этот подход, мы развертываем примерно до 30-40 сайтов и приложений.

Я думаю, что вариант №2 вызовет головные боли для вас или разработчиков. Вам также необходимо убедиться, что разделы с настройками удалены из конфигурации при развертывании или заблокированы на сервере, чтобы локальная конфигурация не могла их добавить.

Для параметра № 3 вам нужно будет сделать несколько сборок, чтобы получить преобразованные файлы конфигурации. Это также не очень удобно, если у вас есть большое количество сайтов для развертывания.

Вариант № 4 может работать, но здесь вы можете столкнуться с ограничениями. Это либо весь раздел находится в отдельном файле, либо все в главном файле, поэтому между ними нет.

Вариант № 5 выглядит интересным, но я не использовал его, поэтому я не могу много говорить об этом.

Ответ 2

Я могу немного рассказать о вариантах # 1/# 3 и сравнить их. В предыдущем ответе было неточно утверждать, что вам нужно несколько раз создавать пакеты с PackageWeb, вам нужно только создать один раз.

Вариант 1: Parameters.xml и SetParameters.xml

В этом подходе вы создадите файл parameters.xml в своем веб-проекте, который будет объявлять дополнительные параметры веб-развертывания.

При создании пакета Web Deploy в пакете создаются параметры, объявленные в параметрах .xml. Когда этот веб-пакет развертывания будет создан, файл web.config будет преобразован на основе конфигурации сборки (и теперь, возможно, и профильного преобразования).

Вы можете использовать этот пакет и setparameters.xml для публикации пакета с указанием значений параметра Web Deploy. Вы можете создавать различные файлы setparameters.xml и использовать их вместе с одним и тем же пакетом для публикации в нескольких местах назначения. Чтобы опубликовать эту технику, вы можете использовать либо deploy.cmd, который VS генерирует, либо вызывает msdeploy.exe с правильным набором параметров.

Вариант 3: ПакетWeb

PackageWeb расширяет пакетный процесс, так что при создании пакета Web Deploy в пакет включаются преобразования web.config, а также сборка, которая может выполнять преобразования.

В дополнение к этому при создании веб-развертывания создается файл publish-interactive.ps1. Вы можете использовать этот файл для публикации своего пакета. Он вам подскажет; используемое преобразование web.config, значения параметров развертывания веб-страниц и сама информация о конечной точке развертывания. Когда вы запускаете публикацию, значения, которые вы указали, сохраняются в publish-configuration.ps1.readme. Вы можете удалить .readme и publish-interactive.ps1 будет использовать значения из этого файла для автоматизации публикации. Вы также можете указать файл, который будет использоваться для настроек.

Если вы создали файл parameters.xml при создании веб-пакета развертывания VS, это приведет к включению в пакет параметров развертывания. PackageWeb выберет их и предложит вам также.

Итак, каковы различия между этими подходами?

С Вариантом № 1 web.config, который попадает в пакет, уже преобразован. У вас не будет возможности снова преобразовать файл. В обоих подходах вы можете указать значения параметров развертывания веб-сайтов, хотя это может удовлетворить ваши потребности. Если вы изменяете большие куски XML от одного env к другому, то преобразования web.config могут быть полезными. Поэтому PackageWeb может быть лучшим выбором.

С помощью опции №1 вам необходимо вручную создать файл SetParameters.xml. С PackageWeb вы можете запустить процесс, используя параметр WhatIf. Вам будут предложены значения, и он создаст для вас файл настроек.

Вы можете легко автоматизировать оба подхода. PackageWeb по существу основывается на методе parameters.xml/setparameters.xml и предлагает супер-набор функций.

Если вы хотите максимально упростить работу с наименьшим числом движущихся частей, я бы рекомендовал вариант №1, потому что вы можете напрямую вызвать msdeploy.exe, если это необходимо.

Если вы хотите упростить автоматизацию публикации, и вы предпочитаете PowerShell в стандартной командной строке, попробуйте PackageWeb.

У меня есть 5-минутное видео на PackageWeb по адресу http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx. Если вы публикуете пакеты веб-развертывания, я призываю вас, ребята, попробовать. Если это не соответствует вашим потребностям, пожалуйста, дайте мне знать, потому что мы можем использовать то, что мы узнаем в PackageWeb позже более формальным образом.

Ответ 3

Мы используем # 5, и он работает очень хорошо. Использование MSBuild для публикации профилей обеспечивает кучу гибкости (элементы особенно полезны).

В нашем конвейере развертывания к этапам развертывания становятся доступны только пакеты веб-сайтов, цели сборки/размещения и публикации профилей. Исходный код, включая файлы проекта, используется только на этапе сборки/тестирования.

FYI, мы пошли с публикацией профилей специально, так как вы быстро столкнетесь с проблемой сохранения специфических для сервера сведений о сервере/учетных данных, пропущенных предложений и значений параметров вместе. WPP/Публикация профилей отслеживает все эти вещи в файле pubxml, а функции MSBuild позволяют использовать некоторые "помощники" для общих, но "шумных" задач.

Ответ 4

Я решил решить эту проблему с помощью комбинации msbuild, запущенной на TeamCity, для создания пакетов NuGet, которые могут быть использованы OctopusDeploy.

Octopus позволяет использовать приложение, упакованное в пакет nuget (встроенный один раз), чтобы быть нажатым в нескольких средах. Конфигурация может быть преобразована для каждой среды или даже для каждой машины с использованием стандартных преобразований ms. Ссылки на соответствующие документы Octopus ниже.

Упаковка для Octopus

Настройка конфигурационных преобразований