Автоматизация развертываний с помощью интеграции и конвейеров Dataverse Git в Power Platform

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

Эта эталонная архитектура помогает решить эти задачи, объединяя встроенную интеграцию Git в Dataverse, конвейеры в Power Platform, средства управления в Azure DevOps и генерацию заметок о выпуске с помощью ИИ, чтобы создать повторно используемый шаблон управления жизненным циклом корпоративных приложений (ALM).

Диаграмма архитектуры

Workflow

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

Рабочий процесс разработки и контроля версий

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

1. Сопоставляйте каждый поток разработки с средой или ветвью компонентов Git.

2. Синхронизируйте изменения с Git через интеграцию Dataverse Git.

3. Проверяйте функциональные ветви и объединяйте их с основной ветвью Git с помощью запросов на вытягивание и политик защиты веток, когда они будут готовы к продвижению по производственному тестовому пути ALM.

4. Чтобы избежать расхождения функциональности, переносите изменения, принятые в основную ветвь, в ветви, соответствующие всем средам разработки.

5. Убедитесь, что основная ветвь стала единым достоверным источником для интеграции и продвижения релизов.

Рабочий процесс тестирования и проверки

1. Синхронизируйте изменения из основной ветви обратно в основную среду разработки. Используйте конвейеры в Power Platform для продвижения решения из основной среды разработки в тестовую среду.

2. Используйте тестовую среду для технической проверки, проверок интеграции и тестирования дыма.

3. После проверки продвигайте решение в среду пользовательского теста принятия (UAT) с помощью конвейеров в Power Platform. Создайте или обновите соответствующую релизную ветвь в Git на основе основной ветви.

4. Создайте заметки о выпуске на основе рабочих элементов DevOps со статусом UAT и распространите их среди тестировщиков, ответственных за UAT. Используйте агент Copilot Studio для создания и форматирования этих заметок о выпуске с помощью действия соединителя Azure DevOps Get Query Results.

5. Убедитесь, что UAT поддерживает проверку бизнес-требований и проверки готовности к выпуску перед утверждением для рабочей среды.

Процесс выпуска в промышленную среду

1. Перенесите утвержденные изменения UAT в рабочую среду с помощью конвейеров Power Platform.

2. Повторно создайте заметки о выпуске на основе рабочих элементов DevOps по статусам для стандартизированного информирования о выпуске.

3. Распространяйте заметки о выпуске техническим и деловым заинтересованным лицам через утвержденные каналы, такие как Teams, Outlook или SharePoint.

Процесс срочного исправления

1. Устраните срочные проблемы рабочей среды в выделенной среде исправлений.

2. Подключите среды исправлений к текущей производственной ветви выпуска Git через интеграцию Git с Dataverse.

3. Перенесите проверенные исправления в рабочую среду через тот же контролируемый механизм конвейера.

4. Объедините изменения исправлений из ветви выпуска обратно в основную ветвь, чтобы сохранить их в будущих выпусках.

Components

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

Интеграция Git в Power Platform

Роль в архитектуре:Интеграция Microsoft Dataverse с Git синхронизирует изменения решений из сред разработки в систему управления версиями на базе Git и обратно.

Почему выбрано:

• Обеспечивает ALM с поддержкой исходного кода для компонентов решения Dataverse
• Поддержка совместной работы группы на основе ветвей
• Уменьшение ручной обработки экспорта и импорта

Azure Repos, ветви и рабочие элементы

Роль в архитектуре:Azure DevOps содержит основную ветвь, ветви функций и ветви выпуска, а также обеспечивает контроль pull request (PR). Он также сохраняет рабочие элементы и служит структурированным источником для сведений об объёме выпуска и сводок изменений.

Почему выбрано:

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

Рассмотренные альтернативы: GitHub для репозиториев кода и рабочих элементов проекта

Почему эта архитектура отдает предпочтение Azure DevOps:
Хотя проекты GitHub могут обеспечивать гибкие возможности для отслеживания работы, такие как настраиваемые поля, представления дорожной карты и автоматизация, в этой архитектуре Azure Boards используется в качестве основного источника данных о рабочих элементах выпуска. В настоящее время Azure Boards предоставляет более широкие возможности для моделирования корпоративных процессов для рабочих элементов, определения области выпуска на основе общих запросов и языка запросов рабочих элементов (WIQL), а также более развитые встроенные средства отслеживания разработки и развертывания для управляемых процессов выпуска.

Конвейеры в Power Platform

Роль в архитектуре:Конвейеры в Power Platform позволяют перемещать решения между средами, включая пути продвижения исправлений.

Почему выбрано:

• Встроенный интерфейс развертывания Power Platform
• Оркестрация развертывания с учетом среды
• Доступно как администраторам платформы, так и группам решений

Альтернативные варианты рассматриваются:

• Оркестрация развертывания только в Azure DevOps или GitHub
• Полностью настраиваемая оркестрация конвейера с помощью интерфейса командной строки Power Platform (PAC CLI)

