Управление ветвями в рабочих областях Microsoft Fabric
Цель этой статьи — представить разработчикам Fabric различные варианты создания процессов CI/CD в Fabric на основе распространенных сценариев клиента. В этой статье основное внимание уделяется части непрерывной интеграции (CI) процесса CI/CD. Обсуждение части непрерывной доставки (CD) см. в разделе "Управление конвейерами развертывания".
В этой статье описано несколько различных вариантов интеграции, но многие организации используют их сочетание.
Необходимые компоненты
Чтобы интегрировать Git с рабочей областью Microsoft Fabric, необходимо настроить следующие предварительные требования для Fabric и Git.
Предварительные требования структуры
Чтобы получить доступ к функции интеграции Git, вам потребуется емкость Fabric. Емкость Fabric необходима для использования всех поддерживаемых элементов Fabric. Если у вас еще нет пробной версии, зарегистрируйтесь на бесплатную пробную версию. Клиенты, у которых уже есть возможность Power BI Premium, могут использовать такую возможность, но помните, что некоторые SKU Power BI поддерживают только объекты Power BI.
Кроме того, на портале администрирования необходимо включить следующие коммутаторы клиента:
- Пользователи могут создавать элементы Fabric
- Пользователи могут синхронизировать элементы рабочей области с репозиториями Git
- Только для пользователей GitHub: пользователи могут синхронизировать элементы рабочей области с репозиториями GitHub
Эти параметры можно включить администратором клиента, администратором емкости или администратором рабочей области в зависимости от параметров вашей организации.
Предварительные требования Git
Интеграция Git в настоящее время поддерживается для Azure DevOps и GitHub. Чтобы использовать интеграцию Git с рабочей областью Fabric, вам потребуется следующее в Azure DevOps или GitHub:
- Активная учетная запись Azure, зарегистрированная для того же пользователя, который использует рабочую область Fabric. Создайте бесплатную учетную запись.
- Доступ к существующему репозиторию.
Процесс разработки
Рабочая область Fabric — это общая среда, которая обращается к динамическим элементам. Любые изменения, внесенные непосредственно в рабочую область, переопределяются и влияют на всех других пользователей рабочей области. Поэтому рекомендуется использовать Git для разработчиков в изоляции за пределами общих рабочих областей. Разработчик может работать в своей защищенной рабочей области двумя способами.
- Разработка с помощью клиентских средств, таких как Power BI Desktop для отчетов и семантических моделей, или VS Code для записных книжек.
- Разработка в отдельной рабочей области Fabric. У каждого разработчика есть собственная рабочая область, в которой они подключают отдельную ветвь, синхронизируют содержимое с этой рабочей областью, а затем фиксируют ее в ветви.
Чтобы работать с филиалами с помощью интеграции Git, сначала подключите рабочую область группы разработки к одной общей ветви. Например, если ваша команда использует одну общую рабочую область, подключите ее к главной ветви в репозитории команды и синхронизируйте их между рабочей областью и репозиторием. Если рабочий процесс вашей команды содержит несколько общих ветвей, таких как Dev/Test/Prod , каждая ветвь может быть подключена к другой рабочей области.
Затем каждый разработчик может выбрать изолированную среду, в которой нужно работать.
Сценарий 1. Разработка с помощью клиентских средств
Если элементы, которые вы разрабатываете, доступны в других средствах, вы можете работать с этими элементами непосредственно в клиентском средстве. Не все элементы доступны в каждом инструменте. Элементы, доступные только в Fabric, необходимо разработать в Fabric.
Рабочий процесс для разработчиков, использующих клиентское средство, например Power BI Desktop, должен выглядеть примерно так:
Клонируйте репозиторий на локальный компьютер. (Этот шаг нужно выполнить только один раз.)
Откройте проект в Power BI Desktop с помощью локальной копии PBIProj.
Внесите изменения и сохраните обновленные файлы локально. Фиксация локального репозитория.
Когда все готово, отправьте ветвь и зафиксирует его в удаленный репозиторий.
Протестируйте изменения с другими элементами или большими данными, подключив новую ветвь к отдельной рабочей области и отправив семантику модели и отчеты с помощью кнопки обновления всех кнопок на панели управления версиями. Перед слиянием в основную ветвь выполните все тесты или изменения конфигурации.
Если в рабочей области не требуются тесты, разработчик может объединить изменения непосредственно в основную ветвь без необходимости в другой рабочей области.
После объединения изменений рабочая область общей команды будет предложено принять новую фиксацию. Изменения обновляются в общей рабочей области, и все могут видеть изменения этих семантических моделей и отчетов.
Инструкции по использованию нового формата файла Power BI Desktop в Git см . в формате исходного кода.
Сценарий 2. Разработка с помощью другой рабочей области
Для разработчика, который работает в Интернете, поток будет следующим образом:
На вкладке "Ветви" меню "Управление версиями" выберите "Ветвь" в новую рабочую область.
Укажите имена ветви и рабочей области. Новая ветвь, созданная на основе ветви, подключенной к текущей рабочей области.
Выберите "Ветвь".
Fabric создает новую рабочую область и ветвь. Вы автоматически перейдете в новую рабочую область.
Рабочая область синхронизируется с ветвь компонента и становится изолированной средой для работы, как показано ниже. Теперь вы можете работать в этой новой изолированной среде. Синхронизация может занять несколько минут. Дополнительные сведения о ветвлениях см. в советах по устранению неполадок.
Сохраните изменения и зафиксируйте их в ветвь компонента.
Когда будет готово, создайте PR-запрос в главную ветвь. Процессы проверки и слияния выполняются с помощью Azure Repos на основе конфигурации, определенной командой для этого репозитория.
После завершения проверки и слияния создается новая фиксация в главной ветви. Эта фиксация предложит пользователю обновить содержимое в рабочей области команды разработки с объединенными изменениями.
Дополнительные сведения см. в разделе об ограничениях для ветвления.
Процесс выпуска
Процесс выпуска начинается после того, как новые обновления завершают процесс запроса на вытягивание и объединяются в общую ветвь команды (например , Main, Dev и т. д.). На этом этапе мы рассмотрим различные варианты создания процесса выпуска в Fabric. Вы можете найти различные рекомендации по процессу выпуска в управлении конвейерами развертывания.
Переключение ветвей
Если рабочая область подключена к ветви Git и вы хотите переключиться на другую ветвь, вы можете сделать это быстро из области управления версиями без отключения и повторного подключения.
При переключении ветвей рабочая область синхронизируется с новой ветвью, а все элементы в рабочей области переопределяются. Если в каждой ветви есть разные версии одного и того же элемента, замените его. Если элемент находится в старой ветви, но не новый, он удаляется.
Чтобы переключиться между ветвями, выполните следующие действия.
На вкладке "Ветви" меню "Управление версиями" выберите "Переключить ветвь".
Укажите ветвь, к которой нужно подключиться или создать новую ветвь. Эта ветвь должна содержать тот же каталог, что и текущая ветвь.
Выберите "Переключить ветвь".
Вы не можете переключать ветви, если в рабочей области есть незафиксированные изменения. Нажмите кнопку "Отмена" , чтобы вернуться и зафиксировать изменения перед переключением ветвей.
Чтобы подключить текущую рабочую область к новой ветви при сохранении существующего состояния рабочей области, выберите "Проверить новую ветвь". Дополнительные сведения о проверке новой ветви см. в разделе "Устранение конфликтов" в Git.