Система управления версиями в Фабрике данных Azure
Область применения:
Фабрика данных Azure 
Azure Synapse Analytics
Совет
Попробуйте использовать фабрику данных в Microsoft Fabric, решение для аналитики с одним интерфейсом для предприятий. Microsoft Fabric охватывает все, от перемещения данных до обработки и анализа данных в режиме реального времени, бизнес-аналитики и отчетности. Узнайте, как бесплатно запустить новую пробную версию !
По умолчанию пользовательский интерфейс Фабрики данных Azure подразумевает разработку непосредственно в службе фабрики данных. Этот интерфейс имеет следующие ограничения:
- Служба фабрики данных не включает репозиторий для хранения сущностей JSON для изменений. Единственный способ сохранить изменения — нажать кнопку Опубликовать все, чтобы опубликовать все изменения непосредственно в службе фабрики данных.
- Служба фабрики данных не оптимизирована для совместной работы и управления версиями.
- Шаблон Azure Resource Manager, необходимый для развертывания фабрики данных, не включен.
Чтобы повысить эффективность разработки, Фабрика данных Azure позволяет настроить репозиторий Git с помощью Azure Repos или GitHub. Git — это система управления версиями, упрощающая отслеживание изменений и совместную работу. В этой статье описывается, как настроить и работать в репозитории Git вместе с выделением рекомендаций и руководством по устранению неполадок.
Вы также можете изучить статью Непрерывные интеграция и поставка в Фабрике данных Azure, чтобы узнать больше о более крупном шаблоне CI/CD, важной составляющей которого является управление версиями.
Примечание.
Мы добавили общедоступную поддержку GitHub в Azure Gov и Microsoft Azure под управлением 21Vianet. Подробнее см. блог объявлений.
Дополнительные сведения о том, как Фабрика данных Azure интегрируется с Git, см. в 15-минутном учебном видео ниже:
Преимущества интеграции с Git
Ниже приведен список некоторых преимуществ, которые интеграция с Git предоставляет для разработки:
- Управление версиями. По мере того как рабочие нагрузки фабрики данных становятся важными, необходимо интегрировать фабрику с Git, чтобы применить несколько преимуществ системы управления версиями, как показано ниже:
- Возможность отслеживания и аудита изменений.
- Возможность отмены изменений, из-за которых появились ошибки.
- Частичные сохранения: при создании в службе фабрики данных невозможно сохранить изменения в виде черновика, а все публикации должны пройти проверку фабрики данных. Если конвейеры не завершены или вы просто не хотите терять изменения при сбое компьютера, интеграция Git позволяет добавочные изменения ресурсов фабрики данных независимо от того, в каком состоянии они находятся. Настройка репозитория Git позволяет сохранять изменения, позволяя публиковать только после тестирования изменений в удовлетворенности.
- Совместная работа и управление. Если у вас несколько участников команды, участвующих в одной фабрике, может потребоваться разрешить коллегам сотрудничать друг с другом с помощью процесса проверки кода. Вы также можете настроить фабрику таким образом, чтобы у участников были разные разрешения. Некоторые члены команды могут быть разрешены только вносить изменения через Git, и только некоторые люди в команде могут публиковать изменения в фабрике.
- Лучше ci/CD: если вы развертываете в нескольких средах с непрерывным процессом доставки, интеграция Git упрощает определенные действия. Некоторые из этих действий включают:
- Настройка конвейера выпуска для автоматического запуска при внесении изменений в фабрику dev.
- Настройка в фабрике свойств, доступных в качестве параметров в шаблоне Resource Manager. Это может быть полезно для хранения только требуемого набора свойств в качестве параметров и иметь все остальное жестко закодированное.
- Повышенная производительность. Средняя фабрика с интеграцией с Git загружает данные в 10 раз быстрее, чем при разработке в службе фабрики данных. Повышение производительности связано с тем, что ресурсы загружаются через Git.
Примечание.
При настройке репозитория Git разработка непосредственно в службе фабрики данных отключена в пользовательском интерфейсе Фабрики данных Azure. Изменения, внесенные с помощью PowerShell или пакета SDK, публикуются непосредственно в службе Фабрики данных и не вводятся в Git.
Подключение к репозиторию Git
Существует четыре разных способа подключения репозитория Git к фабрике данных для Azure Repos и GitHub. После подключения к репозиторию Git вы можете просматривать конфигурацию и управлять ею в центре управления в разделе "Управление версиями" в разделе "Управление версиями".
Метод настройки 1. Домашняя страница
На домашней странице Фабрики данных Azure выберите вверху Настройка репозитория кода.
Метод настройки 2. Холст разработки
На холсте разработки Фабрики данных Azure выберите раскрывающееся меню Фабрика данных, а затем выберите пункт Настройка репозитория кода.
Метод настройки 3. Центр управления
Перейдите в центр управления в Фабрика данных Azure Studio. В разделе Система управления версиями выберите Конфигурация Git. Если у вас нет подключенного репозитория, нажмите кнопку "Настроить".
Метод конфигурации 4. Во время создания фабрики
При создании новой фабрики данных на портале Azure можно указать сведения о репозитории Git на вкладке Git configuration (Конфигурация Git).
Примечание.
При настройке git на портале Azure параметры, такие как имя проекта и имя репозитория, должны быть введены вручную, а не в составе раскрывающегося списка.
Author with Azure Repos Git integration (Разработка с использованием интеграции Git с Azure Repos)
Визуальная разработка с помощью интеграции Git Azure Repos поддерживает управление исходным кодом и совместную работу для создания конвейеров фабрики данных. Фабрику данных можно сопоставить с репозиторием организации Git Azure Repos для управления исходным кодом, совместной работы, управления версиями и т. д. В одной организации Git Azure Repos может быть несколько репозиториев, но репозиторий Git Azure Repos может быть связан только с одной фабрикой данных. Если у вас нет организации Azure Repos или репозитория, создайте их, следуя этим инструкциям.
Примечание.
Вы можете хранить файлы данных и сценариев в репозитории Git Azure Repos. Но в службу хранилища Azure файлы необходимо отправлять вручную. Конвейер фабрики данных автоматически не отправляет в службу хранилища Azure файлы данных и сценариев, которые хранятся в репозитории Git Azure Repos. Дополнительные файлы, такие как шаблоны ARM, скрипты или файлы конфигурации, могут храниться в репозитории за пределами сопоставленной папки. При этом помните, что для сборки и развертывания файлов, хранящихся вне сопоставленной папки Azure DevOps, требуется дополнительная задача.
Параметры Azure Repos
В области конфигурации пошаговые инструкции по настройке каждого из следующих параметров репозитория кода:
| Параметр | Description | Значение |
|---|---|---|
| Тип репозитория | Тип репозитория кода 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 (Импорт существующих ресурсов фабрики данных в репозиторий) | Указывает, следует ли импортировать имеющиеся ресурсы фабрики данных из пользовательского интерфейса Работа над холстом в репозиторий Git Azure Repos. Установите флажок, чтобы импортировать ресурсы фабрики данных в связанный репозиторий Git в формате JSON. Это действие экспортирует каждый ресурс по отдельности (то есть, связанные службы и наборы данных будут экспортироваться в отдельных файлах JSON). Если этот флажок не установлен, имеющиеся ресурсы не импортируются. | Установлен (по умолчанию) |
| Branch to import resource into (Ветвь для импорта ресурсов) | Указывает, в какую ветвь импортируются ресурсы фабрики данных (конвейеры, наборы данных, связанные службы и т.д.). Вы можете выбрать для импорта ресурсов один из следующих вариантов: 1) "Совместная работа"; 2) "Создать"; 3) Использовать существующую |
Примечание.
Если вы используете Microsoft Edge и не видите никаких значений в раскрывающемся списке Azure DevOps Account (Учетная запись Azure DevOps), добавьте https://*.visualstudio.com в список надежных сайтов.
Изменение параметров репозитория
Если какие-либо корректировки необходимо внести в параметры настроенного репозитория Azure Repos Git, можно выбрать команду "Изменить".
Вы можете обновить ветвь публикации и решить, следует ли отключить кнопку публикации из студии ADF. Если вы решили отключить кнопку публикации из студии, кнопка публикации неактивна в студии. Это помогает избежать перезаписи последнего автоматического развертывания публикации.
Использование другого клиента Microsoft Entra
Репозиторий Azure Repos Git может находиться в другом клиенте Microsoft Entra. Чтобы указать другой клиент Microsoft Entra, необходимо иметь разрешения администратора для используемой подписки Azure. Дополнительные сведения см. в разделе "Администратор подписки изменений".
Внимание
Чтобы подключиться к другому идентификатору Microsoft Entra, пользователь, вошедший в систему, должен быть частью этого Active Directory.
Использование личной учетной записи Майкрософт
Чтобы использовать личную учетную запись Майкрософт для интеграции с Git, можно связать личный репозиторий Azure с Active Directory вашей организации.
Добавление личной учетной записи Майкрософт в Active Directory вашей организации в качестве гостя. Дополнительные сведения см. в разделе "Добавление пользователей совместной работы Microsoft Entra B2B" в портал Azure.
Войдите в портал Azure с помощью личной учетной записи Майкрософт. Перейдите в Active Directory вашей организации.
Перейдите к разделу Azure DevOps, где находится личный репозиторий. Выберите репозиторий и подключитесь к Active Directory.
После этих шагов настройки личный репозиторий доступен при настройке интеграции Git в пользовательском интерфейсе Фабрики данных.
Дополнительные сведения о подключении Azure Repos к Active Directory организации см. в Подключение организации Azure DevOps с идентификатором Microsoft Entra.
Author with GitHub integration (Разработка с использованием интеграции GitHub)
Визуальная разработка с помощью интеграции 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 действовать от имени пользователя, чтобы получить доступ к репозиториям на основе разрешений доступа пользователя.
Примечание.
Если вы используете Microsoft Edge, с ним не будут работать версии GitHub Enterprise старше 2.1.4. GitHub официально поддерживает >=3.0, и все они должны нормально работать с ADF. По мере изменения минимальной версии GitHub поддерживаемые версии ADF также изменяются.
Настройки GitHub
Область настройки содержит следующие параметры репозитория кода GitHub:
| Параметр | Description | Value |
|---|---|---|
| Тип репозитория | Тип репозитория кода Azure Repos. | GitHub |
| Использование GitHub Enterprise Server | Установите флажок, чтобы выбрать GitHub Enterprise Server. | Не установлен (по умолчанию) |
| URL-адрес GitHub Enterprise Server | Корневой URL-адрес GitHub Enterprise (должен быть HTTPS для локального сервера GitHub Enterprise). Например: https://github.mydomain.com. Требуется только в том случае, если выбран сервер GitHub Enterprise Server |
<your GitHub Enterprise Server URL> |
| Владелец репозитория GitHub | Организация или учетная запись GitHub, принадлежащие репозиторию. Это имя можно найти из https://github.com/{owner}/{repository имени}. Переход на эту страницу запрашивает ввод учетных данных OAuth GitHub в организацию или учетную запись GitHub. Если выбрать GitHub Enterprise Server, появится диалоговое окно, чтобы ввести маркер доступа. | <your GitHub repository owner name> |
| Имя репозитория | Имя репозитория кода GitHub. Учетные записи GitHub содержат репозитории Git для управления исходным кодом. Создайте репозиторий либо используйте уже имеющийся в учетной записи. При выборе выбора репозитория кода GitHub укажите имя репозитория кода 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, можно изменить.
Вы можете обновить ветвь публикации и решить, следует ли отключить кнопку публикации из студии ADF. Если вы решили отключить кнопку публикации из студии, кнопка публикации неактивна в студии. Это помогает избежать перезаписи последнего автоматического развертывания публикации.
Организации GitHub
Для подключения к организациям GitHub необходимо, чтобы организация предоставляла Фабрике данных Azure разрешение на доступ. Чтобы разрешить подключение фабрики данных, пользователь с разрешениями администратора в организации должен выполнить следующие действия.
Подключение в общедоступный GitHub или GitHub Enterprise Cloud впервые в Фабрика данных Azure
Если вы подключаетесь к общедоступному GitHub или GitHub Enterprise Cloud из Фабрика данных Azure впервые, выполните следующие действия, чтобы подключиться к организации GitHub.
- В панели конфигурация Git введите название организации в поле Учетная запись GitHub. Появится запрос на вход в GitHub.
- Войдите с помощью учетных данных пользователя.
- Вам предлагается авторизовать Фабрика данных Azure в качестве приложения с именем AzureDataFactory. На этом экране вы увидите возможность предоставить разрешение ADF для доступа к организации. Если этот вариант не показан для предоставления разрешения, попросите администратора вручную назначить разрешение через GitHub.
После выполнения этих действий фабрика может подключаться как к общедоступным, так и к частным репозиториям в организации. Если вы не можете подключиться, попробуйте очистить кэш браузера и повторить попытку.
Уже подключено к общедоступному GitHub или GitHub Enterprise Cloud с помощью личная учетная запись
Если вы уже подключены к общедоступному GitHub или GitHub Enterprise Cloud и предоставили только разрешение на доступ к личная учетная запись, выполните приведенные ниже действия, чтобы предоставить разрешения организации.
Перейдите в GitHub и откройте Settings (Настройки).
Выберите пункт Заявления. На вкладке Authorized OAuth apps (Авторизованные приложения OAuth) вы должны увидеть AzureDataFactory.
Выберите приложение и предоставьте приложению доступ к вашей организации.
После выполнения этих действий фабрика может подключаться как к общедоступным, так и к частным репозиториям в организации.
Подключение на сервер GitHub Enterprise Server
При подключении к GitHub Enterprise Server необходимо использовать личный маркер доступа для проверки подлинности. Узнайте, как создать личный маркер доступа при создании личного маркера доступа.
Примечание.
GitHub Enterprise Server находится в локальной частной среде, поэтому вам потребуется полный контроль над брандмауэром, политиками сети и VPN при использовании этой проверки подлинности. Дополнительные сведения см. в разделе о 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 Server URL среду Azure DevOps путем предоставления и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 может использовать только одну ветвь публикации за раз. При указании новой ветви публикации Фабрика данных не удаляет предыдущую ветвь публикации. Если вы хотите удалить предыдущую ветвь публикации, сделайте это вручную.
Примечание.
Фабрика данных считывает файл publish_config.json только при загрузке фабрики. Если на портале уже загружена фабрика, обновите браузер, чтобы изменения вступили в силу.
Публикация изменений кода
После объединения изменений в ветви совместной работы (по умолчанию 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. Использование функции Перезаписать интерактивный режим
Она публикует или перезаписывает код из ветви совместной работы в динамическом режиме. Он считает код в репозитории источником истины.
Поток кода:Ветвь совместной работы -> Live mode (Динамический режим)
Вариант 2. Отключение и повторное подключение репозитория Git
Код импортируется из динамического режима в ветвь совместной работы. Код в динамическом режиме считается достоверным источником.
Поток кода:Live mode (Динамический режим) -> Ветвь совместной работы
- Удалите текущий репозиторий Git.
- Настройте Git повторно с теми же параметрами, но обязательно включит параметр Import existing Data Factory resources to repository (Импорт существующих ресурсов фабрики данных в репозиторий) и выберите пункт Collaboration brunch (Ветвь совместной работы).
- Создайте запрос на вытягивание, чтобы выполнить слияние изменений с ветвью совместной работы.
Примечание.
Создать и объединить запрос на вытягивание необходимо только в том случае, если вы работаете в репозитории, который не разрешает прямые фиксации. В большинстве организаций отправки в репозиторий требуют проверки перед объединением, поэтому рекомендуется использовать этот подход. Но в некоторых случаях проверка не требуется, в этом случае не требуется создавать и объединять запрос на вытягивание, но изменения могут быть зафиксированы непосредственно в ветви совместной работы.
При необходимости выберите любой из методов.
Все ресурсы отображаются как новые при публикации
Во время публикации все ресурсы могут отображаться как новые, даже если они были опубликованы ранее. Это может произойти, если свойство lastCommitId сброшено для свойства фабрики repoConfiguration при повторном развертывании шаблона ARM для фабрики либо путем прямого обновления свойства repoConfiguration с помощью PowerShell или REST API. Продолжая публиковать ресурсы, можно устранить проблему, но чтобы предотвратить ее повторение, не обновите свойство repoConfiguration фабрики.
Переключение на другой репозиторий Git
Чтобы переключиться на другой репозиторий Git, перейдите на страницу конфигурации Git в центре управления в разделе Система управления версиями. Щелкните Отключить.
Введите имя фабрики данных и нажмите кнопку Подтвердить, чтобы удалить репозиторий Git, связанный с фабрикой данных.
После удаления связи с текущим репозиторием можно настроить параметры Git для использования другого репозитория, а затем импортировать существующие ресурсы фабрики данных в новый репозиторий.
Внимание
При удалении конфигурации Git из фабрики данных из репозитория ничего не удаляется. Фабрика содержит все опубликованные ресурсы. Вы можете продолжить изменять фабрику непосредственно в службе.
Связанный контент
- Дополнительные сведения о мониторинге и управлении конвейерами см. в статье Отслеживание фабрики данных Azure с помощью программных средств.
- Сведения о непрерывной интеграции и развертывании (CI/CD) в Фабрике данных Azure см. в этой статье.