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

Заметка

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

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

• администраторы Fabric: администраторы, ответственные за надзор за Fabric в организации. Администраторам Структуры может потребоваться совместная работа с другими администраторами, такими как те, кто контролирует 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 для Работы и Учебы и конвейеров развертывания Fabric.
• Планирование внедрения 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.
• Wiki 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, см. в интеграции проектов Power BI Desktop с 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 позволяет управлять развертыванием между всеми этапами. Благодаря этому подходу API-интерфейсы Fabric REST используются для развертывания и управления содержимым, используя различные конвейеры Azure Pipelines, такие как конвейеры проверки и выпуска.

Рассмотрите использование Azure Pipelines, когда:

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

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

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

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

Оркестрация конвейеров развертывания 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 с помощью Power BI REST API. Однако это связано с большим количеством усилий по настройке и сложности, так как необходимо управлять развертыванием за пределами Power BI. Команды разработчиков, которые уже используют DevOps для решений данных за пределами Power BI, могут ознакомиться с этим подходом. Группы разработчиков, использующие этот подход, могут консолидировать развертывание решений данных в Azure DevOps.

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

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

На следующей схеме показано, как развертывать содержимое с помощью интеграции 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.
• Выполните первоначальную настройку средств и процессов развертывания. Убедитесь, что вы настроили соответствующий доступ и что разрешения соответствуют настроенному доступу к вашему контенту.
• Разверните содержимое в рабочей среде: Когда вы запланировали и настроили развертывание, разверните содержимое в рабочей среде.

Связанное содержимое

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