Планирование реализации Power BI: развертывание содержимого

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

• Администраторы Структуры: администраторы, ответственные за надзор за Структурой в организации. Администраторам Структуры может потребоваться совместная работа с другими администраторами, такими как те, кто контролирует Microsoft 365 или Azure DevOps.
• Центр превосходства (COE) и группы бизнес-аналитики: команды, ответственные за надзор за Power BI в организации. К этим командам относятся лица, принимающие решения, которые решают, как управлять жизненным циклом содержимого Power BI. Эти команды также могут включать руководителей выпусков, которые обрабатывают жизненный цикл выпусков содержимого и инженеров, которые создают и управляют компонентами, необходимыми для эффективного использования и поддержки управления жизненным циклом.
• Создатели контента и владельцы контента: пользователи, которые создают содержимое, которое они хотят опубликовать на портале Fabric, чтобы поделиться с другими пользователями. Эти лица отвечают за управление жизненным циклом создаваемого содержимого Power BI.

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

Чтобы предоставить доступ к содержимому Power BI потребителям, необходимо сначала опубликовать (или развернуть) содержимое в рабочей области Fabric. Развертывание содержимого также включает перемещение содержимого между средами, например развертывание из рабочей области разработки в тестовую рабочую область или из тестовой рабочей области в рабочую область.

На следующем рисунке показан жизненный цикл содержимого Power BI, выделение этапа четыре, в котором выполняется развертывание содержимого.

Примечание.

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

В этой статье рассматриваются основные аспекты и решения по развертыванию содержимого на протяжении всего жизненного цикла. Дополнительные сведения о развертывании содержимого см. в следующем разделе:

• Миграция в Power BI. Развертывание содержимого. В этой статье описываются ключевые аспекты и решения по развертыванию при миграции в Power BI из других технологий.
• Планирование решения бизнес-аналитики: развертывание, поддержка и мониторинг. В этой статье описывается, как планировать развертывание при первом создании решения Power BI или Fabric.
• Планирование реализации Power BI: сценарий самостоятельной публикации контента. В этой статье описывается, как самостоятельно пользователи могут развертывать содержимое с помощью конвейеров развертывания OneDrive для работы и школы и структуры.
• Планирование реализации Power BI: корпоративный сценарий публикации контента. В этой статье описывается, как центральные команды могут развертывать содержимое и управлять ими с помощью Azure DevOps.

Вы развертываете содержимое в двух основных точках жизненного цикла содержимого:

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

В следующих разделах описаны подходы к публикации или продвижению содержимого.

Определите способ публикации содержимого

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

Примечание.

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

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

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

Публикация с помощью Power BI Desktop

Power BI Desktop позволяет пользователям публиковать семантические модели и отчеты с локального компьютера в рабочую область на портале Fabric. Этот подход является самым простым способом публикации содержимого; однако его нельзя автоматизировать.

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

• Создатели содержимого предпочитают вручную управлять публикацией содержимого на портале Fabric.
• Создатели содержимого используют Power BI Desktop для разработки содержимого и управления ими.
• Создатели содержимого не знакомы с Azure DevOps или Git.
• Содержимое состоит только из семантических моделей или отчетов.

Публикация с помощью сторонних средств

Сторонние средства позволяют создателям содержимого публиковать семантику модели с помощью конечной точки чтения и записи в рабочей области XMLA. Например, создатель содержимого использует табличный редактор для разработки метаданных модели и управления ими, таких как TMDL (язык определения табличной модели) или BIM-файлы.

Совет

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

Дополнительные сведения о включении и использовании конечных точек чтения и записи XMLA см. в разделе "Подключение семантической модели" к конечной точке XMLA.

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

• Создатели содержимого предпочитают вручную управлять публикацией содержимого на портале Fabric.
• Создатели содержимого используют стороннее средство для разработки и управления содержимым.
• Содержимое будет опубликовано в рабочей области, которая использует Premium на пользователя (PPU), емкость Premium или режим лицензии емкости Fabric.
• Создатели содержимого не знакомы с Azure DevOps или Git.
• Содержимое состоит только из семантических моделей.

Публикация с помощью обновления OneDrive

OneDrive позволяет создателям контента самообслуживания автоматически публиковать семантические модели или отчеты в рабочую область на портале Fabric с помощью обновления OneDrive. Создатели содержимого могут сохранять файлы Power BI Desktop (PBIX) в общую библиотеку в OneDrive. Общая библиотека также может быть библиотекой документов SharePoint или Microsoft Teams.

Совет

Дополнительные сведения об использовании OneDrive для работы и учебного заведения с содержимым Power BI см. в сценарии самостоятельной публикации контента.

Дополнительные сведения о настройке обновления OneDrive см. в статье Об обновлении семантической модели, хранящейся в OneDrive или SharePoint Online.

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

• Создатели содержимого хотят автоматизировать публикацию контента на портале Fabric.
• Создатели содержимого не знакомы с Azure DevOps или Git.
• Создатели содержимого выполняют управление версиями содержимого с помощью OneDrive или SharePoint.
• Создатели содержимого сохраняют семантические модели и отчеты в виде PBIX-файлов.
• Содержимое состоит только из семантических моделей или отчетов.

Публикация с помощью интеграции Git Fabric

Интеграция Fabric Git — это монопольная функция для емкостей Fabric, которая позволяет создателям содержимого синхронизировать ветвь из удаленного репозитория Git в рабочую область Fabric. Интеграция Git с Azure DevOps можно использовать для синхронизации содержимого из Azure Repos или развертывания содержимого с помощью Azure Pipelines (описано в следующем разделе).

Примечание.

Azure DevOps — это набор служб, которые интегрируются с Power BI и Fabric для планирования и оркестрации управления жизненным циклом контента. При использовании Azure DevOps таким образом обычно используются следующие службы:

• Azure Repos: позволяет создавать и использовать удаленный репозиторий Git, который является расположением удаленного хранилища, которое используется для отслеживания изменений содержимого и управления ими.
• Azure Pipelines: позволяет создавать и использовать набор автоматизированных задач для обработки, тестирования и развертывания содержимого из удаленный репозиторий рабочей области.
• Планы тестирования Azure. Позволяет разрабатывать тесты для проверки решения и автоматизации контроля качества вместе с Azure Pipelines.
• Azure Boards: позволяет использовать доски для отслеживания задач и планов в качестве рабочих элементов, а также ссылки на рабочие элементы из других служб Azure DevOps.
• Вики-сайт Azure. Вы можете поделиться информацией со своей командой, чтобы понять и внести свой вклад в контент.

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

Совет

Дополнительные сведения о том, как использовать интеграцию Fabric Git для развертывания содержимого Power BI, см. в сценарии использования публикации корпоративного контента.

Дополнительные сведения о настройке интеграции Git см. в руководстве по управлению жизненным циклом в проектах Fabric и Power BI Desktop: интеграция с Git.

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

• Создатели содержимого знакомы с Azure DevOps и Git.
• Создатели содержимого используют Azure DevOps для совместной работы и управления версиями.
• Создатели содержимого сохраняют семантические модели и отчеты в виде файлов проекта Power BI (PBIP ).
• Содержимое будет опубликовано в рабочей области в емкости Fabric.
• Содержимое состоит из поддерживаемых типов элементов функцией интеграции Git.
• Содержимое не имеет меток конфиденциальности.

Примечание.

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

Публикация с помощью Azure Pipelines

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

Совет

Содержимое можно развернуть с помощью Azure Pipelines и REST API Power BI в рабочих областях, которые не используют емкость Fabric или Premium. Однако ИНТЕРФЕЙСы REST API Fabric работают только с Fabric, а конечные точки XMLA работают только с емкостью Fabric или Premium.

Дополнительные сведения о том, как использовать Azure Pipelines для развертывания содержимого Power BI, см. в сценарии использования публикации корпоративного контента.

Дополнительные сведения о том, как интегрировать Azure DevOps с Power BI, см. в статье "Проекты Azure DevOps" и конвейеры сборки.

