Бөлісу құралы:

Сценарии использования Power BI: публикация корпоративного содержимого

  • Мақала

Примечание.

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

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

Примечание.

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

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

  1. Разработка содержимого и фиксация работы с удаленный репозиторий: создатели содержимого разрабатывают свое решение на своем компьютере. Они фиксируют и сохраняют свою работу в удаленный репозиторий через регулярные интервалы во время разработки. Удаленный репозиторий содержит последнюю версию решения, и она доступна всей команде разработчиков.
  2. Совместная работа и управление изменениями содержимого с помощью элемента управления версиями: другие создатели контента могут вносить изменения в решение, создавая ветвь. Ветвь является копией удаленный репозиторий. Когда эти редакции готовы и утверждены, ветвь объединяется с последней версией решения. Отслеживаются все редакции решения. Этот процесс называется управлением версиями (или системой управления версиями).
  3. Развертывание и повышение уровня содержимого с помощью конвейеров. В сценарии использования публикации контента самообслуживания контент будет повышен (или развертывается) с помощью рабочих областей разработки, тестирования и рабочей среды с помощью конвейеров развертывания Power BI. Конвейеры развертывания Power BI могут повысить уровень содержимого до рабочих областей Power BI Premium вручную с помощью пользовательского интерфейса или программно с помощью REST API. В отличие от этого, публикация корпоративного содержимого (фокус этого сценария использования) способствует контенту с помощью Azure Pipelines. Azure Pipelines — это служба Azure DevOps, которая автоматизирует тестирование, управление и развертывание содержимого с помощью ряда настраиваемых программных шагов. В сценарии публикации содержимого предприятия эти конвейеры также могут называться конвейерами непрерывной интеграции и развертывания (или CI/CD). Эти конвейеры часто и автоматически интегрируют изменения и упрощают публикацию содержимого.

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

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

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

  • REST API Power BI с конвейерами развертывания Power BI. Вы можете импортировать содержимое в рабочие области разработки и использовать конвейеры развертывания для развертывания содержимого с помощью тестовых и рабочих рабочих областей. Вы по-прежнему управляете развертыванием из Azure DevOps и используете REST API Power BI для управления конвейерами развертывания вместо отдельных элементов содержимого. Кроме того, вы используете конечную точку XMLA для развертывания метаданных модели данных вместо PBIX-файла Power BI Desktop с помощью Azure DevOps. Эти метаданные позволяют отслеживать изменения на уровне объектов с помощью управления версиями. Несмотря на более надежную и простую поддержку, этот подход требует лицензирования Premium и умеренных усилий по настройке импорта и развертывания контента с помощью REST API Power BI. Используйте этот подход, если вы хотите упростить управление жизненным циклом контента с помощью конвейеров развертывания, и у вас есть лицензия Premium. Конечная точка XMLA и конвейеры развертывания Power BI — это функции класса Premium.
  • REST API Power BI. Вы также можете импортировать содержимое в рабочие области разработки, тестирования и рабочей среды с помощью Azure DevOps и только REST API Power BI. Этот подход не требует лицензирования Premium, но он включает в себя высокие усилия по написанию скриптов и настройке, так как развертывание управляется за пределами Power BI. Используйте этот подход, если вы хотите централизованно развернуть содержимое Power BI из Azure DevOps или если у вас нет лицензии Premium. Визуальное сравнение первых двух подходов см. в схеме потоков конвейера выпуска.
  • Средства автоматизации Power BI с конвейерами развертывания Power BI: вы можете использовать расширение средств автоматизации Power BI Azure DevOps для управления конвейерами развертывания вместо REST API Power BI. Этот подход является альтернативой первому варианту, который использует REST API Power BI с конвейерами развертывания Power BI. Расширение средств автоматизации Power BI — это средство открытый код. Это помогает управлять и публиковать содержимое из Azure DevOps без необходимости писать скрипты PowerShell. Используйте этот подход, если вы хотите управлять конвейерами развертывания из Azure DevOps с минимальными усилиями по созданию скриптов и емкостью Premium.

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

Примечание.

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

Совет

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

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

Схема сценария

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

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

Совет

Мы рекомендуем скачать схему сценария, если вы хотите внедрить ее в презентацию, документацию или запись блога, или распечатать ее в виде стенного плаката. Так как это масштабируемое изображение векторной графики (SVG), его можно масштабировать вверх или вниз без потери качества.

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

