Общие сведения об ALM с Microsoft Power Platform
В этой статье описываются компоненты, средства и процессы, необходимые для реализации управления жизненным циклом приложений (ALM).
Среды
Среды — это пространство для хранения, управления и предоставления общего доступа к бизнес-данным, приложениям и бизнес-процессам. Они также служат контейнерами, которые разделяют приложения, которые могут иметь различные роли, требования безопасности или целевые аудитории. Каждая среда может иметь только одну базу данных Microsoft Dataverse. Дополнительные сведения: Обзор сред
Внимание
При создании среды вы можете выбрать установку приложений Dynamics 365, таких как Dynamics 365 Sales и Dynamics 365 Marketing. В это время важно определить, нужны ли эти приложения или нет, потому что их нельзя удалить или установить позже. Если вы не используете эти приложения и не будете нуждаться в них в будущем, мы рекомендуем не устанавливать их в своих средах. Это поможет избежать осложнений с зависимостью при распределении решений между средами.
Типы сред, используемых в ALM
С использованием Центр администрирования Power Platform, вы можете создавать эти типы сред Power Platform:
Песочница Среда песочницы — это любая непроизводственная среда Dataverse. Изолированная от производственного использования среда песочницы представляет собой среду, где можно без опасений вносить изменения в приложение и тестировать их с низким риском. Среды песочницы включают в себя возможности, которые могут быть опасными в рабочей среде, такие как операции сброса, удаления и копирования. Дополнительные сведения: Управление средами песочницы
Рабочая среда Среда, в которой приложения и другое программное обеспечение вводятся в эксплуатацию по назначению.
Разработчик (официально называется Сообщество). План разработчика Power Apps дает вам доступ к функциям Power Apps Премиум, Dataverse и Power Automate для индивидуального использования. Этот план в первую очередь предназначен для создания и тестирования с Power Apps, Power Automate и Microsoft Dataverse или в учебных целях. Среда разработки — это однопользовательская среда, и ее нельзя использовать для запуска или совместного использования рабочих приложений.
По умолчанию Автоматически создается одна среда по умолчанию для каждого клиента. Доступ к ней получают все пользователи этого клиента. Клиент идентифицирует клиента, который может иметь одну или несколько подписок Microsoft и связанных с ней сервисов. Когда новый пользователь регистрируется в Power Apps, он автоматически добавляется в роль разработчика в среде по умолчанию. Среда по умолчанию создается в регионе, ближайшем к региону по умолчанию клиента Microsoft Entra, и называется так: «{Имя клиента Microsoft Entra} (по умолчанию)»
Создайте и используйте правильную среду для определенных целей, таких как разработка, тестирование или производство.
Дополнительные сведения о средах см. тут: Обзор сред.
У кого должен быть доступ?
Определите и управляйте безопасностью своих ресурсов и данных в Microsoft Dataverse. Microsoft Power Platform предоставляет роли администратора уровня среды для выполнения задач. Dataverse включает роли безопасности, которые определяют уровень доступа к приложениям, компонентам приложений и ресурсам, которые разработчики приложений и пользователи имеют в Dataverse.
| Назначение среды | Роли, которые имеют доступ | Комментарий |
|---|---|---|
| Разработка | Создатели приложений и разработчики. | Пользователи приложения не должны иметь доступа. Разработчикам требуется по крайней мере роль безопасности "создатель среды" для создания ресурсов. |
| Тестировать | Администраторы и пользователи, которые тестируют. | Создатели приложений, разработчики и пользователи рабочих приложений не должны иметь доступа. Тестовые пользователи должны иметь достаточно привилегий для проведения тестирования. |
| Рабочая версия | Администраторы и пользователи приложения. Пользователи должны иметь необходимый доступ для выполнения своих задач для приложений, которые они используют. | Создатели приложений и разработчики не должны иметь доступа или должны иметь только привилегии на уровне пользователя. |
| По умолчанию | По умолчанию каждый пользователь вашего клиента может создавать и редактировать приложения в среда Dataverse по умолчанию, которая имеет базу данных. | Мы настоятельно рекомендуем вам создавать среды для конкретной цели и предоставлять соответствующие роли и привилегии только тем пользователям, которые в них нуждаются. |
Дополнительные сведения:
- Общие сведения о средах
- Управление доступом пользователей к средам: группы безопасности и лицензии
- Создание пользователей и назначение ролей безопасности
- Создание сред
Решения
Решения используются для переноса приложений и компонентов из одной среды в другую или для применения набора настроек для существующих приложений.
Решения имеют следующие особенности:
Они включают в себя метаданные и некоторые сущности с данными конфигурации. Решения не содержат никаких бизнес-данных.
Они могут содержать много разных компоненты Microsoft Power Platform, такие как приложения на основе модели, приложения на основе холста, карты сайта, потоки, сущности, формы, настраиваемые соединители, веб-ресурсы, наборы параметров, диаграммы и поля. Обратите внимание, что не все сущности могут быть включены в решение. Например, в решение нельзя добавить системные таблицы "Пользователь приложения", "Пользовательский API" и "Параметры организации".
Они упакованы как единое целое для экспорта и импорта в другие среды или деконструированы и включены в управление исходным кодом в качестве исходного кода для активов. Решения также используются для внесения изменений в существующие решения.
Управляемые решения используются для развертывания в любой среде, которая не является средой разработки для этого решения. Это включает в себя тестирование, приемочное тестирование пользователя (UAT), тестирование системной интеграции (SIT) и рабочие среды. Управляемые решения можно обслуживать (обновлять, исправлять и удалять) независимо от других управляемых решений в среде. В соответствии с рекомендациями ALM управляемые решения должны генерироваться сервером сборки и считаться артефактом сборки.
Обновления управляемое решение развернуты в предыдущей версии управляемое решение. Это не создает дополнительный слой решения. Вы не можете удалить компоненты с помощью обновления.
Исправление содержит только изменения для родительского управляемое решение. Вы должны использовать исправления только при небольших обновлениях (например, исправление), и, возможно, вам потребуется удалить их. Когда исправления импортируются, они накладываются поверх родительского решения. Вы не можете удалить компоненты с помощью исправления.
Обновление решения устанавливает новый слой решения непосредственно над базовым слоем и любыми существующими исправлениями.
Применение обновлений решения включает удаление всех существующих исправлений и базового слоя.
При обновлении решения удаляются компоненты, которые существовали, но больше не включены в обновленную версию.
Дополнительные сведения: Основные понятия решения
Управление исходным кодом
Управление исходным кодом, также известное как управление версиями, представляет собой систему, которая поддерживает и надежно хранит активы разработки программного обеспечения и отслеживает изменения в этих активах. Отслеживание изменений особенно важно, когда несколько создателей приложений и разработчиков работают с одним и тем же набором файлов. Система управления версиями также дает вам возможность откатить изменения или восстановить удаленные файлы.
Система управления исходным кодом помогает организациям достичь работоспособной ALM, поскольку активы, поддерживаемые в системе управления исходным кодом, являются "единым источником данных" — или, другими словами, единой точкой доступа и модификации для ваших решений.
Стратегия ветвления и слияния
Почти каждая система управления версиями имеет некоторую форму поддержки ветвления и слияния. Ветвление означает, что вы отклоняетесь от основной линии разработки и продолжаете выполнять работу без изменения основной линии. Процесс слияния состоит из объединения одной ветви в другую, например, из ветви разработки в основную ветку. Некоторые распространенные стратегии ветвления — это ветвление на основе соединительных линий, ветвление выпуска и ветвление функций. Дополнительные сведения: Примите стратегию ветвления Git
Процесс управления исходным кодом с использованием решения
Есть два основных пути, которые вы можете использовать при работе с решениями в системе управления версиями:
- Экспортируйте неуправляемое решение и поместите его в распакованном виде в систему управления версиями. Процесс сборки импортирует упакованное решение как неуправляемое во временную среду сборки (среда песочницы). Затем экспортируйте решение как управляемое и сохраните его как артефакт сборки в вашей системе управления версиями.
- Экспортируйте решение как неуправляемое, а также экспортируйте решение как управляемое и поместите оба в систему управления версиями. Хотя этот метод не требует среды сборки, он требует поддержки двух копий всех компонентов (одна копия всех неуправляемых компонентов из неуправляемого решения и одна копия всех управляемых компонентов из управляемое решение).
Дополнительные сведения: Задачи средства сборки
Автоматизация
Служба автоматизации является ключевой частью жизненного цикла приложения, которая повышает производительность, надежность, качество и эффективность ALM. Инструменты и задачи службы автоматизации используются для проверки, экспорта, упаковки, распаковки и экспорта решений в дополнение к созданию и сбросу сред песочницы.
Дополнительные сведения: Что такое Microsoft Power Platform Build Tools?
Коллективная разработка с использованием совместного управления исходным кодом
Важно учитывать, как вы и ваша группа разработчиков будете работать вместе для сборки проекта. Преодоление обособленности и генерация мнений и разговоров может помочь вашей группе предоставить лучшее программное обеспечение. Некоторые средства и бизнес-процессы — такие как в Git, GitHub и Azure DevOps — были разработаны специально для улучшения качества коммуникации и программного обеспечения. Обратите внимание, что работа с конфигурациями в системе решений может создать проблемы для коллективной разработки. Организации должны координировать изменения от нескольких разработчиков, чтобы максимально избежать конфликтов при слиянии, потому что системы управления версиями имеют ограничения на то, как происходят слияния. Мы рекомендуем вам избегать ситуаций, когда несколько человек вносят изменения в сложные компоненты — такие как формы, потоки и приложения на основе холста — одновременно.
Дополнительные сведения: Сценарий 5: Поддержка коллективной разработки
Непрерывная интеграция и развертывание
Вы можете использовать любую систему управления исходным кодом и собрать конвейер, чтобы начать работу с непрерывной интеграции и непрерывного развертывания (CI/CD). Тем не менее, это руководство фокусируется на GitHub и Azure DevOps. GitHub — это платформа разработки, используемая миллионами разработчиков. Azure DevOps предоставляет службы разработчиков группам поддержки для планирования работы, коллективной работы над разработкой кода, а также для создания и развертывания приложений.
Чтобы приступить к работе, требуется следующее:
Учетная запись GitHub, где вы можете создать репозиторий. Если у вас нет учетной записи, вы можете создать ее бесплатно.
Организация Azure DevOps. Если у вас нет учетной записи, вы можете создать ее бесплатно.
Дополнительные сведения: Создайте свой первый конвейер
Лицензирование
Для создания или редактирования приложений и потоков с помощью Power Apps и Power Automate, соответственно, пользователи будут обязаны иметь индивидуальную лицензию для Power Apps или Power Automate или соответствующую лицензию на приложение Dynamics 365. Дополнительные сведения см. в Обзор лицензирования для Microsoft Power Platform. Мы также рекомендуем связаться с представителем вашей учетной записи Майкрософт для обсуждения ваших потребностей в лицензировании.
Особенности ALM
Когда вы рассматриваете ALM как неотъемлемую часть создания приложений на Microsoft Power Platform, это может радикальным образом повысить скорость, надежность и удобство работы приложения. Это также гарантирует, что несколько разработчиков, как обычные разработчики, пишущие код, так и разработчики-любители, могут совместно вносить вклад в создание приложения.
См. следующие статьи, в которых обсуждаются несколько вопросов, которые следует учитывать в начале разработки любого приложения: