Система управления версиями в Фабрике данных Azure

ОБЛАСТЬ ПРИМЕНЕНИЯ: Фабрика данных Azure Azure Synapse Analytics

По умолчанию пользовательский интерфейс Фабрики данных Azure подразумевает разработку непосредственно в службе фабрики данных. Этот интерфейс имеет следующие ограничения:

• Служба фабрики данных не включает репозиторий для хранения сущностей JSON для изменений. Единственный способ сохранить изменения — нажать кнопку Опубликовать все, чтобы опубликовать все изменения непосредственно в службе фабрики данных.
• Служба фабрики данных не оптимизирована для совместной работы и управления версиями.
• Шаблон Azure Resource Manager, необходимый для развертывания фабрики данных, не включен.

Чтобы повысить эффективность разработки, Фабрика данных Azure позволяет настроить репозиторий Git с помощью Azure Repos или GitHub. Git — это система управления версиями, упрощающая отслеживание изменений и совместную работу. В этой статье описывается, как настроить и работать в репозитории Git вместе с выделением рекомендаций и руководством по устранению неполадок.

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

Дополнительные сведения о том, как Фабрика данных Azure интегрируется с Git, см. в 15-минутном учебном видео ниже:

Преимущества интеграции с Git

Ниже приведен список некоторых преимуществ, которые интеграция с Git предоставляет для разработки:

• Управление версиями. По мере того как рабочие нагрузки фабрики данных становятся важными, необходимо интегрировать фабрику с Git, чтобы применить несколько преимуществ системы управления версиями, как показано ниже:
  • Возможность отслеживания и аудита изменений.
  • Возможность отмены изменений, из-за которых появились ошибки.
• Частичные сохранения: при создании в службе фабрики данных невозможно сохранить изменения в виде черновика, а все публикации должны пройти проверку фабрики данных. Если конвейеры не завершены или вы просто не хотите терять изменения при сбое компьютера, интеграция Git позволяет добавочные изменения ресурсов фабрики данных независимо от того, в каком состоянии они находятся. Настройка репозитория Git позволяет сохранять изменения, позволяя публиковать только после тестирования изменений в удовлетворенности.
• Совместная работа и управление. Если у вас несколько участников команды, участвующих в одной фабрике, может потребоваться разрешить коллегам сотрудничать друг с другом с помощью процесса проверки кода. Вы также можете настроить фабрику таким образом, чтобы у участников были разные разрешения. Некоторые члены команды могут быть разрешены только вносить изменения через Git, и только некоторые люди в команде могут публиковать изменения в фабрике.
• Лучше ci/CD: если вы развертываете в нескольких средах с непрерывным процессом доставки, интеграция Git упрощает определенные действия. Некоторые из этих действий включают:
  • Настройка конвейера выпуска для автоматического запуска при внесении изменений в фабрику dev.
  • Настройка в фабрике свойств, доступных в качестве параметров в шаблоне Resource Manager. Это может быть полезно для хранения только требуемого набора свойств в качестве параметров и иметь все остальное жестко закодированное.
• Повышенная производительность. Средняя фабрика с интеграцией с Git загружает данные в 10 раз быстрее, чем при разработке в службе фабрики данных. Повышение производительности связано с тем, что ресурсы загружаются через Git.

Подключение к репозиторию Git

Существует четыре разных способа подключения репозитория Git к фабрике данных для Azure Repos и GitHub. После подключения к репозиторию Git вы можете просматривать конфигурацию и управлять ею в центре управления в разделе "Управление версиями" в разделе "Управление версиями".

Метод настройки 1. Домашняя страница

На домашней странице Фабрики данных Azure выберите вверху Настройка репозитория кода.

Метод настройки 2. Холст разработки

На холсте разработки Фабрики данных Azure выберите раскрывающееся меню Фабрика данных, а затем выберите пункт Настройка репозитория кода.

Метод настройки 3. Центр управления

Перейдите в центр управления в Фабрика данных Azure Studio. В разделе Система управления версиями выберите Конфигурация Git. Если у вас нет подключенного репозитория, нажмите кнопку "Настроить".

Метод конфигурации 4. Во время создания фабрики

При создании новой фабрики данных на портале Azure можно указать сведения о репозитории Git на вкладке Git configuration (Конфигурация Git).

Author with Azure Repos Git integration (Разработка с использованием интеграции Git с Azure Repos)

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

Параметры Azure Repos

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

Изменение параметров репозитория

Если какие-либо корректировки необходимо внести в параметры настроенного репозитория Azure Repos Git, можно выбрать команду "Изменить".

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

Использование другого клиента Microsoft Entra

Репозиторий Azure Repos Git может находиться в другом клиенте Microsoft Entra. Чтобы указать другой клиент Microsoft Entra, необходимо иметь разрешения администратора для используемой подписки Azure. Дополнительные сведения см. в разделе "Администратор подписки изменений".

Использование личной учетной записи Майкрософт