Элемент Description
Элемент 1. Создатели содержимого разрабатывают модели данных с помощью Power BI Desktop или табличного редактора и разрабатывают отчеты с помощью Power BI Desktop. Создатели содержимого сохраняют свою работу в локальном репозитории во время разработки.
Элемент 2. Создатели содержимого могут клонировать удаленный репозиторий, чтобы получить локальную копию этого содержимого.
Элемент 3. Некоторым источникам данных может потребоваться локальный шлюз данных или шлюз виртуальной сети для обновления данных, например те, которые находятся в частной сети организации.
Элемент 4. Создатели содержимого регулярно фиксируют и помещают изменения в удаленный репозиторий во время разработки с помощью клиента Git, например Visual Studio Code. На схеме удаленный репозиторий — Azure Repos.
Элемент 5. Другие создатели содержимого используют Azure Repos для отслеживания изменений с помощью управления версиями. Они взаимодействуют путем фиксации изменений в отдельных ветвях.
Элемент 6. Изменения содержимого в удаленный репозиторий активируют Azure Pipelines. Конвейер проверки — это первый конвейер , который активируется. Конвейер проверки выполняет автоматические тесты для проверки содержимого перед публикацией.
Элемент 7. Содержимое, которое передает конвейер проверки, активирует последующий конвейер сборки. Конвейер сборки подготавливает содержимое для публикации в служба Power BI. Процесс до этой точки обычно называется непрерывной интеграцией (CI).
Элемент 8. Содержимое публикуется и развертывается с помощью конвейеров выпуска. Конвейеры выпуска используют REST API Power BI или конечную точку XMLA рабочей области для программного импорта содержимого в служба Power BI. Развертывание с помощью конвейеров выпуска обычно называется непрерывным развертыванием (CD).
Элемент 9. Диспетчер выпусков управляет развертыванием для тестирования и рабочих рабочих областей с помощью утверждения выпуска Azure Pipelines. В публикации корпоративного контента диспетчер выпусков обычно планирует и координирует выпуск содержимого для тестирования и рабочей среды. Они координируют и взаимодействуют с создателями контента, заинтересованными лицами и пользователями.
Элемент 10. Конвейер выпуска публикует содержимое в рабочей области разработки или способствует созданию содержимого от разработки до тестирования рабочих областей или тестирования рабочих областей.
Элемент 11. Создатели контента, работающие в рабочей области с лицензией емкости Fabric, могут использовать интеграцию Git. С интеграцией Git создатели содержимого могут работать в частной рабочей области во время разработки. Создатель содержимого синхронизирует удаленную ветвь (обычно определенную ветвь компонента или ветвь ошибок) из Azure Repos в частную рабочую область. Изменения содержимого синхронизируются между удаленной ветвью в Azure Repos и рабочей областью. В этом сценарии создатели содержимого не должны использовать Azure Pipelines для публикации содержимого. Создатели содержимого также могут регулярно фиксировать и отправлять изменения из рабочей области после публикации. Когда он будет готов, создатели содержимого могут выполнить запрос на вытягивание (PR), чтобы объединить изменения в главной ветви.
Элемент 12. При использовании интеграции Git рабочая область разработки синхронизируется с основной ветвью, чтобы получить последние версии содержимого. Это содержимое содержит все изменения из запросов на вытягивание, которые диспетчер выпусков проверяет, утверждает и объединяет.
Элемент 13. Рабочие области задаются в качестве емкости Fabric, емкости Premium, Premium на пользователя или режима лицензии Embedded, чтобы разрешить использование конвейеров развертывания Power BI и конечной точки чтения и записи XMLA.
Элемент 14. Администратор конвейера развертывания настраивает конвейер развертывания Power BI с тремя этапами: разработка, тестирование и рабочая среда. Каждый этап соответствует отдельной рабочей области в служба Power BI. Параметры развертывания и доступ задаются для конвейера развертывания.
Элемент 15. Рабочая область разработки содержит последние версии содержимого, включая все утвержденные и объединенные изменения. После утверждения конвейер выпуска развертывает содержимое из разработки в тестовую рабочую область.
Элемент 16. Рецензенты в рабочей области тестирования выполняют тестирование и обеспечение качества содержимого. После утверждения конвейер выпуска развертывает содержимое из теста в рабочую рабочую область. При использовании интеграции Git с конвейерами развертывания тестовая рабочая область не синхронизируется с какой-либо ветвью.
Элемент 17. После завершения развертывания конвейер развертывания создатели содержимого вручную выполняют действия после развертывания. Действия могут включать настройку запланированного обновления данных или обновление приложения Power BI для рабочей рабочей области. При использовании интеграции Git с конвейерами развертывания рабочая область не синхронизируется с какой-либо ветвью.
Элемент 18. Средства просмотра содержимого получают доступ к содержимому с помощью рабочей области или приложения Power BI.

