Как разместить рабочую роль Azure локально / в помещении?

Question

Некоторый фон ....

Мы впервые попадаем в Azure и пытаемся сделать это по-детски. На данный момент нашими первыми приложениями будут очереди рабочих ролей, отслеживающие очереди для обработки запросов (таких как отправка электронной почты или выполнение некоторой очистки экрана), и мы просто вставим в очереди наши локальные приложения MVC и службы WCF. Позже мы переместим приложение MVC и службы WCF в Azure.

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

1. Разработка локально и на некоторых общих серверах. Проверьте в систему контроля версий.
2. Каждые 15 минут сервер сборки собирается и развертывается в среде «разработки» (удваивается как CI и покрывает на случай, если нам понадобится среда «разработки», отличная от локальной)
3. Технические тестеры вручную запускают сервер сборки для развертывания последней успешной сборки "Dev" в тестовой среде (или, альтернативно, ранее развернутой тестовой сборки, включая / исключая базу данных).
4. Технические тестеры и бизнес-тестеры вручную запускают сервер сборки для развертывания последней успешной сборки "Тест" (или, альтернативно, ранее развернутой сборки "Тест", включая / исключая базу данных) в среде QA.
5. В какой-то момент мы объединяем набор изменений, который QA утверждает для развертывания.
6. Позже наш сервер производственной сборки развертывает эту версию в стадии подготовки, а затем в наших производственных средах (мы размещаем ее N раз в параллельных / независимых средах).

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

Итак, как мы можем разумно разместить наши рабочие роли локально таким образом, чтобы мы фактически тестировали код, который развертывается в Azure?

Один из предложенных вариантов заключается в том, что мы создаем рабочую роль в качестве оболочки / фасада и выполняем всю реальную работу внутри библиотеки классов, что и было нашим планом. Тем не менее, последующее действие, которое позволит нам «разместить» это, будет заключаться в создании второго приложения-оболочки / фасада, которое выполняет ту же работу, что и рабочая роль, просто так, чтобы мы могли запустить его как запланированную задачу или окна. сервер. В конечном счете, мне не нравится эта опция, потому что весь проект никогда не тестируется, пока не достигнет стадии подготовки.

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

Answer 1

Считаете ли вы, эмулятор Azure может вам помочь? Это различия между настоящим провайдером Azure и эмулятором.

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

Используйте PowerShell для настройки своих ролей и еще много чего. Настройте свой эмулятор Azure как this .

Answer 2

Фасадный подход является лучшим, если честно.

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

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

В этом случае всегда есть какой-то элемент компромисса, если только ваши тестовые среды не идентичны вашим производственным средам.

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

Вы можете создать очень маленькое развертывание исключительно для последующих этапов тестирования. Вы платите за время развертывания роли, поэтому, если вы удалите развертывание после завершения тестирования, вы сможете минимизировать затраты.

Наконец, и образец фасада является примером, дизайн для тестирования. Факторизуйте свой код, чтобы максимально увеличить количество, которое можно протестировать перед развертыванием, и минимизировать свой риск на более поздних этапах тестирования.