Выберите наилучший вариант рабочего процесса CI/CD для Fabric

Цель этой статьи — представить разработчикам Fabric различные варианты создания процессов CI/CD в Fabric на основе распространенных сценариев клиента. В этой статье рассматриваются дополнительные сведения о непрерывном развертывании (CD) процесса CI/CD. Обсуждение части непрерывной интеграции (CI) см. в разделе "Управление ветвями Git".

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

Предварительные требования

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

• У вас есть подписка Microsoft Fabric

• Вы являетесь администратором рабочей области Fabric

Процесс разработки

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

Процесс выпуска

Процесс выпуска начинается после завершения обновлений и после объединения запроса на вытягивание (PR) в общую ветвь команды (например, Main, Dev и т. д.). С этого момента существуют различные варианты создания процесса выпуска в Fabric.

Вариант 1. Развертывания на основе Git

С помощью этого параметра все развертывания происходят из репозитория Git. Каждый этап в конвейере выпуска имеет выделенную первичную ветвь (на схеме эти этапы — dev, test и Prod), которая передает соответствующую рабочую область в Fabric.

После того как PR в ветвь Dev утвержден и объединен:

1. Активируется конвейер выпуска для обновления содержимого рабочей области Dev. Этот процесс также может включать конвейер сборки для выполнения модульных тестов, но фактическая отправка файлов выполняется непосредственно из репозитория в рабочую область с помощью API Fabric Git. Может потребоваться вызвать другие API Fabric для операций после развертывания, которые задают определенные конфигурации для этой рабочей области или приема данных.
2. Затем создается PR в ветку Test. В большинстве случаев pr создается с помощью ветви выпуска, которая может выбрать содержимое, чтобы перейти на следующий этап. Pr должен включать те же процессы проверки и утверждения, что и любые другие в вашей команде или организации.
3. Другой конвейер сборки и выпуска активируется для обновления рабочей области test , используя процесс, аналогичный описанному на первом шаге.
4. Pr создается в ветви Prod , используя процесс, аналогичный описанному на шаге 2.
5. Другой конвейер сборки и выпуска активируется для обновления рабочей области Prod , используя процесс, аналогичный описанному на первом шаге.

Когда следует использовать вариант #1?

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

Вариант 2. Развертывания на основе Git с помощью сред сборки

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

После утверждения и объединения PR в ветвь dev:

1. Конвейер сборки активируется для создания новой среды сборки и запуска модульных тестов для этапа разработки. Затем процесс выпуска активируется для отправки содержимого в среду сборки, запуска скриптов для изменения некоторых конфигураций, адаптации конфигурации к этапу разработки и использования API определения элемента обновления Fabric для отправки файлов в рабочую область.
2. После завершения этого процесса, включая прием данных и утверждение от руководителей выпусков, можно создать следующий конвейер сборки и выпуска для этапа тестирования . Эти этапы создаются в процессе, аналогичном описанному на первом шаге. Для этапа тестирования другие автоматизированные или ручные тесты могут потребоваться после развертывания, чтобы проверить, что изменения будут готовы к выпуску на стадии Prod .
3. После завершения всех автоматизированных и ручных тестов диспетчер выпусков может утвердить и запустить конвейеры сборки и выпуска на стадию Prod . Так как этап Prod обычно имеет разные конфигурации, чем этапы тестирования или разработки, важно также протестировать изменения после развертывания. Кроме того, развертывание должно активировать дополнительное поглощение данных на основе изменения, чтобы свести к минимуму потенциальную недоступность для потребителей.

Какие компоненты можно использовать для реализации параметра #2?

• Fabric-cicd — библиотека Python, предназначенная для использования с рабочими областями Microsoft Fabric. Эта библиотека поддерживает автоматизацию подхода "сначала код" для непрерывной интеграции и развертывания (CI/CD), что позволяет беспрепятственно интегрировать рабочие области в структуру развёртывания. Полный конечный пример изучите в нашем руководстве по fabric-cicd и Azure DevOps.
• Bulk-Import-Item-Definitions-API поддерживает как создание новых элементов, так и обновление существующих прямо на месте, при этом полагаясь на встроенную обработку зависимостей Fabric для гарантии того, что элементы развертываются в правильном порядке. Это позволяет последовательным, повторяемым развертываниям в тестовых и рабочих средах без ручного вмешательства. Чтобы ознакомиться с примером учебного пособия, следуйте нашему руководству по CI/CD Fabric с использованием API массового импорта определений элементов.

