Добавить DevOps в Power Platform приложение? Легко!

Когда я создавал свои первые приложения в Power Apps, такого понятия, как DevOps в Power Platform ещё не существовало. Но, прошло время, и сегодня Microsoft предлагает простые и эффективные способы организации жизненного цикла приложений в Power Platform.

В этом посте я опишу простой вариант, в котором мы не будем делать интеграцию с Azure DevOps Services или c GitHub, а просто создадим несколько сред, в которых и будет жить наше приложение.

Для примера возьмём поток в Power Automate.

Итак, для начала необходимо решить, какие среды или Environments вы будете использовать. На мой взгляд, как минимум, вам понадобится три среды:

• Development — среда, где будет происходить собственно разработка, изменение вашего потока. Решение будет unmanaged, то есть с возможностью редактирования. Если вы создаёте среду «с нуля», можете выбрать тип среды «Разработка»
• Test — среда для тестирования приложения в managed варианте. При создании подойдёт тип среды «Песочница»
• Production — производственная среда, в которой будут работать ваши конечные пользователи. При создании выбираем тип «Рабочая версия». Здесь приложение тоже будет managed и, как следствие, изменений в нём мы делать не будем.

Создание трёх сред позволит нам обезопасить себя от случайного изменения, удаления или иных нежелательных действий с приложением или потоком, которые повлияют на бизнес-пользователей и сделают их работу либо невозможной, либо затруднительной. Также, имея несколько разных по свойствам сред, мы можем быть уверены, что наше приложение будет вести себя одинаково в различных условиях и для различных пользователей. Ещё одним плюсом будет возможность ограничения доступа к приложению в разных средах. Логично, что в Dev это будут только разработчики, в Test — соответственно, тестировщики (или пользователи, которым вы дадите такие полномочия), а в Production — только ваши бизнес-пользователи.

Для создания сред используем Центр Администрования (Admin Center), вкладку «Среды»:

Поскольку создание новой среды достаточно тривиально, приводить подробное описание процесса не буду.

При создании разных сред может возникнуть сложность с реакцией на триггеры, по которым срабатывает ваш поток. Например, вашим триггером может быть заполнение пользователем формы в Microsoft Forms. Если во всех средах триггеры будут реагировать на заполнение одной и той же формы, вы будете получать ложные срабатывания, например в Test и Prod, когда будете проводить тестирование в Dev. Вопрос, как этого избежать? Я думаю, что есть много различных вариантов. В одном из проектов я выбрал такой: для каждой среды создал по одной форме, и настроил триггер на срабатывание именно заданной формы. Но, как это сделать, если идентификатор формы задаётся на этапе дизайна, т.е. хардкодится? Тут на помощь могут прийти Переменные Среды (Environment Variables), которые вы можете задавать как для конкретного приложения (Solution), так и для среды в целом (если пропишете значения переменных в решении Default).

Тут мы подходим к теме решений или Solutions, с помощью которых реализуется DevOps в Power Platform. Как пишет Misrosoft в свой документации, Решения — это механизм реализации ALM в Power Apps и Power Automate. В решение вы можете включить свои приложения, потоки, коннекторы, добавить в них переменные среды, модели и всё, что понадобится для работы вашего приложения при переносе его в другую среду. Пример — приложение Default, которое создаётся в каждой среде при создании:

Как видим, количество типов артефактов, которые могут быть включены в решение, очень велико. Нам, для дальнейшей работы нужно будет создать новое решение и включить в него наше приложение или поток (возможно, не одно, а несколько, зависит от ваших задач). При попытке деплоймента в другую среду, Power Platform проанализирует зависимости и предложит вам включить в решение также и другие компоненты, от которых зависит работа ваших приложений/потоков.

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

Дело в том, что если среда имеет статус managed, вы не сможете изменить значение переменной среды в вашем решении. Но, открыв решение Default, вы увидите, что и значение по умолчанию и текущее значение доступны для редактирования. Это открывает лазейку для управления нашим приложение или потоком. В нашем случае с формой Microsoft Forms мы можем использовать переменную среды в потоке для задания ID формы, и менять его значение в каждой среде.

Таким образом, в каждой среде приложение будет получать на входе уникальный идентификатор формы. Аналогично можно использовать переменные среды и для других задач.

На этом вводная часть закончена и мы можем переходить непосредственно к созданию конвейеров (или Pipelines). Инструкцию от Майкрософт по созданию конвейеров можно прочитать здесь.

Поскольку мы уже создали три среды (Development, Test и Production), нам потребуется одна дополнительная среда, которая будет использоваться только для хранения информации о нашем конвейере (или конвейерах, если вы создадите их несколько).
Эта среда называется Средой размещения.

Среда размещения. Эта специализированная среда играет роль хранилища и плоскости управления для всей конфигурации, безопасности и истории выполнения конвейеров.
Мы рекомендуем использовать ее как выделенную рабочую среду, используемую отдельно от среды разработки и целевой среды.
При желании вы можете настроить несколько разных хост-сред в одном клиенте, — например, для отдельного управления конвейерами для разных бизнес-организаций или географических местоположений. Одна хост-среда для всего клиента также является приемлемым вариантом — при условии, что все среды находятся в одном географическом местоположении.