Совет

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

Ключевые моменты

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

Управление версиями

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

Создатели содержимого обычно разрабатывают модели данных в табличном редакторе для поддержки более эффективного управления версиями. В отличие от модели данных, разработанной в Power BI Desktop, модель данных, разработанная в табличном редакторе , сохраняется в формате метаданных, доступных для чтения. Этот формат позволяет управлять версиями модели данных на уровне объекта. При совместной работе с несколькими людьми в одной модели данных следует использовать управление версиями на уровне объекта. Дополнительные сведения см. в сценарии использования расширенной модели данных. Невозможно увидеть изменения, внесенные в файл Power BI Desktop (PBIX), например определение отчета или модель данных. Например, нельзя отслеживать изменения страницы отчета, например визуальные элементы, их позиции и сопоставления полей или форматирование.

Создатели содержимого хранят файлы метаданных модели данных и PBIX-файлы в центральном удаленный репозиторий, например Azure Repos. Эти файлы курируются техническим владельцем. Хотя создатель контента разрабатывает решение, технический владелец отвечает за управление решением и просмотр изменений, а также объединение их в одно решение. Azure Repos предоставляет сложные возможности для отслеживания изменений и управления ими. Этот подход отличается от подхода, описанного в сценарии самостоятельной публикации контента, где создатель использует хранилище OneDrive с отслеживанием версий. Обслуживание хорошо курированного, документированного репозитория важно, так как это основа всего содержимого и совместной работы.

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

  • Область. Четко определите область репозитория. В идеале область репозитория идентичны область подчиненных рабочих областей и приложений, используемых для доставки содержимого потребителям.
  • Доступ. Необходимо настроить доступ к репозиторию с помощью аналогичной модели разрешений, так как вы настроили разрешения конвейера развертывания и роли рабочей области. Создатели содержимого должны получить доступ к репозиторию.
  • Документация. Добавьте текстовые файлы в репозиторий, чтобы документировать его назначение, владение, доступ и определенные процессы. Например, документация может описать этап и фиксацию изменений.
  • Средства. Для фиксации и отправки изменений в удаленный репозиторий создатели контента нуждаются в клиенте Git, например Visual Studio или Visual Studio Code. Git — это распределенная система управления версиями, которая отслеживает изменения в файлах. Сведения об основах Git см. в статье "Что такое Git?".

Примечание.

Если вы планируете зафиксировать файлы Power BI Desktop (PBIX), рекомендуется использовать служба хранилища больших файлов Git (LFS). Git LFS предоставляет дополнительные возможности для управления файлами, в которых изменения не отображаются (неуправляемые файлы), например PBIX-файл. Например, можно использовать блокировку файлов, чтобы предотвратить одновременные изменения отчета Power BI во время разработки. Однако Git LFS имеет собственный клиент и конфигурацию.

Совместная работа с Azure DevOps

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

Для совместной работы и взаимодействия в Azure DevOps используются вспомогательные службы.

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

Схема потока совместной работы

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

Схема, как описано в приведенном выше абзаце. Элементы на схеме описаны в таблице ниже.

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

Элемент Description
Элемент 1. Создатель контента создает новую, короткую ветвь, клонируя основную ветвь, которая содержит последнюю версию содержимого. Новая ветвь часто называется ветвью компонента , так как она используется для разработки определенной функции или устранения конкретной проблемы.
Элемент 2. Создатель содержимого фиксирует изменения в локальном репозитории во время разработки.
Элемент 3. Создатель контента связывает свои изменения с рабочими элементами, управляемыми в Azure Boards. Элементы работы описывают определенные разработки, улучшения или исправления ошибок, область в свою ветвь.
Элемент 4. Создатель контента регулярно фиксирует свои изменения. Когда он будет готов, создатель содержимого публикует свою ветвь в удаленный репозиторий.
Элемент 5. Чтобы протестировать изменения, создатель содержимого развертывает свое решение в изолированной рабочей области для разработки (не показанной на этой схеме). Создатель содержимого также может синхронизировать ветвь компонента с рабочей областью с помощью интеграции Fabric Git.
Элемент 6. Создатели контента и владельцы контента документирует решение и его процессы в вики-сайте Azure, который доступен всей команде разработчиков.
Элемент 7. Когда он будет готов, создатель содержимого открывает запрос на вытягивание, чтобы объединить ветвь компонента в основную ветвь.
Элемент 8. Технический владелец отвечает за проверку запроса на вытягивание и объединение изменений. При утверждении запроса на вытягивание они объединяют ветвь компонента в основную ветвь.
Элемент 9. Успешное слияние активирует развертывание решения в рабочей области разработки с помощью Azure Pipeline (не показанного на этой схеме). При использовании интеграции с Fabric Git основная ветвь синхронизируется с рабочей областью разработки.
Элемент 10. Диспетчер выпусков выполняет окончательный обзор и утверждение решения. Это утверждение выпуска предотвращает публикацию решения до его готовности. В публикации корпоративного контента диспетчер выпусков обычно планирует и координирует выпуск контента для тестирования и рабочих областей. Они координируют и взаимодействуют с создателями контента, заинтересованными лицами и пользователями.
Элемент 11. Когда диспетчер выпусков утверждает выпуск, Azure Pipelines автоматически подготавливает решение к развертыванию. Кроме того, Azure Pipeline может активировать конвейер развертывания для повышения содержимого между рабочими областями.
Элемент 12. Пользователи тестируют и проверяют содержимое в тестовой рабочей области. При использовании интеграции Git с Azure Pipelines для развертывания тестовая рабочая область не синхронизируется с какой-либо ветвью.
Элемент 13. После принятия и проверки изменений диспетчер выпусков выполняет окончательный обзор и утверждение решения для развертывания в рабочей рабочей области.
Элемент 14. Пользователи просматривают содержимое, опубликованное в рабочей области. При использовании интеграции Git с Azure Pipelines для развертывания рабочая область не синхронизируется с какой-либо ветвью.

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

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

