Выполнение преобразования XML в существующем веб-приложении Azure

У меня есть существующее веб-приложение, развернутое в Azure. Это «ванильный» выпуск, в который я затем хочу добавить индивидуальные настройки клиента с помощью дополнительных изменений dll и конфигурации.

Я пытался использовать шаг «Развернуть веб-приложение Azure» в Octopus Deploy, чтобы вытолкнуть эти дополнительные DLL и изменения конфигурации через файл преобразования XML, однако он, похоже, не работает, поскольку шаг преобразования выполняется на Octopus сервер, а не в Azure, где находится файл web.config.

Я также посмотрел на шаг PostDeploy, но, похоже, возникла та же проблема.

Возможно ли это с помощью Octopus Deploy или чего-то еще, например сценария Powershell, использующего Azure API? Или, возможно, загрузить файл web.confg из Azure, выполнить преобразование и повторно загрузить его?


xml azure-web-app-service powershell octopus-deploy transform
person Iain Ward    schedule 10.12.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Источником истины для вашего приложения, включая код и конфигурацию, является не та версия, которую вы используете в экземпляре Azure.

Отправка новой версии кода или конфигурации должна происходить из локального пакета, независимо от того, создается ли он вручную или с помощью процесса сборки (TeamCity, VSTS, Jenkins и т. Д.). Затем вы отправите этот пакет на свой сервер Octopus Deploy и создадите выпуск.

Этот выпуск представляет состояние вашего кода, конфигурации и любых переменных Octopus на момент создания выпуска. Это также копия файла web.config, для которого вы должны выполнить преобразование XML как часть развертывания на этапе «Развертывание в веб-приложении Azure».

Хранение источника истины вдали от работающего экземпляра в Azure означает, что вы можете повторить развертывание либо потому, что в работающем экземпляре возникла проблема, либо потому, что вам нужно создать сотню новых копий.

person benPearce    schedule 11.12.2017
comment
Это в основном то, как это работает сейчас, однако релиз разделен на две части. Один для «ванильной» версии приложения, которая в настоящее время находится в Azure. Однако он может быть настроен для каждого клиента, что является второй частью, на которую накладываются дополнительные dll и преобразования конфигурации. Вы хотите сказать, что эти две части следует объединить в один «источник истины»? - person Iain Ward; 11.12.2017
comment
Для этого сценария вы, вероятно, захотите использовать арендаторов. Вам также может потребоваться изменить процесс сборки, в зависимости от того, как структурирован ваш код для обработки индивидуальной настройки клиента. При многопользовательском развертывании вы можете охватить действия процесса разными клиентами или включить переменные, значения которых различаются для каждого клиента, или вам может потребоваться несколько процессов развертывания. - person benPearce; 11.12.2017
comment
Хорошо, спасибо, так что объединение настройки в процесс сборки, а не двухэтапный подход, - это выход? - person Iain Ward; 11.12.2017
comment
Как я уже сказал, это действительно зависит от того, как все это работает. В процессе сборки можно создать один пакет для каждого клиента или в процессе развертывания можно создать настраиваемое развертывание для каждого клиента с использованием клиентов в Octopus Deploy. - person benPearce; 11.12.2017