Конфигурация проекта облачной инфраструктуры Azure (.csdef и .cscfg) в нескольких средах

В настоящее время у нас есть облачные сервисы разработки (acme-dev-service) и облачная служба производства (acme-prod-service). Наша текущая настройка в нашем решении имеет проект облачных сервисов, называемый acme.application, который использует преобразование файлов .cscfg и .csdef для развертывания проекта в двух средах (производство и разработка). Мне не нравится метод преобразования, потому что для меня это похоже на хак. Поэтому, после некоторых исследований, кажется, что у вас может быть несколько файлов конфигурации, которые решают некоторые проблемы, но я столкнулся с проблемами, потому что вам разрешено только одно определение службы. Это не работает для нас, потому что производственная среда требует дополнительных сертификатов, а также разных привязок hostHeader, чем наша среда разработки.

Так кажется, что мы не можем уйти от использования преобразований. Поэтому, я думаю, мой вопрос сводится к тому, что я смотрю на файлы Project Azure Service в неправильном свете? Должны ли мы действительно сопоставлять один проект Azure с одним облачным сервисом Azure? Должен ли я иметь проект Azure для производства и второй проект Azure для развития? Есть лучший способ сделать это? Или лучше всего работать с несколькими средами в Azure?

Ответ 1

Файл CSDefinition является настоящим кикером. Если у вас есть значение, вы должны быть разными между двумя средами (dev/test/stage/production и т.д.), Тогда у вас действительно есть три варианта:

1) Вручную измените значение перед развертыванием. Errr.... Хорошо.... у вас есть два варианта.

1) Коснитесь процесса MS Build и определите, какую конфигурацию облака вы выбрали (тот, который используется для определения, какая версия файла .cscfg будет использоваться), а затем создайте модификацию .csdef после сборки и предыдущих для упаковки (есть время, когда файл был скопирован в другой каталог перед упаковкой, и именно там вы хотите внести изменения). Это может быть сложно, хотя я видел это и даже сделал это сам в ранние дни SDK. Вот сообщение в блоге, объясняющее один пример, где он использует WebConfigTransformRunner для этого: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. Я действительно не думаю, что это ваш лучший вариант, потому что он непрозрачен. Это не очевидно, что происходит, и кто-то, кто приходит после вас, чтобы сохранить код, не узнает об этом маленьком драгоценном камне и будет тратить навсегда попытку выяснить, почему какое-то значение, которое они кладут в csdef где-то, как-то перезаписывается после публикации в другой среде.

2) Используйте два упомянутых вами подхода Azure Project. Вы можете настроить определения сборки в своем инструменте Build, который определяет, какие проекты Azure вы хотите построить и опубликовать. Лично я считаю, что это лучший способ справиться с различными файлами .csdef. Это прямо вперед и не требует изменения файлов csproj. Я не против изменения файла csproj, это просто не слишком очевидно, что это было сделано, и, говоря как кто-то, кто унаследовал такие вещи, нелегко найти, когда люди делают такие вещи, и им не нужно рассказывать вы об этом.