Почему эта архитектура предпочитает конвейеры в Power Platform:
Эта архитектура использует конвейеры в Power Platform в качестве основного механизма продвижения среды. Они снижают сложность конфигурации и специализированные требования к непрерывной интеграции и непрерывному развертыванию (CI/CD), предоставляя собственный, управляемый интерфейс развертывания для разработчиков, администраторов и профессиональных разработчиков.

Microsoft Copilot Studio

Роль в архитектуре: Агент Copilot Studio для создания примечаний к выпуску формирует стандартизированные примечания к выпуску на основе утверждённых рабочих элементов и контекста выпуска.

Почему выбрано:

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

Альтернативные варианты рассматриваются:

• Создание вручную на страницах электронной почты или вики-страниц
• Только шаблонная автоматизация без ИИ

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

Подробности сценария

Архитектура особенно ценна для организаций, которые должны поддерживать несколько сред разработки, работающих параллельно (DEV1, DEV2, DEVn), сохраняя общий, управляемый источник истины в Git. Каждая разработчик или небольшая команда могут работать в изолированной среде и синхронизировать изменения с помощью рабочих процессов на основе ветви, что позволяет командам работать без использования одной общей среды разработки.

Ценность для бизнеса

Ключевое значение, предоставленное этой архитектурой, включает:

• Система управления версиями как источник достоверной информации для настроек решения вместо среды создателя в роли авторитетного источника развертывания. Этот подход повышает согласованность и обеспечивает контролируемое продвижение в нижестоящие среды.

• Рекомендации по обеспечению безопасности, аудиту и соответствию с помощью рекомендаций по жизненному циклу разработки программного обеспечения (SDLC), включая управление версиями, проверки кода, возможность отслеживания изменений и интеграцию с процессами управления предприятиями.

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

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

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

• Операционная защита и возможность восстановления с помощью системы управления версиями, которая сохраняет журнал версий и поддерживает восстановление до предыдущих состояний при возникновении непредвиденных изменений.

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

Рекомендации

Эти соображения реализуют основы Power Platform Well-Architected — набора руководящих принципов, повышающих качество рабочей нагрузки. Дополнительные сведения см. в разделе Microsoft Power Platform Well-Architected.

Reliability

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

• Стандартизированный переход развертывания от среды разработки к тестовой и затем к промышленной среде
• Выделенный путь обработки исправлений с обеспечением прослеживаемости через ветвь выпуска
• Повторно используемые механизмы конвейера вместо ручных развертываний
• Этапы валидации перед выпуском в промышленную среду

Security

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

• Управление доступом на основе ролей в средах Power Platform и Azure DevOps
• Субъекты-службы или управляемые удостоверения для выполнения конвейера
• Ограниченные разрешения на развертывание в рабочей среде
• Действия слияния веток и выпуска с возможностью аудита
• Утвержденные каналы для распространения заметок о выпуске

Операционная эффективность

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

• Формализованная стратегия ветвления (функциональная, основная, релизная)
• Повторяющийся процесс продвижения по средам
• Стандартный шаблон обработки исправлений
• Автоматическое создание заметок о выпуске, интегрированное в рабочий процесс выпуска
• Снижение зависимости от институциональных знаний при коммуникации о выпусках

Эффективность работы

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

• Автоматическое развертывание и обмен данными о выпуске
• Сокращение затрат на координацию вручную
• Стандартизованный рабочий процесс для ускорения циклов выпуска
• Масштабирование до параллельных потоков DEVn без изменения системы управления

Оптимизация взаимодействия

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

• Рабочие процессы с выравниванием ролей
• Прогнозируемая модель продвижения
• Согласованный формат заметки о выпуске и время
• Минимизация неоднозначности в раздатках между командами

Взаимодействие улучшено для нескольких групп пользователей:

• Разработчики и создатели благодаря четко определенным рабочим процессам сред и ветвей
• Менеджеры выпусков благодаря стандартизированному продвижению и прослеживаемости
• Заинтересованные лица в сфере бизнеса благодаря понятным сводкам о выпусках, подготовленным с помощью ИИ
• Группы поддержки благодаря определенному маршруту исправлений

Ответственный подход к использованию ИИ

• Беспристрастность: функция ИИ создает сводку по утвержденным рабочим элементам релиза. Оно не принимает кадровые решения, не определяет соответствие критериям и не принимает решения, влияющие на клиентов.

• Надежность и безопасность: рецензенты человека проверяют содержимое перед распространением.

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

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

• Прозрачность: помечайте заметки о выпуске как созданные с помощью ИИ и указывайте проверенный источник достоверной информации с привязкой к исходным рабочим элементам в DevOps.

• Подотчетность. Именованный владелец выпуска или утверждающий развертывание остается ответственным за окончательное содержимое выпуска и решения о рабочем развертывании.

Дальнейшие действия

1. Подключите среды разработки Dataverse к репозиторию Git.
2. Запланируйте структуру и стратегию Azure DevOps организации.
3. Извлекать рабочие элементы из DevOps с помощью Copilot Studio, используя коннекторы как инструменты.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Ник Талсма, технический архитектор Power Platform

Связанные ресурсы

• Настройка интеграции Git с Dataverse
• Планирование структуры организации
• Использование соединителей Power Platform в качестве инструментов