Рекомендуется использовать Azure Pipelines для оркестрации развертывания содержимого при:

• Создатели содержимого знакомы с Azure DevOps и ИНТЕРФЕЙСами REST API Fabric.
• Создатели содержимого используют Azure DevOps для совместной работы и управления версиями.
• Создатели содержимого не используют интеграцию Fabric Git.

Azure Pipelines и другие средства на основе кода могут программно развертывать содержимое с помощью одного или нескольких следующих API или конечных точек:

• REST API Power BI. Существуют разные конечные точки REST API Power BI, которые можно использовать для развертывания содержимого. REST API Power BI поддерживают только типы элементов Power BI.
  • Импорт. Вы можете публиковать поддерживаемые элементы с помощью REST API Power BI для импорта допустимого исходного файла в рабочую область (например, PBIX-файл).
  • Развертывание. Вы можете развернуть поддерживаемые элементы, продвигая их из одной рабочей области в другую, если они этапы в конвейере развертывания.
• ИНТЕРФЕЙСы REST API Fabric. Существуют различные конечные точки REST API Fabric, которые можно использовать для развертывания содержимого. ИНТЕРФЕЙСы REST API Fabric поддерживают типы элементов Power BI и Fabric.
  • Создание: вы можете создавать поддерживаемые элементы с помощью REST API Fabric вместе с допустимым определением элемента.
  • Обновление из Git. Вы можете обновить рабочую область с содержимым из удаленный репозиторий, подключенной с помощью интеграции Git.
• Конечные точки чтения и записи XMLA: можно создавать или изменять семантические модели с помощью конечных точек XMLA вместе с допустимым файлом model.bim. Конечные точки XMLA позволяют развертывать изменения в конкретных объектах модели вместо всей модели. Azure Pipelines может использовать сторонние средства (например, интерфейс командной строки табличного редактора) для развертывания семантических моделей с помощью конечных точек XMLA.

Совет

При использовании REST API Fabric или Power BI необходимо сначала создать регистрацию приложений в Azure (описано здесь для Power BI Embedded). Для этого требуется клиент Идентификатора Microsoft Entra и пользователь организации, и может быть сложным процессом для настройки соответствующих разрешений. Однако rest API Fabric можно выполнять в записных книжках без создания регистрации приложения. Это упрощает настройку и использование API в решениях, чтобы вам не нужно было управлять учетными данными или настраивать настройку перед использованием API.

Чтобы использовать ИНТЕРФЕЙСы REST API Fabric без регистрации приложения, используйте семантику ссылки в записной книжке Fabric с помощью FabricRestClientClass sempy для вызова API.

Вместе с автоматизированным тестированием интеграция Azure Pipelines с Power BI помогает достичь непрерывной интеграции и непрерывного развертывания (CI/CD).

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

Существует три типа Azure Pipelines, которые можно настроить для тестирования, управления и развертывания решения Power BI.

• Конвейеры проверки
• Конвейеры сборки
• Конвейеры выпуска

Примечание.

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

Конвейеры проверки

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

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

Конвейеры сборки

Сборка конвейеров подготавливает модели данных для публикации в служба Power BI. Эти конвейеры объединяют сериализованные метаданные модели в один файл, который позже публикуется конвейером выпуска. Конвейер сборки также может вносить изменения в метаданные, например изменять значения параметров. Конвейеры сборки создают артефакты развертывания, состоящие из метаданных модели данных (для моделей данных) и файлов проекта Power BI (PBIP), готовых к публикации в служба Power BI.

Конвейеры выпуска

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

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

Определите, как повысить уровень содержимого между рабочими областями

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

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

Внимание

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

Развертывание с помощью конвейеров развертывания Fabric

Конвейеры развертывания позволяют настроить два или более этапов (например, разработку, тестирование или рабочую среду) и развернуть содержимое Fabric между этими этапами. Администратор конвейера назначает одну рабочую область Power BI каждому этапу в конвейере развертывания. Использование конвейеров развертывания зависит от способа настройки и использования рабочих областей.

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

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

