Упорядочение решений

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

Аспект Рассмотрение
Область приложения Распространяется ли реализация на несколько приложений, таких как Sales, Customer Service, Field Service, Finance и т. д.?
Частота выпуска Как часто планируется развертывать обновления в рабочей среде?
Ваша методология доставки основана на гибких методиках, таких как циклы спринта?
Поддержка производственной среды Как обрабатывать срочные исправления в рабочей среде без преждевременного внедрения новых функций?
Архитектура решения Сколькими решениями вы управляете?
Делятся ли эти решения компонентами или зависят друг от друга?
Планирование сред Сколько сред Microsoft Dataverse вам необходимо для поддержки жизненного цикла разработки?
Требуются ли отдельные среды для разработки, тестирования и рабочей среды?
Работают ли разработчики совместно в общей среде, или они требуют изолированной среды для независимой работы?

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

Стратегия единого решения

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

Рекомендуемые для:

  • Реализации малого и среднего масштаба
  • Сценарии, в которых будущая модульность вряд ли будет реализована
Преимущество Недостаток
Упрощенная настройка и управление средой. При необходимости требуется больше усилий по масштабированию или модульизации.
Упрощенное развертывание. Только одно решение для управления делает процессы экспорта и импорта между средами простыми и менее склонными к ошибкам. Одно решение, содержащее большое количество настроек, может привести к более длительному времени развертывания. Чтобы уменьшить размер решения, используйте сегментацию таблиц. Чтобы сократить время импорта, перейдите к рекомендациям по производительности.
Проще находить, проверять и управлять изменениями. Если несколько разработчиков работают в одной среде разработки, они рискуют перезаписывать изменения друг друга. Этот риск может быть сокращен путем реализации управления версиями исходного кода, внедрения стратегии ветвления и использования выделенной среды разработки для каждой ветви. Стратегия управления версиями исходного кода и ветвления обеспечивают отслеживание изменений, поддержку совместной работы и механизмы разрешения конфликтов. Дополнительные сведения: внедрение стратегии ветвления Git.

Примечание

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

Несколько решений в одной среде разработки

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

Рекомендуется для:

  • Реализации небольшого и среднего масштаба с отдельными и независимыми функциональными областями, которые не делятся компонентами.
Преимущество Недостаток
Упрощенная настройка и управление средой. Сохранение нескольких неуправляемых решений в одной среде разработки повышает вероятность конфликтов зависимостей. Например, может возникнуть ситуация, когда невозможно импортировать решение A, так как оно зависит от решения B, а решение B не может быть импортировано, так как оно зависит от решения A.
Функциональные области можно развертывать независимо друг от друга. Несколько разработчиков, работающих в одной среде разработки, могут перезаписать изменения друг друга. Работа в неуправляемом решении не обеспечивает изоляцию. Каждое изменение применяется непосредственно к среде независимо от того, какое решение редактируется.

Примечание

При наличии нескольких решений в одной среде разработки после импорта управляемых решений в целевую среду часто создаются слои. Дополнительные сведения: уровни решения и поведение слияния

Важно, чтобы вы:

  • Не включать один и тот же неуправляемый компонент в несколько решений.
  • Есть только одно решение, включающее все таблицы. Не используйте два разных решения, оба из которых содержат таблицы. Это связано с тем, что часто существует риск единственной связи между таблицами, которая создает зависимость между решениями и вызывает проблемы с обновлением или удалением решения в целевой среде в более поздний момент времени.
  • Используйте только одного издателя решения. Издатель решения владеет компонентами управляемого решения, и его связь не может быть изменена позже. Например, если пользовательская таблица импортируется как управляемая с помощью решения A с издателем X, вы не сможете позже переместить эту таблицу в решение B с издателем Y. Единственный вариант — удалить таблицу, обновить решение A, чтобы удалить таблицу из целевой системы, а затем повторно создать таблицу в решении B с издателем Y и импортировать решение B. Этот процесс приводит к потере всех данных, хранящихся в пользовательской таблице, если она не перенесена заранее.
  • Избегайте создания зависимостей между решениями. Зависимости определяют порядок импорта и могут создавать проблемы. Например, если у вас есть одно решение для таблиц и другое для облачных потоков, и поток зависит от пользовательского столбца, он будет работать в среде разработки, потому что столбец существует. Однако если в целевую среду импортируется только решение облачного потока, процесс импорта может не распознать зависимость от настраиваемого столбца. В результате решение для потока успешно устанавливается, но сам поток не работает. Дополнительные сведения: примеры зависимостей, созданных несколькими решениями

