Параметры конфигурации Azure Web Role в разных средах

Освобождение до Azure:

Прежде чем использовать Azure, у нас будут только файлы конфигурации только для чтения, сидящие в разных средах (тестирование, постановка и производство и т.д.). Во время релиза все файлы приложений (без файлов конфигурации) будут развернуты в соответствующей среде. Затем файлы приложений будут считывать конфигурационный файл среды для строк подключения и другие данные, относящиеся к среде. Я предполагаю, что это довольно стандартная настройка?

Освобождение после Azure:

Теперь мы перемещаем наши веб-приложения в Azure Web Roles. Веб-роли используют файлы ServiceConfiguration.Cloud.cscfg и ServiceConfiguration.Local.cscfg.

При публикации в облачном сервисе необходимо знать строки подключения. Если мы хотим опубликовать в службе облака тестирования, тогда ServiceConfiguration.Cloud.cscfg необходимо соответствующим образом отредактировать. Если мы хотим опубликовать в облачном сервисе Staging или Production, тогда ServiceConfiguration.Cloud.cscfg необходимо изменить далее.

Я бы предпочел отвлечь разработчиков AWAY от строк подключения, когда они выполняют их развертывания. Это предотвращает ошибку, указывающую на неправильные условия (которые могут иметь огромные последствия). Как это можно сделать?

Я понимаю, что эти параметры конфигурации могут быть изменены на портале управления Azure, но включение этого шага в процесс выпуска означает, что разработчикам необходимо будет иметь доступ к Порталу управления, что не является идеальной ситуацией, поскольку существует (плюс "открытый" доступ к Management Portal).

Update:

Я обнаружил, что вы можете управлять файлами конфигурации службы, добавляя больше (и переименовывая):

enter image description here

И затем, выбрав правильную облачную службу (черный) и правильную конфигурацию службы (красная стрелка) вместе, разработчикам не нужно знать подробности конфигурации:

enter image description here

По-прежнему существует проблема, когда разработчик выбирает неправильную конфигурацию сервиса при развертывании в облачную службу (но, возможно, это может быть автоматизировано в script, чтобы предотвратить это?)

Мой главный irk - тип среды (синяя стрелка). Теперь это бесполезно для меня.

Ответ 1

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

В моем приложении у меня есть 3 прикладных проекта (1 WebRole и 2 Worker Role)

Затем мы имеем 6 проектов облачного развертывания, по одному для каждой целевой среды. Каждый проект развертывания содержит одну и ту же роль ролей в Интернете и рабочие роли, но имеет другой файл cscfg и csdef.

Solution Organisation

На уровне приложения файлы app.config и web.config обрабатываются через Configuration Transforms с помощью SlowCheetah. В основном у вас есть другая конфигурация конфигурации в диспетчере конфигурации для каждого развертывания. поэтому вместо Debug и Release у меня есть Debug, QA, Uat, Test, SAndbox, Production