Какова предпочтительная практика для создания среды разработки и развертывания Azure, совместимой с ALM?

Question

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

Для начала я изучаю Azure Key Vault, и он представил прекрасный пример сценария моего основного вопроса.

В моем развитии (и ALM) процесса, я обычно:

• Локальная среда разработки
• Развернутые среда разработки (CI/CD)
• Testing Environment
• Балетмейстер
• Производство

Для каждой среды у меня обычно есть App.config или Web.config с XDT environment transforms, которые запускаются для каждой среды и размещаются в настройках среды для каждой среды для внешних ресурсов, которые использует мое приложение.

Теперь я видел this question, но мне было несколько лет, поэтому я хотел вернуться к нему, поскольку, похоже, было много работы, в частности, с new Azure Resource Manager and the Azure Management API that seems to have replaced Azure Service Management model.

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

Мои вопросы:

1. Является ли это правильный способ смотреть на Azure группы ресурсов?
2. Из моей локальной среды разработки следует подключиться к ресурсам, хранящимся в группе ресурсов разработки Azure, которую я создаю, или есть другой предпочтительный механизм для локального развития? (Например, существуют ли другие эмуляторы, такие как Azure Storage Emulator, которые я должен использовать?)
3. Есть ли более предпочтительный подход к обработке моей среды, чем то, что я представил?

Заранее благодарю за помощь и разъяснения!

Answer 1

ИМХО (..и я не могу делать вид, что я эксперт),

1. Да, группа ресурсов в среде звучит разумно. Однако вы можете также рассмотреть отдельные подписки (или отдельные для производства), потому что есть такие вещи, как AAD (которые, как я полагаю, вы используете для Key Vault), которые выходят за рамки группы ресурсов. Вероятно, вы не хотите, чтобы ваше приложение-разработчик случайно обратилось к хранилищу ключей продукта.
2. Это действительно зависит от того, что вы строите, но если нет необходимости разделять локальные и облачные среды, тогда я бы скажем, только 1 среда.
3. См. Выше :)