Примеры зависимостей, созданных несколькими решениями

  • Ленты интерфейса приложений. Если несколько решений изменяют ленту приложения или карту сайта одного приложения.
  • Плагины или облачные процессы. Если подключаемый модуль или поток запускается на пользовательском столбце или обновляет пользовательскую таблицу, объект зависит от этих пользовательских таблиц.
  • Роли безопасности. Если существуют индивидуальные таблицы, роли безопасности обычно зависят от этих таблиц для обеспечения доступа пользователей.

Несколько решений с выделенными средами разработки

Эта стратегия предполагает разработку каждого неуправляемого решения в отдельной изолированной среде разработки Dataverse. Эта стратегия обычно используется в модульных архитектурах, где, например, различные приложения, такие как продажи, обслуживание клиентов или служба полей, создаются и поддерживаются независимо. Базовое решение, содержащее общие компоненты (например, таблицы учетных записей и контактов), создается и развертывается в качестве управляемого решения в каждой среде разработки для конкретного приложения. Затем каждое приложение имеет собственное неуправляемое решение, наложенное поверх базового управляемого решения, что позволяет командам расширять функциональные возможности без изменения основы.

Рекомендуется для использования:

  • Крупномасштабные корпоративные проекты.
  • Команды с несколькими разработчиками или партнерами
  • Сценарии, требующие строгого управления и конвейеров CI/CD.
Преимущество Недостаток
Проще расти и развивать систему, добавляя или обновляя модули, не затрагивая других пользователей. Более высокие затраты на инфраструктуру и обслуживание.
Несколько команд могут работать параллельно с различными модулями, не конфликтуя с изменениями друг друга. Требуется надежная стратегия и управление средой.
Проще реализовать автоматизированное тестирование и методики DevOps. Более сложное развертывание.
Небольшие решения быстрее развертываются, особенно в конвейерах CI/CD, если необходимо развернуть только определенное приложение.
Ошибки или регрессии проще отслеживать при изоляции изменений в определенных модулях.

Создание слоев решения

Примечание

Прежде чем создавать решения на следующих шагах, используйте один и тот же издатель для всех решений в разных средах. Дополнительные сведения: Издатель решения

  1. В среде разработки «base» у вас есть базовое решение с общими неуправляемыми таблицами и без других таблиц. Затем экспортируйте это решение как управляемое.
  2. Вы настроили вторую среду разработки для уровня расширения или приложения, который позже будет находиться на базовом уровне.
  3. Вы импортируете управляемый базовый слой в среду разработки уровня приложений и создаёте неуправляемое решение для уровня приложений. Правильное многоуровневое решение с использованием нескольких решений в нескольких средах.
  4. Теперь модель данных можно расширить, добавив дополнительные таблицы, столбцы, связи таблиц, подключаемые модули, потоки и т. д. в конкретное решение app. Затем экспортируйте это решение приложения как управляемое. Обратите внимание, что решение приложения по-прежнему зависит от решения базового уровня, но управление несколькими решениями таким образом лучше подходит. Рассмотрим приведенный ранее пример потока, который зависит от пользовательского столбца. В большинстве случаев настраиваемый столбец и поток находятся в одном решении приложения. Но даже если настраиваемый столбец является частью базового решения, необходимо сначала завершить и развернуть это базовое решение как управляемое, иначе поток внутри решения приложения не может быть создан.
  5. В рабочей среде вы импортируете управляемый базовый слой, а затем импортируете управляемый слой приложения. Это создает два управляемых уровня в среде с четкими зависимостями между управляемыми решениями.
  6. Повторите этот шаблон, чтобы иметь столько различных решений, сколько вам нужно поддерживать. Хотя мы рекомендуем, чтобы количество решений было как можно меньшим, чтобы обеспечить управляемость многоуровневого решения.

Использование сегментации таблицы
Сценарий 5: поддержка коллективной разработки

  • Last updated on