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

Примечание.

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

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

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

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

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

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

Примечание.

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

Совет

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

• Что такое управление жизненным циклом в Microsoft Fabric?: в этой статье приведены технические сведения и учебники по интеграции и развертыванию Fabric Git.
• Рекомендации по управлению жизненным циклом. В этой статье содержатся практические советы и рекомендации по использованию функций управления жизненным циклом Fabric и Power BI для разработки содержимого и управления изменениями.
• Интеграция с Power BI Desktop OneDrive и SharePoint. В этой статье содержится обзор вариантов использования и хранения файлов, сохраненных в OneDrive для работы и учебного заведения или SharePoint при выполнении управления версиями с PBIX-файлами.
• Начало работы с Git в Azure Repos. В этой серии статей содержатся практические советы, руководства и рекомендации по управлению версиями с помощью репозитория Git в Azure Repos.

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

Другие преимущества управления версиями включают возможность:

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

Совет

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

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

Определите, как разрабатывать содержимое

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

Совет

При разработке семантических моделей и отчетов с помощью Power BI Desktop рекомендуется использовать PBIP-файлы вместо PBIX-файлов. При разработке семантических моделей с помощью средств XMLA рекомендуется использовать формат языка определения табличной модели (TMDL) вместо BIM-файлов.

Форматы PBIP и TMDL поддерживают более простое отслеживание и слияние изменений на уровне объектов. Это означает, что вы можете просматривать изменения отдельных объектов и управлять ими, например меры ИЛИ таблицы DAX.

Power BI Desktop

Power BI Desktop можно использовать для создания семантических моделей или отчетов, которые можно сохранить как PBIX-файлы или PBIP-файлы. Существуют дополнительные пользовательские файлы содержимого, которые также могут использоваться при использовании Power BI Desktop.При использовании Power BI Desktop для создания содержимого некоторые ключевые решения, которые следует принять:

• Какой формат файла следует использовать: можно сохранить содержимое в виде PBIX-файлов или PBIP-файлов. Например, интеграция Git требует, чтобы вы использовали PBIP-файлы, создатели самообслуживания могут найти PBIX-файлы проще для управления и обслуживания в Teams, SharePoint или OneDrive.
• Управление пользовательским содержимым. Вы можете добавлять темы, пользовательские визуальные элементы или изображения в файлы Power BI Desktop, которые могут потребовать различных рекомендаций по управлению жизненным циклом. Например, когда создатели содержимого делают собственные пользовательские визуальные элементы, они должны сохранять и управлять определением визуального элемента в отдельном файле.
• Как управлять функциями предварительной версии: вы можете выбрать предварительный просмотр функций или параметров в Power BI Desktop, которые изменяют содержимое и способ его использования. Например, можно выполнить дополнительные действия для проверки содержимого, использующего предварительные версии функций.

Веб-разработка

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

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

Совет

При разработке потоков данных и оценки карта рекомендуется получить определения элементов для управления изменениями и хранения резервной копии. Вы можете автоматизировать поток данных и оценку карта получить с помощью ИНТЕРФЕЙСов REST API Fabric. В частности, можно использовать конечные точки Get Dataflow и Get Score карта s соответственно.

Внимание

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

Другие средства

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

• Visual Studio или Visual Studio Code: интегрированная среда разработки для разработчиков для создания семантических моделей или записных книжек Fabric и управления ими. С помощью Visual Studio и Visual Studio Code разработчики также могут выполнять управление версиями (SCM), зафиксировав и принудив локальные изменения к удаленный репозиторий.
• Табличный редактор: стороннее средство для разработки и управления семантических моделей.
• Excel: клиентское средство для сводных таблиц и динамических подключенных таблиц, работающих с семантической моделью.
• Power BI построитель отчетов: классическое приложение для создания файлов отчета с разбивкой на страницы (RDL).

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

• Управление лицензиями. Для управления другими инструментами могут потребоваться дополнительные лицензии, которыми следует управлять.
• Как опубликовать содержимое. Другие средства могут потребовать дополнительных шагов для публикации содержимого, например с помощью конечных точек XMLA или REST API Power BI.

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

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

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

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

В Fabric и Power BI рекомендуется использовать отдельные рабочие области Fabric, как описано в статьях планирования на уровне клиента и рабочей области.

Внимание

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

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

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

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

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

Примечание.

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

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

Дополнительные сведения об этих подходах к развертыванию содержимого см . на этапе 4. Развертывание содержимого далее в этой серии.