Так определяет её Microsoft. При создании этой среды не забудьте, что все среды, используемые в конвейерах, должны иметь базу данных Microsoft Dataverse. Создаём её также в Центре Администрирования.

Далее переходим во вновь созданную среду и делаем следующее:

• Установите в своей хост-среде приложение Конвейеры Power Platform, выбрав хост-среду, а затем выбрав Ресурсы>Приложения Dynamics 365.
• Выберите Установить приложение и прокрутите вниз на правой панели, пока не найдете Конвейеры Power Platform.
• Выберите Далее; если вы согласны, примите условия и выберите Установить.

После указанных действий приложение Power Platform Pipelines должно иметь статус «Установлено».

После этого можно переходить к созданию конвейера. В документации рекомендуется сохранить идентификаторы сред согласно статье Нахождение среды и идентификатора и названия организации. Но, к сожалению, статья, видимо, несколько устарела и идентификатор среды, который она рекомендует использовать, не принимается при создании конвейера. Поэтому лучше будет просто взять его из строки URL вашей среды. Например, для Development ID можно найти так:

По завершении установки пакета Конвейер развертывания перейдите на портал Power Apps  и выберите хост-среду (где вы установили приложение Конвейер Power Platform). Перейдите в «Приложения» и запустите приложение Конфигурация конвейеров развертывания.

Выберите Среды на левой панели, затем выберите Создать, чтобы создать записи сред в Dataverse:

Заполните поля Имя (зависит от названия вашей среды), Тип среды (может быть Development Environment или Target Environment), ID среды (мы сохранили его ранее), необязательное поле Описание. Если ID среды указан правильно, статус валидации должен измениться на Success. Не забудьте нажать на кнопку «Сохранить».

Таким образом создаём три среды — Development (тип Development), Test (тип Target) и Production (тип Target).

Далее переходим во вкладку Конвейеры (Pipelines). Здесь снова нажимаем кнопку New.

После сохранения, вы сможете добавить среду разработки, выбрав её из ранее созданных на предыдущем шаге:

После этого можно переходить к созданию Стадий Развертывания. В сетке Стадии Развёртывания нажимаем кнопку «New Deployment Stage» и в открывшемся окне заполняем поля:

• Имя: имя стадии.
• Описание (необязательно): необязательное описание стадии.
• Предыдущая стадия развертывания (необязательно): указывает стадию развертывания, в которую необходимо выполнить развертывание, прежде чем выполнять развертывание в текущую стадию. Например, при создании рабочей стадии вы можете указать в поле Предыдущая стадия развертывания стадию тестирования. Обратите внимание, что для первой стадии или для конвейеров, содержащих только одну стадию, это поле следует оставлять пустым.
• Целевая среда развертывания: это целевая среда, в которой будет производиться развертывание стадии.
• Требуется шаг перед развертыванием (необязательно): запросы на развертывание будут находиться на ожидании до тех пор, пока они не будут одобрены пользовательской бизнес-логикой. Требуются дополнительные действия по настройке. Подробнее: Расширение конвейеров в Power Platform

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

1. Развёртывание из среды разработки в среду тестирования (из Development в Test)
2. Развёртывание из среды тестирования с продуктивную среду (из Test в Production)

Должно получиться что-то типа такого:

После всех предпринятых действий мы получим рабочий конвейер, который сможем использовать для развертывания своих решений. Конечно, необходимо раздать права на работу с конвейрами своим сотрудникам. Это мы делаем в среде размещения через Центр Администрирования

При установке приложения «Конвейеры Power Platform» добавляются две роли безопасности:

• Пользователь конвейеров развертывания: имеет привилегии на запуск конвейеров, к которым ему предоставлен доступ.
• Администратор конвейеров развертывания: имеет полный контроль над всей конфигурацией конвейеров, не будучи участником роли безопасности «Системный администратор».

Важно!
Администраторы конвейеров также должны иметь доступ ко всем средам разработки, тестовым средам или рабочим средам, связанным с конвейерами, которые они создают или запускают.

После того, как все конвейеры созданы, роли назначены, можем переходить непосредственно к развертыванию. Статью документации можно почитать здесь. Мы же посмотрим, как это сделать на конкретном примере.

Напомню, что все действия по развертыванию производятся из среды разработки Development. Перейдём в Решения, выберем своё решение, которое мы создали ранее (или создадим новое, если мы ещё не сделали этого) и выберем раздел Контейнеры (Pipelines).

Здесь выбираем нужный конвейер (если их более одного). Как видно на картинке, первый доступный вариант развертывания — это из Dev в Test. Нажимаем кнопку Deploy here.

Если есть зависимости, которые не включены в решение и которых ещё нет в целевой среде развертывания, визард сообщит вам об этом и предложит включить их в решение. Если развертывание прошло успешно, вы увидите информацию о новой версии решения в среде развертывания, дату и время последнего развертывания. Также станет доступна кнопка Deploy here в следующей целевой среде развертывания (Production).

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