Когда следует использовать вариант #2?

• Если вы хотите использовать Git в качестве единственного источника истины и источника всех развертываний.
• Когда ваша команда использует workflow на основе trunk в качестве стратегии ветвления.
• Перед развертыванием требуется среда сборки (с пользовательским скриптом) для изменения атрибутов для конкретной рабочей области, таких как connectionId и lakehouseId.
• Вам нужен конвейер выпуска и пользовательский скрипт для получения содержимого элемента из Git, а также для вызова соответствующего API элементов Fabric с целью создания, обновления или удаления измененных элементов Fabric.

Вариант 3 — Развертывание с помощью конвейеров развертывания Fabric

С помощью этого параметра Git подключается только до этапа разработки. На этапе разработки развертывание выполняется непосредственно между рабочими областями dev/Test/Prod с помощью конвейеров развертывания Fabric. Хотя само средство является внутренним в Fabric, разработчики могут использовать API конвейеров развертывания для оркестрации развертывания в рамках конвейера релиза Azure или рабочего процесса GitHub. Эти API позволяют команде создавать аналогичный процесс сборки и выпуска , как и в других вариантах, используя автоматизированные тесты (которые можно выполнить в самой рабочей области или до этапа разработки ), утверждения и т. д.

После утверждения и объединения PR в основную ветвь:

1. Конвейер сборки активируется, который отправляет изменения на этап разработки с помощью API-интерфейсов Fabric Git. При необходимости конвейер может активировать другие API для запуска операций и тестов после развертывания на этапе разработки .
2. После завершения развертывания разработки конвейер выпуска запускается для развертывания изменений с этапа разработки на этап тестирования. Автоматические и ручные тесты должны выполняться после развертывания, чтобы убедиться, что изменения хорошо протестированы перед достижением рабочей среды.
3. После завершения тестов и диспетчер выпусков утверждает развертывание на стадии Prod, выпуск в Prod запускается и завершает развертывание.

Когда следует использовать вариант #3?

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

Вариант 4 - CI/CD для ISV на платформе Fabric (управление решениями для нескольких клиентов)

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

Этот параметр основан на параметре #2. После утверждения и объединения PR в основную ветку main:

1. Конвейер сборки активируется для создания новой среды сборки и запуска модульных тестов для этапа разработки. После завершения тестов активируется конвейер выпуска . Этот конвейер может загружать содержимое в среду сборки, запускать скрипты для изменения некоторых конфигураций, настроить конфигурацию на этап dev, а затем использовать API определения обновления элемента в Fabric для загрузки файлов в рабочую область.
2. После завершения этого процесса, включая прием данных и утверждение от руководителей выпусков, следующий конвейер сборки и выпуска для этапа тестирования может начаться. Этот процесс аналогичен описанному на первом шаге. Для этапа тестирования другие автоматизированные или ручные тесты могут потребоваться после развертывания, чтобы проверить, что изменения готовы к выпуску на стадии Prod в высоком качестве.
3. После завершения всех тестов и завершения процесса утверждения развертывание для клиентов Prod может начаться. Каждый клиент имеет собственный выпуск с собственными параметрами, чтобы его конфигурация и подключение к данным могли проходить в соответствующей рабочей области клиента. Изменение конфигурации может произойти через сценарии в среде сборки или с помощью API после развертывания. Все выпуски могут выполняться параллельно, так как они не связаны друг с другом и не зависят друг от друга.

Когда следует использовать вариант #4?

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

Итоги

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

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

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

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

• Управление ветвями Git
• Автоматизация интеграции Git с помощью API и Azure DevOps
• Автоматизация конвейера развертывания с помощью API Fabric
• Рекомендации по управлению жизненным циклом в Fabric