Managed и unmanaged решения Power Platform: полное руководство

By Mirko Peters · 2026-10-21

Разберитесь в ключевых различиях между managed и unmanaged решениями Power Platform, правилах развертывания и рекомендациях по ALM для ваших приложений.

Automatically translated with AI from the original post. Read the English original

Понимание различий между managed и unmanaged решениями Power Platform необходимо, чтобы предотвратить катастрофическое удаление приложений и неудачные развертывания. В этом руководстве объясняется, как unmanaged слои служат вашим редактируемым рабочим пространством, а managed решения — замороженными пакетами для развертывания в средах разработки, тестирования и production.

Главное

• Unmanaged решения — это ваша рабочая копия в средах разработки, где вы активно создаете, редактируете и экспериментируете.
• Managed решения — это замороженные копии для развертывания, предназначенные исключительно для тестовых и производственных сред, чтобы сохранять стабильность.
• Удаление unmanaged решения удаляет только контейнер, оставляя компоненты на месте, тогда как удаление managed решения уничтожает связанные пользовательские таблицы и данные.
• Нельзя импортировать managed решение обратно в ту же среду разработки, где был создан его unmanaged исходник.
• Рассмотрение unmanaged решений как исходного кода, а managed решений как артефактов сборки приводит ваш ALM в Power Platform в соответствие со стандартными практиками разработки ПО.

Ключевые различия между managed и unmanaged решениями

Когда вы только начинаете создавать приложения, потоки и таблицы в Microsoft Power Platform, легко воспринимать среды как гигантские цифровые блокноты. Вы кликаете, создаете пользовательские сущности и настраиваете облачные потоки прямо в среде по умолчанию или общем рабочем пространстве. Однако, как только проект выходит за рамки стадии proof of concept, такой подход быстро приводит к неподдерживаемому коду и случайной потере данных. Чтобы создавать надежные приложения, нужно понимать фундаментальное различие между unmanaged и managed решениями.

По сути, решение — это просто контейнер, манифест отгрузки, который объединяет компоненты приложения, чтобы их можно было аккуратно переносить между средами. Но внутри этой концепции контейнера есть строгая дихотомия: unmanaged против managed. Чтобы запомнить назначение каждого, достаточно простой фразы: unmanaged — для редактирования здесь, а managed — для развертывания там.

Unmanaged решения: ваше рабочее пространство для разработки

Unmanaged решение — это ваша активная, редактируемая рабочая копия. Когда вы проектируете canvas-приложение, пишете бизнес-правила или изменяете таблицы Dataverse, вы работаете внутри unmanaged решения в среде разработки. Каждая правка, изменение цвета и корректировка схемы сразу попадает в базовое приложение.

Что происходит при удалении unmanaged решения?

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

Microsoft рекомендует хранить неуправляемые решения непосредственно в системах контроля версий, таких как GitHub или Azure DevOps. Если рассматривать неуправляемое решение как основной репозиторий исходного кода, вы получаете полную историческую трассировку всех изменений, которые вносила команда разработки.

Управляемые решения: пакет для развёртывания в продуктивной среде

Управляемое решение представляет собой готовую, скомпилированную и зафиксированную копию вашего приложения. Напрямую редактировать управляемое решение нельзя. Вместо этого вы экспортируете неуправляемое решение как управляемое и развёртываете этот пакет в последующих средах: в среде приёмочного тестирования (UAT), в среде интеграционного тестирования (SIT) и, в конечном итоге, в продуктивной среде.

Удаление управляемого решения: чем это чревато

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

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

Архитектура сред и правила тестирования

Технические механизмы Power Platform жёстко разграничивают среды в зависимости от того, как вы работаете с этими двумя типами решений. Например, управляемое решение нельзя импортировать обратно в ту среду разработки, где находится неуправляемое решение, из которого оно было собрано. Для тестирования управляемого развёртывания нужна отдельная среда, поэтому лучшая практика — с самого начала настроить выделенный конвейер из нескольких сред.

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

• Разработка: здесь разработчики создают и изменяют неуправляемые решения.
• Тестирование (UAT): здесь вы импортируете управляемое решение, чтобы убедиться, что процесс развёртывания и функциональность приложения работают корректно.
• Продуктивная среда: здесь реальные пользователи каждый день работают со стабильным, зафиксированным управляемым решением.

Стратегия развёртывания Power Platform: как всё выстроить

Строгое разделение между неуправляемыми рабочими средами разработки и управляемыми развёртываниями в продуктивной среде превращает вашу стратегию Power Platform из набора хрупких решений «на коленке» в инженерную разработку корпоративного уровня. Соблюдая границы решений, защищая продуктивные среды от ad-hoc изменений и поддерживая аккуратные практики работы с контролем версий, вы гарантируете, что критически важные для бизнеса приложения останутся стабильными и устойчивыми по мере роста.

Чтобы глубже разобраться в механике компонентов Power Platform, издателей, префиксов и слоёв решений, обязательно послушайте полный выпуск и подпишитесь на подкаст, чтобы следить за новостями экосистемы облачных сервисов Microsoft.