Тестовые и рабочие рабочие области

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

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

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

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

Примечание.

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

Разработка, тестирование и рабочие рабочие области

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

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

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

Элемент	Description
	Создатели содержимого разрабатывают содержимое в локальной среде.
	После готовности создатели содержимого публикуют содержимое в рабочей области разработки. В рабочей области разработки создатели контента могут разрабатывать содержимое, которое можно создавать только с помощью веб-разработки. Создатели содержимого также могут проверять содержимое в рабочей области разработки.
	После готовности создатели содержимого развертывают содержимое в тестовой рабочей области. В тестовой рабочей области пользователи проверяют содержимое в рабочей области или приложении.
	После готовности создатели содержимого развертывают содержимое в рабочей рабочей области. В рабочей области создатели содержимого распространяют содержимое, публикуя приложение Power BI или предоставляя общий доступ к содержимому из рабочей области.

Примечание.

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

Частная рабочая область с интеграцией Git

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

Примечание.

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

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

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

Примечание.

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

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

Элемент	Description
	Каждый создатель контента разрабатывает содержимое в собственной локальной среде.
	После готовности создатели содержимого фиксируют и помещают изменения в удаленный репозиторий, например репозиторий Azure Repos Git.
	В удаленном репозитории Git создатели содержимого отслеживают изменения содержимого и управляют ими с помощью системы управления версиями, а также ветви и слияния содержимого для упрощения совместной работы.
	Создатели содержимого синхронизируют ветвь удаленный репозиторий с частной рабочей областью. После синхронизации последние изменения, которые создатель фиксирует и отправляет в ветвь, отображаются в этой частной рабочей области. Различные создатели контента работают самостоятельно, отдельные ветви по мере внесения изменений.
	В частных рабочих областях создатели контента могут разрабатывать содержимое с помощью веб-разработки и проверять свои изменения. Изменения содержимого, сделанного веб-разработчиком, могут синхронизироваться с ветвью в репозитории Git, когда создатель содержимого фиксирует и отправляет эти изменения из рабочей области. Разные создатели контента работают в своих собственных частных рабочих областях.
	После готовности создатели содержимого выполняют запрос на вытягивание, чтобы объединить изменения в основную ветвь решения.
	После объединения изменений основная ветвь синхронизируется с рабочей областью разработки.
	В рабочей области разработки создатели содержимого могут разрабатывать содержимое, которое не поддерживается интеграцией Git Fabric, например панелями мониторинга. Создатели содержимого также проверяют интегрированное решение, содержащее все последние изменения.
	После готовности создатели содержимого развертывают содержимое в тестовой рабочей области. В тестовой рабочей области пользователи выполняют приемочное тестирование содержимого.
	После готовности создатели содержимого развертывают содержимое в рабочей рабочей области. В рабочей области создатели содержимого распространяют содержимое, публикуя приложение Power BI или предоставляя общий доступ к содержимому из рабочей области.

Поддержка ресурсов для рабочих областей

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

• Шлюзы. Рекомендуется использовать отдельные локальные кластеры шлюзов данных и шлюзы виртуальной сети для рабочих нагрузок. Это полезно для предотвращения нарушений, но и для обеспечения времени простоя, когда необходимо обновить эти шлюзы.
• Приложения. Рассмотрите возможность разделения приложений для тестовых и рабочих рабочих областей. Невозможно развертывать или копировать приложения между этапами. Приложения в тестовой рабочей области предназначены для тестирования содержимого и взаимодействия с приложением перед развертыванием изменений в рабочей рабочей области. Приложения в рабочей рабочей области предназначены для доставки содержимого конечным пользователям в структурированном и интерфейсном интерфейсе.
• Azure DevOps. Если вы планируете использовать Azure DevOps для совместной работы и оркестрации системы управления версиями и развертывания, рассмотрите способ использования ветвей и Azure Pipelines для развертывания содержимого между этими средами. Дополнительные сведения об использовании Azure Pipelines для развертывания содержимого см . на этапе 4. Развертывание содержимого.

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

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

В Power BI можно управлять версиями с помощью SharePoint/OneDrive или с помощью удаленного репозитория Git, например Azure Repos, который является компонентом Azure DevOps. В обоих подходах вы добавляете локальные файлы содержимого в удаленное хранилище для отслеживания изменений и управления ими. Рекомендуется использовать SharePoint или OneDrive только для небольших и простых проектов, так как не хватает функций и надежности для поддержки более крупных или более сложных сценариев.

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

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

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

