Гибкая схема очень.
1. сложность кода этих доп. компонентов на уровне джуна/мидла
2. из 1 следует, что вы имеете полный контроль над этими компонентами
3. если тянуть даги напрямую из гита встает вопрос: как организовать деплой из любой ветки. Деплой из мастера как правило только в розовый мечтах тимлидов из кровавого энтерпрайза, в реальности, в небольших командах регулярно есть необходимость деплоя из своей собственной ветки.
4. возможность построения гибкой схемы хранения на S3. Например, мы при деплое дага указываем его версию, на S3 улетает даг в директорию вида [dag-id]-[version], плюс на этом же уровне лежит файлик current-version с последней версией дага отправленного на деплой.

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

А nexus для этих целей не рассматривали? Или с3 просто был и поэтому решили его использовать?

nexus для других целей инструмент)) а s3 да, просто был уже

он предполагает работу с немного другим уровнем абстракции: артифакт, ну, и прочее гавно, верно))
а тут тупо директорию с файликами закинуть надо.

Гибкая схема очень.
1. сложность кода этих доп. компонентов на уровне джуна/мидла
2. из 1 следует, что вы имеете полный контроль над этими компонентами
3. если тянуть даги напрямую из гита встает вопрос: как организовать деплой из любой ветки. Деплой из мастера как правило только в розовый мечтах тимлидов из кровавого энтерпрайза, в реальности, в небольших командах регулярно есть необходимость деплоя из своей собственной ветки.
4. возможность построения гибкой схемы хранения на S3. Например, мы при деплое дага указываем его версию, на S3 улетает даг в директорию вида [dag-id]-[version], плюс на этом же уровне лежит файлик current-version с последней версией дага отправленного на деплой.

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

Получается, что у вас могут быть dag_xxx_master_v4 и dag_xxx_branch_v2? И все они висят в веб-интерфейсе? Или как-то удаляете старые dag-и?

Павел, есть еще вопросы по этой теме:

1 А как проверяется что один даг другой не сломает?
2 Есть тестовый стенд чтобы как то проверять?
3 Как накатываются конфиги?

1. если один даг ломает другой даг, то это очень плохой даг)))
2. отедльного выделенного тестового стенда нет, была задача под это в бэклоге, но отказались пока от отдельной тестовой среды. Вероятно, понадобится с ростом команды и процессов. Все etl процессы у нас построены таким образом, что на 100% воспроизводимы на локальных машинах разработчиков. Если запустилось на локалхосте, то запустится на проде.
3. Про какие конфиги речь?

3 Конфиги имеется ввиду Variables

Подскажите как можно получить доступ к JSON вставленному в UI в окне Trigger DAG?