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

Примечание.

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

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

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

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

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

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

Примечание.

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

Совет

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

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

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

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

Определение и описание содержимого

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

Примечание.

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

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

Какой формат содержимого?

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

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

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

Совет

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

Пример таких схем см. в схемах сценариев планирования использования реализации Power BI.

Кто будет создавать и поддерживать содержимое?

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

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

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

Внимание

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

Какова важность содержимого?

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

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

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

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

Определите, как создатели контента должны сотрудничать

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

Совет

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

Microsoft Teams

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

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

Совет

Рекомендуется использовать Microsoft Teams для упрощения эффективного управления жизненным циклом контента в сценариях самообслуживания с децентрализованной доставкой контента.

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

• Планировщик: владельцы содержимого могут использовать Планировщик для создания планов, которые используются для отслеживания задач и область работы содержимого. Задачи могут описывать проблемы, ошибки или функции в решении и соответствующие заинтересованные лица.
• SharePoint: создатели содержимого могут хранить файлы и управлять ими в библиотеке документов Microsoft Teams или подключенном сайте для каждого канала. Файлы содержимого, хранящиеся в SharePoint, могут использовать управление версиями для отслеживания изменений содержимого и управления ими. Дополнительные сведения об отслеживании изменений и управлении ими с помощью SharePoint см . на этапе 2. Разработка содержимого и управление ими.
• Утверждения. Создатели содержимого и владельцы могут настроить и использовать рабочие процессы для утверждения изменений или выпусков содержимого после проверки.
• Fabric и Power BI: создатели содержимого и владельцы могут получить доступ к порталу Fabric из Microsoft Teams. Оттуда они могут управлять и обсуждать содержимое и добавлять полезные отчеты на вкладки в каналах Teams.
• Другие интеграции: создатели содержимого могут использовать другие службы Майкрософт или сторонние службы, которые интегрируются с Microsoft Teams в соответствии с их предпочитаемым рабочим процессом и потребностями.

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

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

Azure DevOps

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

Примечание.

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

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

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

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

Совет

Рекомендуется использовать Azure DevOps для эффективного управления жизненным циклом контента в корпоративных сценариях с централизованной доставкой содержимого. Совместная работа с помощью Azure DevOps или аналогичных средств предпочтительнее в более сложных сценариях для совместной работы с помощью Microsoft Teams или SharePoint. Это связано с тем, что существуют дополнительные средства и варианты, позволяющие упростить более надежную совместную работу и автоматизацию.

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

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

Примечание.

Вы также можете использовать Microsoft Teams вместе с Azure DevOps, так как существуют различные способы интеграции этих служб. Например, вы можете просматривать и контролировать события Azure Boards и отслеживать события в Azure Pipelines из Microsoft Teams.

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

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

Выбор места хранения файлов

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

Совет

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

Типы файлов, которые необходимо хранить часто, включают:

• Файлы содержимого: файлы, содержащие данные содержимого или метаданные. Файлы содержимого с данными, такими как PBIX и PBIP-файлы Проекта Power BI (PBIP), содержат конфиденциальную информацию. Храните файлы содержимого в безопасном расположении, доступном только тем, кто нуждается в доступе к ним. Кроме того, следует хранить файлы содержимого в расположении, поддерживающем управление версиями, например библиотеку документов в Microsoft Teams или репозиторий Git в Azure DevOps. Примеры файлов содержимого:
  • Файлы Power BI Desktop (PBIX)
  • Файлы Проекта Power BI (PBIP)
  • Файлы отчета с разбивкой на страницы Power BI (RDL)
  • Файлы метаданных модели (BIM или TMDL)
  • Файлы метаданных потока данных (.json)
• Файлы источника данных: файлы, используемые элементами данных, такими как семантические модели или потоки данных. Содержимое напрямую зависит от файлов источника данных, поэтому важно тщательно учесть, где они хранятся, так как удаление их приведет к сбою обновления данных. Кроме того, эти файлы могут содержать конфиденциальную информацию. Таким образом, храните файлы источника данных в безопасной, надежной и надежной среде, которая имеет ограниченный доступ другим лицам. Примеры файлов источника данных могут включать:
  • Структурированные источники данных, такие как книги Excel, Parquet или CSV-файлы.
  • Частично структурированные источники данных, такие как JSON или XML-файлы.
  • Неструктурированные источники данных, такие как изображения, импортированные в отчеты.
• Вспомогательные файлы: файлы, поддерживающие создание или управление содержимым, но не требуются для его работы. Вспомогательные файлы должны храниться в расположении, поддерживающем управление версиями, и где к ним могут получить доступ другие средства и создатели содержимого. Ниже приведены примеры вспомогательных файлов:
  • Файлы правил анализатора рекомендаций (.json).
  • Файлы темы Power BI (.json).
  • Файлы исходного кода для содержимого и запросов.
  • Пользовательские файлы визуализации (PBIVIZ).
• Шаблоны и документация: файлы, помогающие создавать самостоятельное содержимое или описывать существующее содержимое. Шаблоны и документация должны быть легко доступны пользователям, которым требуется их использовать. Примеры шаблонов и документации могут включать:
  • Файлы шаблона Power BI (Pbit).
  • Шаблоны визуализации и примеры отчетов.
  • Проекты решений и документация.
  • Планирование решений и стратегии.
  • Проблемы с запросами пользователей и решением.

Внимание

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

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

SharePoint Online или OneDrive

Общим решением для хранения файлов является использование сайтов SharePoint . SharePoint широко доступен для большинства пользователей и высоко интегрирован с Power BI и другими приложениями Microsoft 365, такими как Microsoft Teams. Кроме того, он имеет встроенный элемент управления версиями, что упрощает хранение большинства типов файлов. Управление версиями позволяет просматривать и управлять различными сохраненными версиями файла.