Управление версиями с помощью SharePoint или OneDrive для работы и учебного заведения

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

Совет

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

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

На схеме описаны следующие процессы и компоненты.

Элемент	Description
	Создатели содержимого разрабатывают семантические модели и отчеты в локальной среде и сохраняют эти модели и отчеты в виде PBIX-файлов.
	После готовности создатели содержимого сохраняют изменения, которые синхронизируются с удаленной библиотекой SharePoint или OneDrive для работы и учебного заведения.
	В удаленной библиотеке создатели содержимого отслеживают изменения на уровне файлов, которые упрощают управление версиями.
	Создатели содержимого могут связать опубликованную семантику или отчет с PBIX-файлом, чтобы упростить обновление OneDrive. Обновление OneDrive автоматически публикует изменения содержимого каждый час.
	В рабочей области Fabric создатели содержимого видят изменения содержимого Power BI после завершения обновления OneDrive.

Внимание

Управление версиями можно выполнять только с помощью файлов SharePoint или OneDrive для Power BI Desktop, содержащих семантические модели или отчеты. Невозможно легко управлять версиями с помощью SharePoint или OneDrive для других типов элементов Power BI, таких как потоки данных, или для типов элементов Fabric, таких как записные книжки. Для этих других типов элементов следует выполнять управление версиями с помощью удаленного репозитория Git, например Azure Repos.

Чтобы свести к выводу, создатели содержимого могут связать опубликованную семантику или отчет с PBIX-файлом, хранящимся в библиотеке SharePoint или OneDrive для работы и учебного заведения. При таком подходе создатели содержимого больше не должны публиковать семантику модели, чтобы увидеть изменения. Вместо этого изменения отображаются после автоматического обновления OneDrive, которое происходит почасово. Хотя это удобно, этот подход поставляется с некоторыми соображениями, и его нельзя легко изменить.

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

Рассмотрите возможность использования SharePoint или OneDrive для отслеживания изменений и управления ими в следующих сценариях:

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

Примечание.

OneDrive и SharePoint поддерживают содержимое с примененными метками конфиденциальности, за исключением некоторых ограниченных сценариев. В отличие от этого интеграция Fabric Git не поддерживает метки конфиденциальности.

Избегайте использования SharePoint или OneDrive для отслеживания изменений и управления ими в следующих сценариях:

• Содержимое состоит из типов элементов, отличных от семантических моделей и отчетов.
• Содержимое является сложным или большим в область.
• Создатели контента должны совместно работать над тем же элементом одновременно.

В следующих разделах описываются дополнительные рекомендации по эффективному использованию управления версиями с помощью SharePoint или OneDrive с Power BI.

Интеграция Microsoft Teams

Вы можете использовать библиотеки документов из Microsoft Teams, если создатели содержимого используют его для совместной работы. Библиотеки документов — это сайты SharePoint и использование библиотек документов (вместо отдельной папки SharePoint или Папки OneDrive) обеспечивает централизацию содержимого, файлов и совместной работы.

Файлы для регистрации и проверка

Вы должны проверка файлы, над которыми вы работаете, чтобы избежать возможных конфликтов изменений. После завершения изменений проверка в файлах с комментариями, описывающими изменения. При использовании SharePoint или OneDrive для рабочей и учебной среды для управления версиями можно улучшить совместную работу между создателями содержимого и проверка. Если вы проверка и проверка файлы с несколькими создателями контента, вы можете изменить библиотеку сайта SharePoint, чтобы просмотреть последнее обновление и комментарии последнего проверка-in.

История версий

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

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

Управление версиями с помощью удаленного репозитория Git

Удаленный репозиторий Git упрощает управление версиями файлов, что позволяет создателям контента больше возможностей отслеживать изменения и управлять ими. Вкратце создатели содержимого могут разрабатывать содержимое локально или в служба Power BI, а затем зафиксировать и отправить эти изменения в удаленный репозиторий Git, например Azure Repos

Примечание.

Вы также можете выполнять управление версиями содержимого без интеграции Git. В этом сценарии вы по-прежнему отслеживаете изменения содержимого в удаленном репозитории Git, но развертываете содержимое с помощью REST API или конечных точек чтения и записи XMLA. Дополнительные сведения об этих методах развертывания содержимого см . на этапе 4. Развертывание содержимого.

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