Чтобы использовать личную учетную запись Майкрософт для интеграции с Git, можно связать личный репозиторий Azure с Active Directory вашей организации.

1. Добавление личной учетной записи Майкрософт в Active Directory вашей организации в качестве гостя. Дополнительные сведения см. в разделе "Добавление пользователей совместной работы Microsoft Entra B2B" в портал Azure.

2. Войдите в портал Azure с помощью личной учетной записи Майкрософт. Перейдите в Active Directory вашей организации.

3. Перейдите к разделу Azure DevOps, где находится личный репозиторий. Выберите репозиторий и подключитесь к Active Directory.

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

Дополнительные сведения о подключении Azure Repos к Active Directory организации см. в статье "Подключение организации Azure DevOps к идентификатору Microsoft Entra".

Author with GitHub integration (Разработка с использованием интеграции GitHub)

Визуальная разработка с помощью интеграции GitHub поддерживает управление исходным кодом и совместную работу для создания конвейеров фабрики данных. Фабрику данных можно связать с репозиторием учетной записи GitHub для управления исходным кодом, совместной работы и управления версиями. Одна учетная запись GitHub может размещать несколько репозиториев, и каждый репозиторий может быть связан с несколькими фабриками данных. Настроив каждую фабрику данных для использования другой ветви в одном репозитории, можно поддерживать отдельные среды (например, разработку, промежуточные и рабочие среды) при управлении их конфигурациями независимо. Если у вас нет учетной записи GitHub или репозитория, создайте их, следуя этим инструкциям.