Рассмотрим другой подход, чем конвейеры развертывания, когда:

• Вы предпочитаете развертывать содержимое из удаленный репозиторий, например с помощью Azure Pipelines.
• Вы планируете использовать интеграцию Git для синхронизации различных этапов с разными ветвями удаленный репозиторий вместо развертывания содержимого.

Совет

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

Дополнительные сведения о конвейерах развертывания см. в статье "Конвейеры развертывания". Общие сведения о процессе развертывания.

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

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

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

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

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

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

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

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

Совет

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

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

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

Выполнение развертывания вручную

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

Внимание

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

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

Использование REST API Power BI для выполнения развертывания

Rest API Power BI можно использовать для развертывания содержимого с помощью конвейера развертывания. Преимущество использования REST API заключается в том, что вы можете автоматизировать развертывание и интегрировать его с другими средствами, такими как Azure Pipelines в Azure DevOps.

Развертывание с использованием Azure Pipelines

Azure Pipelines позволяет управлять развертыванием между всеми этапами. Благодаря этому подходу интерфейсы REST API Fabric используются для развертывания содержимого и управления ими, используя различные конвейеры проверки и выпуска Azure Pipelines.

При использовании Azure Pipelines рекомендуется использовать:

• Вы хотите централизировать оркестрацию развертывания из Azure DevOps.
• Создатели содержимого используют Azure DevOps для совместной работы и управления версиями.

Рассмотрим другой подход, чем Azure Pipelines, когда:

• Создатели содержимого не знакомы с развертываниями Azure DevOps или на основе кода.
• Содержимое включает типы элементов, которые не имеют поддерживаемого формата определения или исходного файла, например панелей мониторинга.

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

Конвейеры развертывания Orchestrate Fabric с помощью Azure Pipelines

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

На следующей схеме показано, как оркестрировать конвейеры развертывания из Azure Pipelines.

В итоге создатели содержимого публикуют содержимое в рабочей области на первом этапе конвейера развертывания. Затем диспетчер выпусков утверждает развертывание, которое активирует Azure Pipeline. Этот конвейер использует REST API Power BI для повышения содержимого между этапами, чтобы метаданные развертывались в другой рабочей области. Одним из преимуществ этого подхода является оркестрация развертывания нескольких типов элементов Fabric с помощью конвейеров развертывания, так как некоторые типы элементов разрабатываются на портале Fabric и поэтому не могут быть развернуты только Azure Pipelines.

Развертывание содержимого с помощью только Azure Pipelines

Вы также можете развернуть содержимое в рабочей области из Azure DevOps с помощью Azure Pipelines. Этот подход не использует конвейеры развертывания. Вместо этого он использует конвейеры выпуска для развертывания исходных файлов или файлов метаданных с помощью ИНТЕРФЕЙСов REST API Fabric или Power BI или конечных точек чтения и записи XMLA. Как правило, эти файлы хранятся в репозитории Azure Repos Git.

На следующей схеме показано, как развертывать содержимое с помощью только Azure Pipelines.

В итоге создатели контента фиксируют и отправляет изменения содержимого в удаленный репозиторий Git в Azure Repos. Это содержимое используется Azure Pipelines для развертывания. После утверждения конкретного развертывания диспетчер выпуска Azure Pipeline развернет содержимое в рабочей области с помощью REST API Power BI (то есть для PBIX-файлов), REST API Fabric (то есть для определений элементов) или конечных точек XMLA (то есть для файлов model.bim). Для каждой рабочей области существует отдельный Azure Pipeline.

Этот подход не требует лицензирования Fabric или premium при публикации только файлов Power BI Desktop с помощью REST API Power BI. Однако это связано с большим количеством усилий по настройке и сложности, так как необходимо управлять развертыванием за пределами Power BI. Команды разработчиков, которые уже используют DevOps для решений данных за пределами Power BI, могут ознакомиться с этим подходом. Группы разработчиков, использующие этот подход, могут консолидировать развертывание решений данных в Azure DevOps.

Развертывание с помощью интеграции с Fabric Git