На схеме описаны следующие процессы и компоненты.

Элемент	Description
	Создатели содержимого разрабатывают семантические модели и отчеты в локальной среде и сохраняют эти модели и отчеты в виде PBIP-файлов. Создатели содержимого также могут разрабатывать семантические модели и сохранять метаданные модели.
	Когда они будут готовы, создатели содержимого сохраняют свои изменения, которые они фиксируют и передают в удаленный репозиторий Git через регулярные интервалы.
	В удаленном репозитории Git создатели содержимого отслеживают изменения на уровне объектов, что упрощает управление версиями. Создатели контента также могут создавать ветви для работы с содержимым и объединять их изменения в одну ветвь с помощью запросов на вытягивание.
	Создатели содержимого могут синхронизировать содержимое из удаленный репозиторий с помощью интеграции Git. Они также могут развертывать содержимое с помощью других подходов, таких как Azure Pipelines вместе с REST API.
	В рабочей области Fabric создатели содержимого видят изменения содержимого Power BI после завершения синхронизации или развертывания. Создатели содержимого могут создавать содержимое, например потоки данных или записные книжки в рабочей области. Если они используют интеграцию Git, создатели содержимого связывают эту рабочую область с определенной ветвью удаленный репозиторий.
	Создатели содержимого могут зафиксировать и отправить изменения из рабочей области в удаленный репозиторий с помощью интеграции Git. Эти изменения могут импортировать определения элементов для поддерживаемого содержимого, созданного в рабочей области, таких как потоки данных и записные книжки.

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

Рассмотрите возможность использования системы управления версиями для отслеживания изменений и управления ими в следующих сценариях:

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

Ниже приведены некоторые предварительные требования и рекомендации по эффективному использованию системы управления версиями в Azure DevOps.

• Git. Чтобы зафиксировать и отправить изменения в удаленный репозиторий, создатели содержимого должны скачать и установить Git. Git — это распределенная система управления версиями, которая отслеживает изменения в файлах. Сведения об основах Git см. в статье "Что такое Git?".
• Средства. Чтобы использовать Git, создатели содержимого должны использовать интерфейс командной строки (CLI) или графический клиент пользовательского интерфейса (GUI) для SCM, например Visual Studio или Visual Studio Code.
• Лицензии и разрешения. Чтобы создать и использовать репозиторий Azure Repos Git, создатели содержимого должны иметь следующее:
  • Для уровня доступа задано значение "Базовый" (в отличие от заинтересованных сторон).
  • Принадлежит организации и проекту.
  • Соответствующие разрешения репозитория.
• Интеграция Git Fabric. Чтобы синхронизировать содержимое в удаленный репозиторий с рабочей областью Microsoft Fabric, создатели содержимого используют интеграцию Fabric Git. Это важно для отслеживания и управления изменениями содержимого, созданного на портале Fabric, например потоков данных.

Совет

Чтобы упростить управление версиями с помощью локальной разработки, рекомендуется использовать клиентское приложение, например Visual Studio Code. Для разработки содержимого с помощью Power BI Desktop можно использовать Visual Studio Code для управления версиями этого содержимого, промежуточного хранения, фиксации и отправки изменений в удаленный репозиторий.

Предупреждение

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

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

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

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

Примечание.

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

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

