Управление исходным кодом в Azure Data Factory

ПРИМЕНИМО К: Azure Data Factory Azure Synapse Analytics

Совет

Data Factory в Microsoft Fabric — это следующее поколение Azure Data Factory с более простой архитектурой, встроенным ИИ и новыми функциями. Если вы не знакомы с интеграцией данных, начните с Fabric Data Factory. Существующие рабочие нагрузки ADF могут обновляться до Fabric для доступа к новым возможностям в области обработки и анализа данных, аналитики в режиме реального времени и отчетов.

• Start a Fabric бесплатная пробная версия.
• Переход с Azure Data Factory на Data Factory в Microsoft Fabric

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

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

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

Кроме того, вы можете ссылаться на Континуальную интеграцию и развертывание (CI/CD) в Azure Data Factory, чтобы подробнее узнать о более широкой схеме CI/CD, где контроль версий является критически важным аспектом.

Примечание.

Мы добавили общедоступную поддержку GitHub на Azure Gov и Microsoft Azure, которыми управляет 21Vianet. Подробнее см. блог объявлений.

Чтобы узнать больше о том, как Azure Data Factory интегрируется с Git, посмотрите 15-минутное учебное видео ниже.

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

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

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

Примечание.

При настройке репозитория Git в пользовательском интерфейсе Azure Data Factory отключено прямое создание, используемое через службу Azure Data Factory. Изменения, внесенные с помощью PowerShell или пакета SDK, публикуются непосредственно в службе Фабрики данных и не вводятся в Git.

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

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

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

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

Способ настройки 2: Среда разработки

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

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

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

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

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

Примечание.

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

Автор с интеграцией Azure Repos Git

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

Примечание.

Вы можете хранить файлы скриптов и данных в репозитории Azure Repos Git. Однако необходимо вручную отправить файлы в Azure Storage. Конвейер фабрики данных не автоматически отправляет скрипты или файлы данных, хранящиеся в репозитории Azure Repos Git, в Azure Storage. Дополнительные файлы, такие как шаблоны ARM, скрипты или файлы конфигурации, могут храниться в репозитории за пределами сопоставленной папки. При этом помните, что для сборки и развертывания файлов, хранящихся вне сопоставленной Azure DevOps папки, требуется дополнительная задача.

параметры Azure Repos

Панель конфигурации проводит вас шаг за шагом через настройку следующих параметров репозитория кода:

Настройка	Описание	Значение
Тип репозитория	Тип репозитория кода Azure Repos.	Azure DevOps Git или GitHub
Microsoft Entra ID	Имя клиента Microsoft Entra.	<your tenant name>
Azure Repos Организация	Название организации в Azure Repos. Имя организации Azure Repos можно найти по адресу https://{organization name}.visualstudio.com. Вы можете войти в вашу организацию Azure Repos, чтобы получить доступ к своему профилю Visual Studio и просмотреть свои репозитории и проекты.	<your organization name>
Имя проекта	Название вашего проекта Azure Repos. Имя проекта Azure Repos можно найти по адресу https://{organization name}.visualstudio.com/{project name}.	<your Azure Repos project name>
Имя репозитория	Имя репозитория кода Azure Repos. Azure Repos проекты содержат репозитории Git для управления исходным кодом по мере роста проекта. Создайте репозиторий либо используйте репозиторий, который уже имеется в проекте.	<your Azure Repos code repository name>
Ветка совместной работы	Ваша ветка совместной работы в Azure Repos, которая используется для публикации. По умолчанию это main. Измените этот параметр, если нужно опубликовать ресурсы из другой ветви.	<your collaboration branch name>
Ветка публикации	Ветвь публикации — это определенная ветвь в репозитории, в которой хранятся и обновляются связанные с публикацией шаблоны ARM. По умолчанию это adf_publish.	<your publish branch name>
Корневая папка	Корневая папка в ветви совместной работы Azure Repos.	<your root folder name>
Import existing Data Factory resources to repository (Импорт существующих ресурсов фабрики данных в репозиторий)	Указывает, следует ли импортировать существующие ресурсы фабрики данных из инструмента создания пользовательского интерфейса Authoring canvas в репозиторий Azure Repos Git. Установите флажок, чтобы импортировать ресурсы фабрики данных в связанный репозиторий Git в формате JSON. Это действие экспортирует каждый ресурс по отдельности (то есть, связанные службы и наборы данных будут экспортироваться в отдельных файлах JSON). Если этот флажок не установлен, имеющиеся ресурсы не импортируются.	Установлен (по умолчанию)
Ветвь для импорта ресурса	Указывает, в какую ветвь импортируются ресурсы фабрики данных (конвейеры, наборы данных, связанные службы и т.д.). Вы можете импортировать ресурсы в одну из следующих веток: a. "Совместная работа" Создать новый элемент. Использовать существующую

Примечание.

Если вы используете Microsoft Edge и не видите никаких значений в раскрывающемся списке учетной записи Azure DevOps, добавьте https://*.visualstudio.com в список надежных сайтов.

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

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

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

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

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

Внимание

Чтобы подключиться к другому Microsoft Entra ID, пользователь, вошедший в систему, должен быть частью этого Active Directory.