При использовании интеграции Git можно синхронизировать различные ветви с разными рабочими областями, а не публиковать или развертывать содержимое явным образом. Таким образом, можно использовать отдельные ветви для разработки, тестирования и рабочей рабочей области. В этом сценарии основная ветвь синхронизируется с рабочей областью. Затем вы развертываете содержимое между рабочими областями, выполняя запрос на вытягивание, чтобы объединить ветвь разработки в тестовую ветвь (чтобы развернуть в тестовой рабочей области) или объединить тестовую ветвь в основную ветвь (для развертывания в рабочей рабочей области).

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

В итоге создатели контента фиксируют и отправляет изменения содержимого в удаленный репозиторий Git в Azure Repos. Создатели содержимого открывают запросы на вытягивание (PR), чтобы запросить объединение изменений в определенную ветвь. В зависимости от стратегии ветвления различные ветви связаны с разными рабочими областями. После объединения изменений в ветвь создатели содержимого синхронизируют рабочую область с удаленным репозиторием Git, чтобы просмотреть последние изменения содержимого в этой рабочей области.

Рассмотрим этот подход, когда:

• Вы хотите управлять развертыванием между рабочими областями с помощью стратегии ветвления и объединения.
• Вы не планируете использовать конвейеры развертывания Azure Pipelines или Fabric для оркестрации развертываний для тестирования и рабочей среды.
• Рабочая область не содержит неподдерживаемых элементов или сценариев.
• Содержимое не имеет меток конфиденциальности.

Примечание.

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

Например, содержимое можно развернуть в рабочей области разработки с помощью Azure Pipeline, что позволяет воспользоваться функциями непрерывной интеграции и проводить автоматическое тестирование (например, с помощью анализатора рекомендаций). Затем можно развернуть содержимое между рабочими областями с помощью интеграции Git или конвейера развертывания Fabric.

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

Определите, как обрабатывать действия после развертывания

После развертывания выполняются различные действия после развертывания. Многие из этих действий можно обрабатывать программным способом, например с помощью Azure Pipeline или записной книжки и ИНТЕРФЕЙСов REST API Power BI и Fabric. Например, можно программно задать учетные данные источника данных, управлять запланированным обновлением и запускать обновления после развертывания метаданных. Однако для некоторых задач требуется вмешательство вручную, например при первой настройке или обновлении приложения Power BI.

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

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

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

• Определите варианты развертывания, доступные вам. В зависимости от лицензирования и содержимого вы сможете публиковать содержимое или продвигать его между рабочими областями. Определите, можно ли использовать конвейеры развертывания, Azure DevOps, интеграцию Git, ИНТЕРФЕЙСы REST API Fabric и конечные точки чтения и записи XMLA.
• Определите способ публикации содержимого: выберите подход к публикации контента, который лучше всего подходит для рабочего процесса и потребностей. Убедитесь, что этот подход соответствует другим стратегиям, таким как отслеживание изменений и управление ими.
• Определите способ продвижения содержимого между рабочими областями: выберите подход к развертыванию содержимого из разработки в тестовые рабочие области и от тестирования до рабочих областей. Убедитесь, что этот подход соответствует другим стратегиям, таким как публикация содержимого.
• Планирование стратегии выпуска: определите, будет ли конкретный человек отвечать за окончательный обзор содержимого перед утверждением выпуска или развертывания. Убедитесь, что этот человек знает об этой задаче и что они должны сделать для защиты процесса развертывания, не блокируя ход выполнения.
• Планирование действий после развертывания. Убедитесь, что вы решили выполнить действия, такие как обновление приложения Power BI или обновление элементов данных после развертывания метаданных. Рассмотрите возможность автоматизации этого процесса с помощью REST API Fabric.
• Сначала настройте средства и процессы развертывания: убедитесь, что вы настроили соответствующий доступ, а разрешения соответствуют настройке доступа к содержимому.
• Развертывание содержимого в рабочей среде: когда вы планируете и настроили развертывание, разверните содержимое в рабочей среде.

Связанный контент

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