При хранении файлов в SharePoint рассмотрите следующие моменты.

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

Совет

При совместной работе с помощью Microsoft Teams рекомендуется хранить файлы в библиотеке документов канала. Этот подход помогает централизировать файлы и упрощает совместную работу.

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

• Шаблоны и документация. Хранение шаблонов и документации в SharePoint, если у вас нет существующего решения для хранения. SharePoint идеально подходит для этих файлов, так как вы можете предоставить доступ другим пользователям и управлять файлами без сложных настроек или процессов.
• Вспомогательные файлы: храните вспомогательные файлы в SharePoint, если у вас нет существующего решения для хранения. Однако некоторые вспомогательные файлы (например, темы Power BI .json файлы отчетов) могут лучше храниться в системе управления версиями, которая позволяет просматривать сохраненные изменения и управлять ими.
• Файлы содержимого: храните содержимое в SharePoint, если оно не является критически важным для бизнеса или если у вас нет доступа к удаленный репозиторий, например Azure Repos.
• Источники данных: хранение источников данных в SharePoint только в том случае, если они имеют небольшой размер и сложность. Дисциплина при использовании SharePoint для хранения файлов источника данных. Рассмотрим другие возможные варианты, такие как OneLake.

Внимание

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

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

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

OneLake

Если у вас есть емкость Fabric, OneLake может быть хорошим выбором для хранения файлов источника данных. Вы можете отправлять или синхронизировать файлы в OneLake с помощью проводник OneLake, где их можно преобразовать в таблицы для использования в подчиненных рабочих нагрузках, таких как Power BI. Для больших или регулярно обновленных источников данных можно автоматически загружать файлы в OneLake с помощью Фабрики данных Fabric или других приложений, использующих API Azure Data Lake служба хранилища (ADLS) 2-го поколения или пакет SDK для Python служба хранилища Azure.

Внимание

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

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

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

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

Совет

При хранении данных в OneLake рекомендуется включить непрерывность бизнес-процессов и аварийное восстановление (BCDR), чтобы снизить риск потери данных. С включенной функцией BCDR данные дублируются и хранятся в двух разных географических регионах в соответствии со стандартными парами регионов Azure.

Удаленный репозиторий

Создатели содержимого могут зафиксировать и сохранить работу с локального компьютера на удаленный репозиторий ( например, репозиторий Azure Repos Git) через регулярные интервалы во время разработки. Удаленный репозиторий содержит последнюю версию решения, и она доступна всей командой разработчиков. Как правило, удаленный репозиторий упрощает более сложные подходы к управлению жизненным циклом, чем с помощью Teams, SharePoint или OneDrive. Это связано с тем, что с помощью удаленный репозиторий создатели контента могут воспользоваться более сложными способами совместной работы над файлами или отслеживать изменения файлов и управлять ими. Например, создатели содержимого могут работать с собственной ветвью удаленный репозиторий, чтобы внести изменения и запросить слияние этих изменений в основную ветвь при готовности.

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

• Шаблоны и документация. Хранение шаблонов и документации в удаленный репозиторий при управлении проектом с соответствующими службами, такими как Azure DevOps.
• Вспомогательные файлы: храните вспомогательные файлы в удаленный репозиторий, когда он доступен для легкого отслеживания изменений и управления ими.
• Файлы содержимого: храните содержимое в удаленный репозиторий, когда это важно для бизнеса, или вы планируете сотрудничать с другими разработчиками на том же контенте. Удаленный репозиторий идеально подходит для отслеживания изменений содержимого и упрощения совместной работы.

Совет

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

Нет файлов: содержимое, созданное на портале Fabric

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

Внимание

Вы не можете скачать в виде файла некоторое содержимое, созданное на портале Fabric. Например, отчеты, созданные на портале Fabric, нельзя скачать как PBIX-файлы.

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

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

• Планирование решения: соберите бизнес-требования и технические требования , чтобы достаточно понять проблему, с помощью решения проблемы, и разработать способ решения этой проблемы.
• Определите, кто создаст содержимое: в зависимости от рабочего процесса, навыков и потребностей отдельного создателя содержимого могут потребоваться различные подходы к управлению жизненным циклом.
• Определите, нужно ли совместно работать с несколькими создателями контента: убедитесь, что создатели содержимого совместно используют типы файлов, поддерживающие управление версиями, например PBIP-файлы.
• Решите, как создатели содержимого будут сотрудничать: определите, насколько сложно будет совместная работа. Кроме того, определите, как упростить эту совместную работу, например с помощью Microsoft Teams или Azure DevOps.
• Настройте средства совместной работы: убедитесь, что вы выполняете необходимую первую настройку для решения или проекта. Принимать ключевые решения о том, как управлять совместной работой с помощью этих средств.
• Хранение файлов источника данных в SharePoint или OneLake: хранение небольших, простых файлов источника данных в SharePoint. В противном случае используйте OneLake или ADLSGen2 (если они доступны).
• Храните содержимое и вспомогательные файлы в SharePoint или удаленный репозиторий. Для более простых, небольших проектов используйте SharePoint для большинства файлов, если это упорядочено, и вы рекомендуете управлять доступом. Для более крупных сред или при необходимости параллельной совместной работы рекомендуется использовать удаленный репозиторий, что обеспечит подробный обзор изменений содержимого.
• Хранение шаблонов и документации в SharePoint. Убедитесь, что шаблоны и документация просты для других пользователей для поиска, использования и понимания.
• Планирование разработки и развертывания. Чтобы завершить этот первый этап, выполните конкретные планы по решению ключевых областей и провести начальную настройку. Например, установите средства и проверьте подключения к источнику данных.

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

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