Рекомендации по совместной работе

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

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

Внимание

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

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

REST API в Power BI

Вы разрабатываете программную логику для импорта и развертывания содержимого из Azure DevOps с помощью REST API Power BI. Импортируйте файлы Power BI (PBIX) в рабочую область с помощью операции импорта. Операция конвейера используется для развертывания содержимого или всего содержимого для тестирования или рабочих рабочих областей с помощью конвейеров развертывания Power BI. Программная логика определена в Azure Pipelines.

Рекомендуется использовать субъект-службу для вызова REST API Power BI в конвейерах. Субъект-служба предназначен для автоматической автоматической работы и не зависит от учетных данных пользователя. Однако некоторые элементы и действия не поддерживаются REST API Power BI или при использовании субъекта-службы, например потоков данных.

При использовании субъекта-службы необходимо тщательно управлять разрешениями. Ваша цель состоит в том, чтобы следовать принципу наименьшей привилегии. Необходимо задать достаточные разрешения для субъекта-службы без чрезмерной подготовки разрешений. Используйте Azure Key Vault или другую службу, которая безопасно хранит секреты и учетные данные субъекта-службы.

Внимание

Если у вас есть модель данных, сохраненная в виде формата метаданных, доступного для чтения, она не может быть опубликована с помощью REST API Power BI. Вместо этого необходимо опубликовать его с помощью конечной точки XMLA. Вы можете публиковать файлы метаданных с помощью сторонних средств, таких как интерфейс командной строки редактора табличного редактора(CLI). Вы также можете публиковать файлы метаданных программным способом с помощью собственной разработки .NET. Для разработки пользовательского решения требуется больше усилий, так как необходимо использовать расширение Microsoft Tabular Object Model (TOM) клиентских библиотек объектов управления анализом (AMO).

Azure Pipelines

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Элемент Description
Элемент 1. В первом подходе конвейеры выпуска публикуют содержимое с помощью конечной точки XMLA и REST API Power BI с конвейерами развертывания Power BI. Содержимое публикуется, а затем продвигается с помощью рабочих областей разработки, тестирования и рабочей среды. Конвейеры развертывания Power BI и конечная точка чтения и записи XMLA — это функции Premium.
Элемент 2. Успешное слияние ветви или завершение конвейера вышестоящий активирует конвейер сборки. Затем конвейер сборки подготавливает содержимое для публикации и запускает конвейер выпуска разработки.
Элемент 3. Конвейер выпуска разработки публикует содержимое в рабочей области разработки с помощью конечной точки XMLA (для метаданных модели данных) или REST API Power BI (для файлов Power BI Desktop, которые могут содержать модели данных и отчеты). Конвейер разработки использует интерфейс командной строки табличного редактора (CLI) для развертывания метаданных модели данных с помощью конечной точки XMLA.
Элемент 4. Триггер утверждения выпуска или триггера по запросу активирует конвейер тестового выпуска.
Элемент 5. Конвейер тестового выпуска развертывает содержимое с помощью операций развертывания REST API Power BI, которые запускают конвейер развертывания Power BI.
Элемент 6. Конвейер развертывания Power BI повышает содержимое из рабочей области разработки в тестовую рабочую область. После развертывания конвейер выпуска выполняет действия после развертывания с помощью REST API Power BI (не показан на схеме).
Элемент 7. Триггер утверждения выпуска или триггера по запросу активирует конвейер выпуска рабочей среды.
Элемент 8. Конвейер выпуска рабочей среды развертывает содержимое с помощью операций развертывания REST API Power BI, которые выполняют конвейер развертывания Power BI.
Элемент 9. Конвейер развертывания Power BI повышает содержимое из тестовой рабочей области в рабочую область. После развертывания конвейер выпуска выполняет действия после развертывания с помощью REST API Power BI (не показан на схеме).

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

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

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