Интеграция GitHub с Фабрикой данных поддерживает общедоступный GitHub (то есть https://github.com), GitHub Enterprise Cloud и GitHub Enterprise Server. Вы можете использовать общедоступные и частные репозитории GitHub с Фабрикой данных, если у вас есть разрешения на чтение и запись в репозитории GitHub. Чтобы подключиться к общедоступный репозиторий, выберите параметр "Использовать репозиторий ссылок", так как они не отображаются в раскрывающемся меню имени репозитория. Интеграция ADF с сервером GitHub Enterprise работает только с официально поддерживаемыми версиями сервера GitHub Enterprise.

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

Настройки GitHub

Область настройки содержит следующие параметры репозитория кода GitHub:

Изменение параметров репозитория

Если какие-либо корректировки необходимо внести в параметры настроенного репозитория GitHub, можно изменить.

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

Организации GitHub

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

Подключение к общедоступному GitHub или GitHub Enterprise Cloud впервые в Фабрика данных Azure

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

1. В панели конфигурация Git введите название организации в поле Учетная запись GitHub. Появится запрос на вход в GitHub.
2. Войдите с помощью учетных данных пользователя.
3. Вам предлагается авторизовать Фабрика данных Azure в качестве приложения с именем AzureDataFactory. На этом экране вы увидите возможность предоставить разрешение ADF для доступа к организации. Если этот вариант не показан для предоставления разрешения, попросите администратора вручную назначить разрешение через GitHub.

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

Уже подключено к общедоступному GitHub или GitHub Enterprise Cloud с помощью личная учетная запись

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

1. Перейдите в GitHub и откройте Settings (Настройки).

   

2. Выберите пункт Заявления. На вкладке Authorized OAuth apps (Авторизованные приложения OAuth) вы должны увидеть AzureDataFactory.

   

3. Выберите приложение и предоставьте приложению доступ к вашей организации.

   

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

Подключение к GitHub Enterprise Server

При подключении к GitHub Enterprise Server необходимо использовать личный маркер доступа для проверки подлинности. Узнайте, как создать личный маркер доступа при создании личного маркера доступа.

Известные ограничения GitHub

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

• GitHub Enterprise версии ниже 2.14.0 не работает в браузере Microsoft Edge.

• Интеграция GitHub с визуальными средствами разработки Фабрики данных работает только в общедоступной версии Фабрики данных.

Подключение к Azure DevOps Server 2022

При подключении к Azure DevOps Server 2022 необходимо использовать личный маркер доступа для проверки подлинности. Узнайте, как создать личный маркер доступа здесь.

Подключение к локальной среде Azure DevOps путем предоставления Azure DevOps Server URL и Azure DevOps Project Collection

Предоставьте маркер с областью доступа как чтение и запись для кода.

Управление версиями

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

Создание ветвей возможностей

Каждый репозиторий Git Azure Repos, связанный с фабрикой данных, имеет ветвь совместной работы. (main является ветвью совместной работы по умолчанию). Пользователи также могут создавать ветви компонентов, щелкнув +Создать ветвь в раскрывающемся списке ветвей.

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

Когда вы будете готовы объединить изменения из ветви компонентов с ветвью совместной работы, щелкните раскрывающийся список ветвей и выберите Создать запрос на вытягивание. Вы перейдете к Azure Repos Git, где можно создавать запросы на вытягивание, выполнять проверки кода и объединять изменения с ветвью совместной работы. (Значение по умолчанию — main.) Публикация в службе фабрики данных разрешена только из ветви совместной работы.

Настройка параметров публикации

По умолчанию фабрика данных создает шаблоны Resource Manager опубликованной фабрики и сохраняет их в ветвь с именем adf_publish. Чтобы настроить пользовательскую ветвь публикации, добавьте файл publish_config.json в корневую папку в ветви совместной работы. При публикации ADF считывает этот файл, ищет поле publishBranch и сохраняет все шаблоны Resource Manager в указанном расположении. Если ветвь не существует, фабрика данных автоматически создает ее. Ниже приведен пример того, как выглядит этот файл:

{
    "publishBranch": "factory/adf_publish"
}

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

Публикация изменений кода

После объединения изменений в ветви совместной работы (по умолчанию main) щелкните Опубликовать, чтобы вручную опубликовать изменения кода главной ветви в Фабрике данных.

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

Рекомендации по интеграции с Git

Разрешения

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

• Всем участникам команды следует предоставить разрешения на чтение Фабрики данных.
• Предоставить разрешение на публикацию в Фабрику данных нужно только определенным пользователям. Для этого у них должна быть роль участника Фабрики данных в группе ресурсов, которая содержит Фабрику данных. Дополнительные сведения о разрешениях см. в статье Роли и разрешения для службы "Фабрика данных Azure".

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

Использование паролей из Azure Key Vault

Рекомендуется использовать Azure Key Vault для хранения строк подключения или паролей или проверки подлинности с помощью управляемого удостоверения для связанных служб Фабрики данных. По соображениям безопасности фабрика данных не хранит секреты в Git. Любые изменения в связанных службах, содержащие секреты, такие как пароли, публикуются немедленно в службе "Фабрика данных Azure".

Использование Key Vault или проверки подлинности MSI также упрощает непрерывную интеграцию и развертывание, так как вам не придется предоставлять эти секреты во время развертывания шаблона Resource Manager.

Устранение неполадок интеграции Git

Устаревшая ветвь публикации

Ниже приведены примеры ситуаций, при которых ветвь публикации может устареть.

• У пользователя несколько ветвей. В одной из ветвей функциональности пользователь удалил связанную службу, которая не использует AKV (такие службы публикуются немедленно, независимо от того, находятся ли они в Git или нет), но не выполнил слияние ветви функциональности с ветвью совместной работы.
• Пользователь изменил фабрику данных с помощью пакета SDK или PowerShell.
• Пользователь переместил все ресурсы в новую ветвь и пытался выполнить публикацию впервые. Связанные службы нужно создавать вручную при импорте ресурсов.
• Пользователь передает связанную службу, которая не использует AKV, или JSON Integration Runtime вручную. Он ссылается на этот ресурс из другого ресурса, такого как набор данных, связанная служба или конвейер. Связанная служба, не связанная с AKV, созданная через пользовательский интерфейс, публикуется немедленно, так как учетные данные должны быть зашифрованы. Если вы отправляете набор данных, ссылающийся на связанную службу, и пытаетесь опубликовать ее, пользовательский интерфейс разрешает его, так как он существует в среде Git. Он будет отклонен во время публикации, поскольку не существует в службе фабрики данных.

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

Вариант 1. Использование функции Перезаписать интерактивный режим

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

Поток кода: ветвь совместной работы —> режим реального времени

Вариант 2. Отключение и повторное подключение репозитория Git

Код импортируется из динамического режима в ветвь совместной работы. Код в динамическом режиме считается достоверным источником.

Поток кода: динамический режим —> ветвь совместной работы

1. Удалите текущий репозиторий Git.
2. Настройте Git повторно с теми же параметрами, но обязательно включит параметр Import existing Data Factory resources to repository (Импорт существующих ресурсов фабрики данных в репозиторий) и выберите пункт Collaboration brunch (Ветвь совместной работы).
3. Создайте запрос на вытягивание, чтобы выполнить слияние изменений с ветвью совместной работы.

При необходимости выберите любой из методов.

Все ресурсы отображаются как новые при публикации

Во время публикации все ресурсы могут отображаться как новые, даже если они были опубликованы ранее. Это может произойти, если свойство lastCommitId сброшено для свойства фабрики repoConfiguration при повторном развертывании шаблона ARM для фабрики либо путем прямого обновления свойства repoConfiguration с помощью PowerShell или REST API. Продолжая публиковать ресурсы, можно устранить проблему, но чтобы предотвратить ее повторение, не обновите свойство repoConfiguration фабрики.

Переключение на другой репозиторий Git

Чтобы переключиться на другой репозиторий Git, перейдите на страницу конфигурации Git в центре управления в разделе Система управления версиями. Щелкните Отключить.

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

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

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

• Дополнительные сведения о мониторинге и управлении конвейерами см. в статье Отслеживание фабрики данных Azure с помощью программных средств.
• Сведения о непрерывной интеграции и развертывании (CI/CD) в Фабрике данных Azure см. в этой статье.