Рекомендации по управлению жизненным циклом в Fabric
В этой статье приводятся рекомендации для создателей данных и аналитики, которые управляют своим содержимым на протяжении всего жизненного цикла в Microsoft Fabric. В этой статье рассматривается использование интеграции Git для управления версиями и конвейеров развертывания в качестве средства выпуска. Общие рекомендации по публикации контента Enterprise, публикации контента Enterprise.
Статья разделена на четыре раздела:
Подготовка содержимого— подготовка содержимого к управлению жизненным циклом.
Разработка — узнайте о лучших способах создания содержимого на этапе разработки конвейеров развертывания.
Тест. Узнайте , как использовать этап тестирования конвейеров развертывания для тестирования среды.
Рабочая среда — используйте рабочий этап конвейеров развертывания, чтобы сделать содержимое доступным для использования.
Рекомендации по подготовке содержимого
Чтобы лучше подготовить содержимое к текущему управлению на протяжении всего жизненного цикла, ознакомьтесь с информацией в этом разделе, прежде чем вы:
Выпуск содержимого в рабочую среду.
Начните использовать конвейер развертывания для определенной рабочей области.
Разделение разработки между командами
Различные команды в организации обычно имеют разные знания, владение и методы работы, даже при работе над тем же проектом. Важно установить границы, давая каждой команде свою независимость работать так же, как им нравится. Рассмотрите возможность наличия отдельных рабочих областей для разных команд. С отдельными рабочими областями каждая команда может иметь разные разрешения, работать с различными репозиториями системы управления версиями и отправлять содержимое в рабочую среду в другой курс. Большинство элементов могут подключать и использовать данные в рабочих областях, поэтому они не блокируют совместную работу с теми же данными и проектами.
Планирование модели разрешений
Для интеграции и конвейеров развертывания Git требуются разные разрешения, отличные от разрешений рабочей области. Ознакомьтесь с требованиями к разрешениям для конвейеров интеграции и развертывания Git.
Чтобы реализовать безопасный и простой рабочий процесс, планировщик, который получает доступ к каждой части используемых сред, как репозиторий Git, так и этапы разработки и тестирования или prod в конвейере. Ниже приведены некоторые из соображений, которые следует учитывать:
Кто должен иметь доступ к исходному коду в репозитории Git?
Какие операции должны выполнять пользователи с доступом к конвейеру на каждом этапе?
Кто просматривает содержимое на этапе тестирования?
Должны ли проверятели тестового этапа иметь доступ к конвейеру?
Кто должен контролировать развертывание на рабочей стадии?
Какая рабочая область назначается конвейеру или подключается к Git?
К какой ветви вы подключаетесь к рабочей области? Что такое политика, определенная для этой ветви?
Предоставляется ли рабочая область несколькими участниками команды? Должны ли они вносить изменения непосредственно в рабочую область или только через запросы на вытягивание?
На каком этапе вы назначаете рабочую область?
Нужно ли вносить изменения в разрешения рабочей области, которую вы назначаете?
Подключение различных этапов к разным базам данных
Рабочая база данных всегда должна быть стабильной и доступной. Рекомендуется не перегружать запросы, созданные создателями бизнес-аналитики для разработки или тестирования семантических моделей. Создайте отдельные базы данных для разработки и тестирования, чтобы защитить рабочие данные и не перегружать базу данных разработки со всем объемом рабочих данных.
Использование параметров для конфигураций, изменяющихся между этапами
По возможности добавьте параметры в любое определение, которое может меняться между этапами разработки, тестирования и prod. Использование параметров позволяет легко изменять определения при перемещении изменений в рабочую среду. Хотя в Fabric по-прежнему нет единого способа управления параметрами, рекомендуется использовать его в элементах, поддерживающих любой тип параметризации.
Параметры используют разные виды использования, такие как определение подключений к источникам данных или внутренние элементы в Fabric. Их также можно использовать для внесения изменений в запросы, фильтры и текст, отображаемый пользователям.
В конвейерах развертывания можно настроить правила параметров для задания различных значений для каждого этапа развертывания.
Рекомендации по этапу разработки конвейеров развертывания
В этом разделе приводятся рекомендации по работе с конвейерами развертывания и его использованием для этапа разработки.
Резервное копирование работы в репозиторий Git
С интеграцией Git любой разработчик может создать резервную копию своей работы, зафиксировав его в Git. Чтобы правильно создать резервную копию работы в Fabric, ниже приведены некоторые основные правила:
Убедитесь, что у вас есть изолированная среда для работы, поэтому другие не переопределяют работу, прежде чем она будет зафиксирована. Это означает, что работа в классическом средстве (например , VS Code, Power BI Desktop или других) или в отдельной рабочей области, к которым другие пользователи не могут получить доступ.
Зафиксируйте ветвь, созданную вами, и ни один другой разработчик не использует. Если вы используете рабочую область в качестве среды разработки, ознакомьтесь с ветвями.
Зафиксируйте вместе изменения, которые необходимо развернуть вместе. Этот совет применяется к одному элементу или нескольким элементам, связанным с одним изменением. Фиксация всех связанных изменений может помочь вам позже при развертывании на других этапах, создании запросов на вытягивание или возврате изменений обратно.
Большие фиксации могут привести к максимальному ограничению размера фиксации. Учитывайте количество элементов, которые вы фиксируете вместе, или общий размер элемента. Например, отчеты могут увеличиваться при добавлении больших изображений. Это плохая практика хранения больших размеров элементов в системах управления версиями, даже если это работает. Рассмотрите способы уменьшения размера элементов, если у них много статических ресурсов, таких как изображения.
Откат изменений
После резервного копирования работы могут возникнуть случаи, когда вы хотите вернуться к предыдущей версии и восстановить ее в рабочей области. Существует несколько способов вернуться к предыдущей версии:
Кнопка отмены. Операция отмены — это простой и быстрый способ вернуть внесенные вами немедленные изменения, если они еще не зафиксированы. Вы также можете отменить каждый элемент отдельно. Дополнительные сведения об операции отмены.
Возврат к старым фиксациям: нет прямого способа вернуться к предыдущей фиксации в пользовательском интерфейсе. Лучшим вариантом является повышение старой фиксации, чтобы быть HEAD с помощью git revert или сброса git. Это показывает, что в области управления версиями есть обновление, и вы можете обновить рабочую область с этой новой фиксацией.
Так как данные не хранятся в Git, помните, что отмена элемента данных в более раннюю версию может нарушить существующие данные и может потребовать удаления данных или операции может завершиться ошибкой. Перед отменой изменений проверьте это заранее.
Работа с частной рабочей областью
Если вы хотите работать в изоляции, используйте отдельную рабочую область в качестве изолированной среды. Узнайте больше об изоляции рабочей среды в работе с ветвями. Для оптимального рабочего процесса для вас и команды рассмотрим следующие моменты:
Настройка рабочей области. Перед началом работы убедитесь, что вы можете создать новую рабочую область (если у вас еще нет), которую можно назначить емкости Fabric и получить доступ к данным для работы в рабочей области.
Создание новой ветви: создайте новую ветвь из основной ветви, поэтому у вас есть самая актуальная версия содержимого. Также убедитесь, что вы подключаетесь к правильной папке в ветви, чтобы можно было извлечь нужное содержимое в рабочую область.
Небольшие, частые изменения: рекомендуется вносить небольшие добавочные изменения, которые легко объединить и менее вероятно, в конфликты. Если это невозможно, обязательно обновите ветвь из main, чтобы разрешить конфликты самостоятельно.
Изменения конфигурации. При необходимости измените конфигурации в рабочей области, чтобы повысить эффективность работы. Некоторые изменения могут включать подключение между элементами или различными источниками данных или изменения параметров для данного элемента. Просто помните, что все, что вы фиксируете, становится частью фиксации и может случайно быть объединены в основную ветвь.
Использование клиентских средств для редактирования работы
Для элементов и инструментов, поддерживающих ее, может быть проще работать с клиентскими инструментами для разработки, например Power BI Desktop для семантических моделей и отчетов, VS Code для записных книжек и т. д. Эти средства могут быть вашей локальной средой разработки. После завершения работы отправьте изменения в удаленный репозиторий и синхронизируйте рабочую область для отправки изменений. Просто убедитесь, что вы работаете с поддерживаемой структурой элемента, который вы создаете. Если вы не уверены, сначала клонируйте репозиторий с содержимым, уже синхронизированным с рабочей областью, а затем начните создавать из нее, где структура уже размещена.
Управление рабочими областями и филиалами
Так как рабочая область может быть подключена только к одной ветви одновременно, рекомендуется рассматривать ее как сопоставление 1:1. Тем не менее, чтобы уменьшить объем рабочей области, которую он влечет за собой, рассмотрите следующие варианты:
Если разработчик настроит частную рабочую область со всеми необходимыми конфигурациями, он может продолжать использовать ее для любой создаваемой ветви. Когда спринт завершается, изменения объединяются и вы запускаете новую задачу, просто переключите подключение к новой ветви в той же рабочей области. Это также можно сделать, если вдруг нужно исправить ошибку в середине спринта. Подумайте об этом как о рабочем каталоге в Интернете.
Разработчикам, использующим клиентское средство (например, VS Code, Power BI Desktop или другие), не обязательно требуется рабочая область. Они могут создавать ветви и фиксировать изменения в этой ветви локально, отправлять их в удаленный репозиторий и создавать запрос на вытягивание в главную ветвь без рабочей области. Рабочая область необходима только в качестве среды тестирования, чтобы убедиться, что все работает в реальном сценарии. Это до вас, чтобы решить, когда это должно произойти.
Дублирование элемента в репозитории Git
Чтобы дублировать элемент в репозитории Git, выполните следующие действия.
- Скопируйте весь каталог элементов.
- Измените логический идентификатор на что-то уникальное для этой подключенной рабочей области.
- Измените отображаемое имя, чтобы отличить его от исходного элемента и избежать ошибки повторяющегося отображаемого имени.
- При необходимости обновите логический идентификатор и/или отображайте имена в любых зависимостях.
Рекомендации по тестированию конвейеров развертывания
В этом разделе приведены рекомендации по работе с этапом тестирования конвейеров развертывания.
Имитация рабочей среды
Важно увидеть, как предлагаемое изменение повлияет на этап производства. Этап тестирования конвейеров развертывания позволяет имитировать реальную рабочую среду для тестирования. Кроме того, это можно имитировать, подключив Git к другой рабочей области.
Убедитесь, что эти три фактора рассматриваются в тестовой среде:
Объем данных
Объем использования
Аналогичная емкость, как в рабочей среде
При тестировании можно использовать ту же емкость, что и этап рабочей среды. Однако использование той же емкости может сделать рабочую нестабильность во время нагрузочного тестирования. Чтобы избежать нестабильной рабочей среды, протестируйте использование другой емкости, аналогичной ресурсам для рабочей емкости. Чтобы избежать дополнительных затрат, используйте емкость, в которой можно платить только за время тестирования.
Использование правил развертывания с источником данных в реальном времени
Если вы используете тестовый этап для имитации использования данных в реальном времени, рекомендуется разделить источники данных разработки и тестирования. База данных разработки должна быть относительно небольшой, и тестовая база данных должна быть максимально похожа на рабочую базу данных. Используйте правила источника данных для переключения источников данных на этапе тестирования или параметризации подключения, если не работает через конвейеры развертывания.
Проверка связанных элементов
Внесенные изменения также могут повлиять на зависимые элементы. Во время тестирования убедитесь, что изменения не влияют на производительность существующих элементов, которые могут зависеть от обновленных.
С помощью анализа влияния можно легко найти связанные элементы.
Обновление элементов данных
Элементы данных — это элементы, которые хранят данные. Определение элемента в Git определяет, как хранятся данные. При обновлении элемента в рабочей области мы импортируем его определение в рабочую область и применяем его к существующим данным. Операция обновления элементов данных одинакова для конвейеров развертывания и Git.
Так как различные элементы имеют различные возможности, когда речь идет о сохранении данных при применении изменений в определении, следует учитывать при применении изменений. Некоторые методики, которые помогут применить изменения самым безопасным способом:
Заранее знайте, какие изменения и какие последствия могут повлиять на существующие данные. Используйте сообщения фиксации для описания внесенных изменений.
Чтобы узнать, как этот элемент обрабатывает изменение с помощью тестовых данных, передайте изменения в среду разработки или тестирования.
Если все происходит хорошо, рекомендуется также проверить его в промежуточной среде с данными реального времени (или как можно ближе к нему), чтобы свести к минимуму непредвиденные действия в рабочей среде.
Рассмотрите лучшие сроки при обновлении среды Prod, чтобы свести к минимуму ущерб, который могут привести к возникновению ошибок для бизнес-пользователей, которые используют данные.
После развертывания тесты после развертывания в Prod убедитесь, что все работает должным образом.
Некоторые изменения всегда будут рассматриваться как критические изменения. Надеюсь, предыдущие шаги помогут вам отслеживать их перед рабочей средой. Создайте план, чтобы применить изменения в Prod и восстановить данные, чтобы вернуться к нормальному состоянию и свести к минимуму время простоя для бизнес-пользователей.
Тестирование приложения
Если вы распространяете содержимое для клиентов через приложение, просмотрите новую версию приложения, прежде чем она находится в рабочей среде. Так как каждый этап конвейера развертывания имеет собственную рабочую область, вы можете легко публиковать и обновлять приложения для этапов разработки и тестирования. Публикация и обновление приложений позволяет протестировать приложение с точки зрения конечного пользователя.
Внимание
Процесс развертывания не включает обновление содержимого или параметров приложения. Чтобы применить изменения к содержимому или параметрам, вручную обновите приложение на требуемом этапе конвейера.
Рекомендации по этапу развертывания конвейеров развертывания
В этом разделе приводятся рекомендации по этапу рабочей среды конвейеров развертывания.
Управление тем, кто может развернуть в рабочей среде
Так как развертывание в рабочей среде должно обрабатываться тщательно, рекомендуется разрешить только определенным людям управлять этой конфиденциальной операцией. Тем не менее, вероятно, все создатели бизнес-аналитики для определенной рабочей области должны иметь доступ к конвейеру. Используйте разрешения рабочей рабочей области для управления разрешениями доступа. Другие пользователи могут иметь роль средства просмотра рабочей области, чтобы просмотреть содержимое в рабочей области, но не вносить изменения из конвейеров Git или развертывания.
Кроме того, ограничить доступ к репозиторию или конвейеру путем включения только разрешений пользователям, которые являются частью процесса создания контента.
Настройка правил для обеспечения доступности этапа рабочей среды
Правила развертывания — это эффективный способ обеспечения подключения данных в рабочей среде и их доступности для пользователей. При применении правил развертывания развертывание может выполняться при наличии гарантии того, что клиенты могут видеть соответствующую информацию без нарушений.
Убедитесь, что вы устанавливаете правила развертывания рабочей среды для источников данных и параметров, определенных в семантической модели.
Обновление рабочего приложения
Развертывание в конвейере через пользовательский интерфейс обновляет содержимое рабочей области. Чтобы обновить связанное приложение, используйте API конвейеров развертывания. Невозможно обновить приложение через пользовательский интерфейс. Если вы используете приложение для распространения содержимого, не забудьте обновить приложение после развертывания в рабочей среде, чтобы конечные пользователи сразу могли использовать последнюю версию.
Развертывание в рабочей среде с помощью ветвей Git
Так как репозиторий служит "одним источником истины", некоторые команды могут потребовать развертывания обновлений на разных этапах непосредственно из Git. Это возможно с интеграцией Git с несколькими рекомендациями.
Рекомендуется использовать ветви выпуска. Перед каждым развертыванием необходимо постоянно изменять подключение рабочей области к новым ветвям выпуска.
Если конвейер сборки или выпуска требует изменить исходный код или запустить скрипты в среде сборки перед развертыванием в рабочей области, подключение рабочей области к Git не поможет вам.
После развертывания на каждом этапе обязательно измените всю конфигурацию, относящуюся к этой стадии.
Быстрые исправления содержимого
Иногда в рабочей среде возникают проблемы, требующие быстрого исправления. Развертывание исправления без тестирования в первую очередь является плохой практикой. Поэтому всегда реализуйте исправление на этапе разработки и отправьте его на остальные этапы конвейера развертывания. Развертывание на этапе разработки позволяет проверить, работает ли исправление перед развертыванием в рабочей среде. Развертывание в конвейере занимает всего несколько минут.
Если вы используете развертывание из Git, рекомендуется следовать рекомендациям, описанным в статье "Внедрение стратегии ветвления Git".