⚪️ История про git flow для оркестратора, часть 1

Когда я задумал сделать себе операционный оркестратор (который потом назвался dd-flow) идея была такая: я "закидываю" работу в оркестратор, и он "впиливает" эту работу дальше автоматически, важно, чтобы "закидывание" было процессом асинхронным. Типа, можете добавлять несколько параллельных задач, которые будут реализованы, и автоматически смержены в проект.

Чтобы это все работало, предполагался простой флоу: от главной ветки делаем фичабранчи (оптимизируя это через worktree, чтобы чекауты бранчей были покомпактнее).

Вроде бы все просто. Но есть нюансы. Нюанс называется "релиз". Если у вас ci/cd, то любой мерж в origin сразу триггерит релиз. На каждую вмерженную фичу это неудобно.

Усложним. Делаем две главные ветки:
* main. Пуш в main триггерит релиз.
* develop. Главная ветка разработки, в нее собираем все фичи. Как набрали достойное количество - переливаем все в main, вот вам и релиз.
* hotfix пока решил не делать, вроде не было нужды.
* Решил что впоследствии мой main будет релизить beta.project.com, а в прод будем промоутить после тестирования beta если все ок. почти ничего не будем менять.

Теперь мы все вливаем в итоге в origin/develop. Выяснилось, что оркестратору реально нужно иметь свой локальный чекаут origin/develop, которым только он управляет. Это важно для работы очереди мержей.

Очередь мержей: разберем, что это такое. Когда параллельно пилятся куча разных задач/фич, то "вливать" итоги в develop нужно все равно по одному в некоей четкой последовательности. Это важно для обеспечение консистентности и стабильности develop: ветка должна быть всегда "зеленой", то есть на ней всегда должны проходить все тесты и она должна собираться в продукт. При вливании нужно решать конфликты, что требует синхронности - решать проблемы шаг за шагом. Вот эту последоватльность и обеспечивает очередь мержей, это такой механизм в оркестраторе.

Очередь мержей важно чтобы не косячилась и не зависала - важно чтобы механизм работал. Она должна всегда легко синхрониироваться с origin/develop. Пришлось сделать много гардов, чтобы они ее периодически обслуживали - сервисный чекаут был бы на origin/develop, чтобы на нем чеки проходили зелеными. В оркестраторе сервисные операции оказалось довольно удобно делать: организуем детерминированные команды, а если что то идет не так - у нас есть агентный флоу для фикса! И state, возможность переживать остановки, и ui чтобы если что - пользователя вовлечь к решению проблемы. Удобно.