Azure Data Factory (ADF) – это мощный инструмент для управления и оркестрации рабочих процессов данных в облаке. При начале проекта ADF важно обдумать, как организовать ваш код и систему контроля версий. Одно распространенное заблуждение заключается в том, что каждая среда (Dev, Test, Prod) должна иметь свой собственный отдельный репозиторий Git. Однако Microsoft рекомендует отказаться от этого подхода, утверждая, что только разработческая фабрика должна быть связана с репозиторием Git.

Есть две основные причины, почему наличие нескольких репозиториев в ADF необязательно:

1. Сложность развертывания

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

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

2. Отклонение от общей практики DevOps

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

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

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

Вывод

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