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

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

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

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

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

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

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

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

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

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

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

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

настольная версия Power BI

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

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

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

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

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

Другие инструменты

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

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

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

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

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

Выбор формата содержимого

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

Формат файла вашего контента может изменяться в течение его жизненного цикла. Например, сначала можно создать PBIX-файлы для отчетов и моделей. Однако, когда новые создатели содержимого хотят сотрудничать с вами или когда вы хотите повысить производительность, вы можете переключиться на другой формат, например PBIP-файлы.

В следующих разделах представлен обзор распространенных форматов, которые необходимо выбрать в Power BI.

Формат файла Power BI Desktop (PBIX)

Формат по умолчанию и наиболее распространенный формат отчетов и моделей Power BI — это формат PBIX-файла. Этот двоичный формат легко управлять и использовать для большинства пользователей. Однако невозможно открыть или использовать содержимое файла для отслеживания изменений или повышения производительности разработчика.

Используйте формат PBIX-файла, если:

• Вы планируете публиковать содержимое с помощью обновления OneDrive.
• Создатели содержимого хотят использовать и предоставлять общий доступ к одному файлу, а не папке нескольких файлов (например, с форматом PBIP).
• Создатели содержимого предпочитают формат PBIX, так как они находят его проще.

Формат файла Проектов Power BI (PBIP)

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

На следующем рисунке показано, как отличаются PBIX-файлы и PBIP-файлы:

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

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

Формат PBIP-файла также может использовать форматы TMDL или PBIR для определений семантической модели и отчетов соответственно, которые имеют свои собственные преимущества и рекомендации, которые следует учитывать.

Используйте формат PBIP-файла, если:

• Вы планируете использовать интеграцию Git, а не обновление OneDrive для публикации или развертывания содержимого.
• Вы планируете использовать систему контроля версий для отслеживания изменений и управления ими.
• Вы планируете использовать Power BI Desktop в сочетании с другими средствами для разработки моделей или отчетов.
• Несколько авторов контента будут совместно работать над моделями или отчетами.
• Вы хотите воспользоваться улучшениями производительности и сэкономить время создания моделей или отчетов.
• Вы планируете автоматизировать части процесса разработки, тестирования или развертывания.
• Вы хотите структурировать файлы модели и отчетов различными способами (например, несколькими отчетами в папке .Report и несколькими моделями в папке .SemanticModel).

Формат файла языка определения табличной модели (TMDL)

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

Ниже приведен пример того, как выглядит формат TMDL:

Ниже приведены некоторые преимущества нового формата TMDL:

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

Ниже приведен пример того, как выглядит управление исходным кодом с форматом TMDL:

Используйте формат TMDL, если:

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

Формат расширенного отчета Power BI (PBIR).

При сохранении содержимого в виде PBIP-файла можно использовать формат отчета по умолчанию или новый формат PBIR. Этот новый формат представляет несколько преимуществ, которые могут повысить производительность и совместную работу разработчиков, особенно при использовании формата PBIR с PBIP-файлами.

Ниже приведен пример того, как выглядит формат PBIR:

Ниже приведены некоторые преимущества использования формата PBIR:

• Вы можете лучше использовать управление версиями и интеграцию Git, так как метаданные отчета являются более краткими, структурированным и более удобными для чтения.
• Вы можете повысить эффективность определенных задач отчетности, например:
  • Повторное использование или копирование визуальных элементов между страницами путем копирования visual.json.
  • Повторное использование или копирование страниц между отчетами.
  • Поиск и замена пользовательских цветов, полей и другой визуальной конфигурации одновременно.
  • Исправление "разбитых" визуализаций с полями, которые были переименованы или перемещены между таблицами.
• Вы можете добавить заметки метаданных в метаданные отчета для упрощения определенных автоматизации или задач, поддерживающих непрерывную интеграцию или непрерывное развертывание (CI/CD).
• Вы можете использовать такие инструменты, как semantic-link-labs, которые являются более полезными с новым форматом PBIR.

Используйте формат PBIR, если:

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

Формат файла шаблона Power BI (Pbit)

Вы также можете сохранить отчет Power BI или семантику модели в виде PBIT-файла. Однако PBIT-файлы предназначены для повторного использования определенного макета отчета или структуры модели. Не следует использовать формат PBIT для сохранения содержимого Power BI и управления им во время разработки. Вместо этого следует использовать PBIT-файлы, если вы хотите создать повторно используемые шаблоны для совместного использования с другими людьми в вашей организации.

Другие форматы

При разработке другого содержимого в Power BI (например, на панелях мониторинга, потоках данных или отчетах с разбивкой на страницы) может не быть файлов содержимого, если вы разрабатываете элемент в Fabric. Кроме того, можно сохранить только определение элемента в системе управления версиями. Дополнительные сведения см. в разделе "Выбор места хранения файлов " в предыдущей статье этой серии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ресурсы для поддержания рабочих пространств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Элемент	Описание
	Создатели содержимого разрабатывают семантические модели и отчеты в локальной среде и сохраняют эти модели и отчеты в виде 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, создатели содержимого должны иметь следующее:
  • Уровень доступа установлен на "Базовый" (по сравнению с "Заинтересованным лицом").
  • Принадлежит организации и проекту.
  • Соответствующие разрешения репозитория.
• Интеграция Fabric Git. Чтобы синхронизировать содержимое в удаленном репозитории с рабочей областью Microsoft Fabric, создатели содержимого используют интеграцию Fabric Git. Это важно для отслеживания и управления изменениями содержимого, созданного на портале Fabric, например потоков данных.

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

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

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

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

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

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

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

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

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

Пакетные изменения в коммитах

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

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

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

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

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

Создавайте pull requests для слияния изменений

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

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

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

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

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

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