Элемент	Description
	Создатель контента создает новую, короткую ветвь, клонируя основную ветвь, которая содержит последнюю версию содержимого. Новая ветвь часто называется ветвь компонента, так как она используется для разработки определенной функции или устранения конкретной проблемы.
	Создатель содержимого фиксирует изменения в локальном репозитории во время разработки.
	Создатель контента связывает свои изменения с рабочими элементами, управляемыми в Azure Boards. Элементы работы описывают определенные разработки, улучшения или исправления ошибок, область в свою ветвь.
	Создатель контента регулярно фиксирует свои изменения. Когда он будет готов, создатель содержимого публикует свою ветвь в удаленный репозиторий.
	Чтобы протестировать изменения, создатель содержимого развертывает свое решение в изолированной рабочей области для разработки (не показанной на этой схеме). Создатель содержимого также может синхронизировать ветвь компонента с рабочей областью с помощью интеграции Fabric Git.
	Создатели контента и владельцы контента документирует решение и его процессы в вики-сайте Azure, который доступен всей команде разработчиков.
	Когда он будет готов, создатель содержимого открывает запрос на вытягивание, чтобы объединить ветвь компонента в основную ветвь.
	Технический владелец отвечает за проверку запроса на вытягивание и объединение изменений. При утверждении запроса на вытягивание они объединяют ветвь компонента в основную ветвь.
	Успешное слияние активирует развертывание решения в рабочей области разработки с помощью Azure Pipeline (не показанного на этой схеме). При использовании интеграции с Fabric Git основная ветвь синхронизируется с рабочей областью разработки.
	Диспетчер выпусков выполняет окончательный обзор и утверждение решения. Это утверждение выпуска предотвращает публикацию решения до его готовности. В публикации корпоративного контента диспетчер выпусков обычно планирует и координирует выпуск контента для тестирования и рабочих областей. Они координируют и взаимодействуют с создателями контента, заинтересованными лицами и пользователями.
	Когда диспетчер выпусков утверждает выпуск, Azure Pipelines автоматически подготавливает решение к развертыванию. Кроме того, Azure Pipeline может активировать конвейер развертывания для повышения содержимого между рабочими областями.
	Пользователи тестируют и проверяют содержимое в тестовой рабочей области. При использовании интеграции Git с Azure Pipelines для развертывания тестовая рабочая область не синхронизируется с какой-либо ветвью.
	После принятия и проверки изменений диспетчер выпусков выполняет окончательный обзор и утверждение решения для развертывания в рабочей рабочей области.
	Пользователи просматривают содержимое, опубликованное в рабочей области. При использовании интеграции Git с Azure Pipelines для развертывания рабочая область не синхронизируется с какой-либо ветвью.

В следующих разделах описываются дополнительные рекомендации по эффективному использованию системы управления версиями с помощью Azure DevOps и Power BI.

Внимание

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

Использование ветвей

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

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

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

Совет

См . статью "Внедрение стратегии ветвления Git" для конкретных рекомендаций и рекомендаций по эффективному использованию стратегии ветвления для эффективной совместной работы.

Пакетные изменения в фиксациях

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

Пакетная обработка изменений таким образом имеет несколько преимуществ.

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

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

• Будет ли выполняться этап и фиксация изменений из локального репозитория или из рабочей области Fabric.
• Поместите PBIP-файлы в папки верхнего уровня при хранении нескольких моделей или отчетов в одном репозитории. Это упрощает идентификацию и группирование внесенных изменений.
• Игнорируйте небезопасные или неискусные изменения метаданных с помощью файла gitignore или файла GITATTRIBUTES. Это гарантирует, что все изменения, которые вы фиксируете, являются значимыми.

Совет

См. статью "Сохранить работу с фиксациями " для конкретных рекомендаций и рекомендаций по этапу и фиксации работы в репозитории Git.

Создание запросов на вытягивание для слияния изменений

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

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

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

Совет

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

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

• Выберите средства разработки: убедитесь, что ваш подход к разработке содержимого соответствует тому, как вы будете сотрудничать с другими создателями контента и использовать управление версиями.
• Выбор между форматами PBIP и PBIX для моделей и отчетов: как правило, формат PBIP более выгоден для управления версиями, но пользователи самообслуживания могут найти PBIX-файлы проще.
• Отдельная семантическая модель и разработка отчетов: управление версиями наиболее эффективно при управлении изменениями для разных типов элементов отдельно. Рекомендуется разделять модель и разработку отчетов.
• Определите, сколько рабочих областей требуется: использование отдельных сред критически важно для успешного управления жизненным циклом контента. Убедитесь, что вы узнали, сколько рабочих областей вам нужно и проводите соответствующее планирование на уровне рабочей области.
• Решите, как реализовать управление версиями: определите один из простых подходов с помощью SharePoint или OneDrive для бизнеса или с помощью Azure DevOps для упрощения управления версиями.
• Настройте удаленный репозиторий. Создайте структурированное пространство в папке OneDrive или репозитории Git, где будет храниться содержимое для отслеживания изменений и управления ими.
• Если вы используете управление версиями, настройте файлы .gitignore и .gitattributes: убедитесь, что вы настроили репозиторий, чтобы отслеживать только значимые изменения.
• Если вы используете управление версиями, определите стратегии ветвления и слияния. Убедитесь, что вы определите четкие процессы настройки и использования системы управления версиями для оптимальной поддержки разработки. Избегайте чрезмерного усложнения процесса. Вместо этого попробуйте дополнить текущий способ работы в командах разработчиков.

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

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