Элемент Description
Элемент 1. Во втором подходе конвейеры выпуска публикуют содержимое с помощью конечной точки XMLA и rest API Power BI. Содержимое публикуется в рабочих областях разработки, тестирования и рабочей среды.
Элемент 2. Успешное слияние ветви или завершение конвейера вышестоящий активирует конвейер сборки. Затем конвейер сборки подготавливает содержимое для публикации и запускает конвейер выпуска разработки.
Элемент 3. Конвейер выпуска разработки публикует содержимое в рабочей области разработки с помощью конечной точки XMLA (для метаданных модели данных) или REST API Power BI (для файлов Power BI Desktop, которые могут содержать модели данных и отчеты). Конвейер разработки использует интерфейс командной строки табличного редактора (CLI) для развертывания метаданных модели данных с помощью конечной точки XMLA.
Элемент 4. Триггер утверждения выпуска или триггера по запросу активирует конвейер тестового выпуска.
Элемент 5. Конвейер выпуска разработки публикует содержимое в тестовой рабочей области с помощью конечной точки XMLA (для метаданных модели данных) или REST API Power BI (для файлов Power BI Desktop, которые могут содержать модели данных и отчеты). Конвейер разработки использует интерфейс командной строки табличного редактора (CLI) для развертывания метаданных модели данных с помощью конечной точки XMLA. После развертывания конвейер выпуска выполняет действия после развертывания с помощью REST API Power BI (не показан на схеме).
Элемент 6. Триггер утверждения выпуска или триггера по запросу активирует конвейер выпуска рабочей среды.
Элемент 7. Конвейер выпуска разработки публикует содержимое в рабочей рабочей области с помощью конечной точки XMLA (для метаданных модели данных) или REST API Power BI (для файлов Power BI Desktop, которые могут содержать модели данных и отчеты). Конвейер разработки использует интерфейс командной строки табличного редактора (CLI) для развертывания метаданных модели данных с помощью конечной точки XMLA. После развертывания конвейер выпуска выполняет действия после развертывания с помощью REST API Power BI (не показан на схеме).

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

Совет

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

Конвейеры развертывания Power BI

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

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

Совет

Если вы отделяете рабочие области данных от рабочих областей отчетов, рекомендуется использовать Azure Pipelines для оркестрации публикации содержимого с несколькими конвейерами развертывания Power BI. Семантическая модель развертывается сначала, а затем обновляется. Наконец, развертываются отчеты. Этот подход помогает упростить развертывание.

Лицензирование уровня "Премиум"

Конвейеры развертывания Power BI и конечная точка чтения и записи XMLA — это функции Premium. Эти функции доступны с емкостью Power BI Premium и Power BI Premium на пользователя (PPU).

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

Примечание.

Вы по-прежнему можете настроить публикацию корпоративного контента без лицензии Premium, как описано вторым подходом в разделе конвейера выпуска. Во втором подходе вы используете Azure Pipelines для управления развертыванием файлов Power BI Desktop для разработки, тестирования и рабочих областей. Однако невозможно развернуть метаданные модели с помощью конечной точки XMLA, так как невозможно опубликовать семантику формата метаданных с помощью REST API Power BI. Кроме того, невозможно повысить уровень содержимого в средах с конвейерами развертывания без лицензии Premium.

Установка шлюза

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

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

Примечание.

Централизованный шлюз данных в стандартном режиме настоятельно рекомендуется использовать через шлюзы в личном режиме. В стандартном режиме шлюз данных поддерживает динамическое подключение и операции DirectQuery (помимо запланированных операций обновления данных).

Системный надзор

Журнал действий записывает события, происходящие в служба Power BI. Администраторы Power BI могут использовать журнал действий для аудита действий развертывания.

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

Существует также журнал аудита в Azure DevOps, который находится за пределами служба Power BI. Администраторы Azure DevOps могут использовать журнал аудита для проверки действий в удаленных репозиториях и конвейерах.

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

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