Поделиться через

Выберите лучший вариант рабочего процесса 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.

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

После утверждения и объединения pr-запросов в ветвь разработки:

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

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

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

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

Схема, показывающая поток развертывания на основе Git с помощью сред сборки.

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

После утверждения и объединения pr в ветви разработки :

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

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

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

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

Схема, показывающая поток развертывания на основе Git с помощью конвейеров развертывания.

С помощью этого параметра 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 для поставщиков программного обеспечения в Fabric (управление несколькими клиентами и решениями)

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

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

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

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

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

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

Итоги

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

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

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

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