Используйте личный аккаунт Microsoft

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

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

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

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

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

Дополнительные сведения о подключении Azure Repos к Active Directory вашей организации см. в статье Connect your Azure DevOps organization to Microsoft Entra ID.

Автор с интеграцией GitHub

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

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

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

Примечание.

Если вы используете Microsoft Edge, GitHub корпоративная версия менее 2.1.4 не работает с ней. GitHub официально поддерживает >=3.0, и все это должно быть хорошо для ADF. Когда GitHub меняет минимальную версию, поддерживаемые версии ADF также изменяются.

параметры GitHub

Примечание.

Если возникает ошибка Не удалось перечислить репозитории GitHub. Пожалуйста, убедитесь, что имя учетной записи правильно, и у вас есть разрешение на выполнение действия., убедитесь, что используете правильное имя владельца, а не URL-адрес репозитория GitHub.

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

Параметр	Description	Value
Тип репозитория	Тип репозитория кода Azure Repos.	GitHub
Use GitHub Enterprise Server	Флажок для выбора GitHub Enterprise Server.	Не установлен (по умолчанию)
GitHub URL-адрес корпоративного сервера	Корневой URL-адрес GitHub Enterprise (должен быть HTTPS для локального GitHub корпоративного сервера). Например: https://github.mydomain.com. Требуется только в том случае, если выбран Use GitHub Enterprise Server	<your GitHub Enterprise Server URL>
владелец репозитория GitHub	GitHub организация или учетная запись, которая владеет репозиторием. Это имя можно найти из https://github.com/{owner}/{repository имени}. Переход на эту страницу требует ввести учетные данные OAuth для вашей организации или учетной записи в GitHub. Если выбрать Use GitHub Enterprise Server, появится диалоговое окно, чтобы ввести маркер доступа.	<your GitHub repository owner name>
Имя репозитория	Имя репозитория кода GitHub. GitHub учетные записи содержат репозитории Git для управления исходным кодом. Создайте репозиторий либо используйте уже имеющийся в учетной записи. Укажите имя репозитория кода GitHub при выборе Выбрать репозиторий.	<your repository name>
Ссылка репозитория Git	Ссылка на репозиторий кода GitHub. Укажите ссылку на репозиторий кода GitHub при выборе Использовать ссылку на репозиторий.	<your repository link>
Ветка совместной работы	Ваша ветка GitHub для совместной работы, используемая для публикации. Значение по умолчанию — main (главная). Измените этот параметр, если нужно опубликовать ресурсы из другой ветви. Вы также можете создать новую ветвь совместной работы здесь.	<your collaboration branch>
Ветка публикации	Ветвь репозитория, где хранятся и обновляются ARM-шаблоны, связанные с публикацией.	<your publish branch name>
Корневая папка	Корневая папка в ветви совместной работы GitHub.	<your root folder name>
Импорт существующих ресурсов в репозиторий	Указывает, следует ли импортировать существующие ресурсы фабрики данных из холста разработки пользовательского интерфейса в репозиторий GitHub. Установите флажок, чтобы импортировать ресурсы фабрики данных в связанный репозиторий Git в формате JSON. Это действие экспортирует каждый ресурс по отдельности (то есть, связанные службы и наборы данных будут экспортироваться в отдельных файлах JSON). Если этот флажок не установлен, имеющиеся ресурсы не импортируются.	Установлен (по умолчанию)
Импортировать ресурс в эту ветвь	Указывает, в какую ветвь импортируются ресурсы фабрики данных (конвейеры, наборы данных, связанные службы и т.д.).

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

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

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

Скриншот с флажком для отключения кнопки публикации в студии Azure Data Factory.

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

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

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

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

1. В области конфигурации Git введите имя организации в поле GitHub Account. Появится запрос на вход в GitHub.
2. Войдите с помощью учетных данных пользователя.
3. Вам предлагается авторизовать Azure Data Factory как приложение с именем 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 Enterprise Server находится в локальной частной среде, поэтому вам потребуется полный контроль над брандмауэром, политиками сети и VPN при использовании этой проверки подлинности. Дополнительные сведения см. в разделе About GitHub Enterprise Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
    "publishBranch": "factory/adf_publish"
}

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

Примечание.

Фабрика данных считывает файл publish_config.json только при загрузке фабрики. Если на портале уже загружена фабрика, обновите браузер, чтобы изменения вступили в силу.

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

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

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

Внимание

Главная ветвь не отражает того, что развернуто в службе Data Factory. Главную ветвь нужно обязательно опубликовать вручную в службе Data Factory.

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

Разрешения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Удалите текущий репозиторий Git.
2. Настройте Git повторно с теми же параметрами, но обязательно включите параметр «Импорт существующих ресурсов фабрики данных в репозиторий» и выберите пункт «Ветвь совместной работы (тот же филиал)».
3. Создайте pull request для слияния изменений с ветвью совместной работы.

Примечание.

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

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

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

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

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

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

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

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

Внимание

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

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

• Дополнительные сведения о мониторинге и управлении конвейерами данных см. в статье Мониторинг и управление конвейерами программно.
• Сведения о реализации непрерывной интеграции и развертывания см. в статье Continuous integration and delivery (CI/CD) в Azure Data Factory.