Развертывание в Azure API Management с помощью GIT, но выполнение чего-то похожего на преобразования web.config

В настоящее время я работаю над развертыванием конфигураций управления API AZURE на нескольких серверах. Например, как DEV/TEST/PROD.

Таким образом, я могу клонировать свой репозиторий, используя GIT, например, для моей среды DEV. Но я мог бы захотеть отправить это в TEST, используя тот же «код». Я имею в виду, что у меня не будет полной версии кода, специфичной для TEST, а будет база кода 1 *, которую я мог бы преобразовать в некоторые переменные для развертывания TEST.

Таким образом, URL будет идти от этого: http://my-DEV-url.com до http://my-TEST-url.com

введите здесь описание изображения

Теперь в других мирах, таких как, например, веб-сайты, я могу преобразовать свой файл web.config с помощью web.test.config. ТАК, в зависимости от моей конфигурации сборки, моя конфигурация автоматически преобразуется.

Итак, мой реальный вопрос заключается в том, могу ли я выполнять какие-либо необычные преобразования в моем json управления API Azure, чтобы не хранить 3 версии (DEV/TEST/PROD) моего кода в 3 разных ветках GIT.

Любые предложения будут очень признательны.

спасибо Расс


git azure-api-management transformation
person RuSs    schedule 20.07.2016    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Вы можете использовать свойства для определения значения области. Свойства нельзя использовать для определения serviceUrl для API, но вы можете использовать политика set-backend-service для определения serviceUrl во время выполнения.

<policies>
    <inbound>
         <set-backend-service base-url="{{backend-url}}" />
         ....

Затем вы устанавливаете для свойства «backend-url» желаемые значения в ваших экземплярах APIM. Обратите внимание, что свойства не экспортируются через git, поэтому все ваши экземпляры будут иметь разные значения.

person JJ.    schedule 22.07.2016
comment
Спасибо @j.j. Я действительно нашел это вчера. Работает отлично. Спасибо - person RuSs; 23.07.2016