На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
- GitFlow противоречит тезису "ветки должны быть короткоживущими".
Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических) - GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого. - GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
- GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
Так что делать-то?
Автору оригинальной статьи помог trunk-based development + feature flags — почти гугловый green trunk, но не совсем. Но это совсем не значит, что этот подход нужен именно вам.
Во-первых нужно понять приоритеты.
Как выглядят ваши релизы?
- Они короткие или длинные? Вы хотите релизиться раз в пару часов, дней, недель, или у вас коробочные продукты, которые выкатываются раз в полгода?
- Сколько занимает время самого релиза? Это может быть от пары минут до даже дней, если у вас есть долгоживущие клиенты, которые подключены по WebSockets, и не хотят отваливаться. Всякое бывает.
- Нужно ли поддерживать старые или будущие релизы? Есть ли у вас LTS-релизы, в которые вы обязаны делать backport-ы (это когда вы чините баг в основной ветке, а потом идете, и еще раз чините его в ветке 2016 года) изменений? Есть ли у вас canary и beta-релизы?
- Есть ли у вас вообще Continuous Delivery?
Кто работает в репозитории?
- Все (или почти все) ли члены команды самодостаточны, или им нужен фидбек старших товарищей? Нужны ли вам полноценные циклы design review и merge/pull-request-ов, или среднее время на PR — это 5 минут на каждые 100 строк кода?
- Работает ли в репозитории много команд, или только одна?
Есть ли у вас автоматизированные средства для проверки качества кода? Ну, или хотите ли вы их внедрить?
- линтеры
- проверки типов
- автотесты: юнит-тесты, интеграционные тесты и так далее
Очень важно понимать, что релизный процесс и рабочий процесс — это вообще разные потоки. Тут без вариантов, любой flow поверх гита так или иначе это делает, разделяя изменения и релизы. Работа с этими двумя процессами похожа на работу с очередями вроде Apache Kafka или SQS — есть ряд источников, которые помещают обновления в очередь, и есть ряд указателей-релизов, которые смотрят на какой-то момент в прошлом, периодически поднимаясь вверх по этой очереди.
Изменения разработчиков и релизы — это абсолютно разные вещи. Релиз включает в себя пачку (от одного до бесконечности) изменений разработчиков, да, но он не обязательно должен включать в себя всю сделанную разработчиком фичу, он может забрать, допустим, пару созданных им для работы классов или функций, но не реализованную задачу, и это нормально.
Важно понимать, что если вам иногда требуется релиз, даже если изменений нет — вы что-то делаете не так. Иногда такое происходит, когда требуется обновить базовый JSON или YAML, который забирается во время сборки от внешнего поставщика — секреты, переводы, внешняя конфигурация.
Это неправильно, потому что это завязка на внешний фактор риска, и это неправильно, потому что это можно обновлять наживую во время работы с продакшном — автоматически или по кнопке, и в ситуации, когда это нужно будет сделать срочно — вы будете ждать полноценного релиза. Все, что можно вынести из релизного процесса, стоит вынести из него. Релиз — это дорогая операция, и если вы можете уменьшить их количество при той же скорости производства — стоит это делать.
Собираем свой flow
В общем случае вам будет нужна единая мастер-ветка, в которую будут попадать все изменения. Очень сложно представить ситуацию, где все вместе работают над отдельными задачами, синхронизируясь друг с другом время от времени (если это не поддержка старых версий). Есть подход, в котором заводится отдельная ветка для документации или для отдельного проекта, но по сути это отдельный репозиторий в рамках общего, и к нему надо относиться точно так же, хотя это практика, которая может привести к расхождениям между кодом и документацией к нему, а так же к невозможности одновременно держать документацию, скажем, к v1 и v2 решениям.
В целом, если вы можете жить в монорепозитории, стоит это делать. Да, нужно разово все настроить, но у вас нет никаких значимых плюсов в отдельных репозиториях, кроме потенциального риска плохо настроенного и тормозящего CI, а потенциальных минусов очень много: про преимущества монорепозиториев написана не одна и не две статьи.
Если ваши релизы частые — нужно явно внедрять Continuous Delivery.
Время релизного инженера — это издержки, которые будут расти при росте количества релизов и количества deliverables. Лучше потратьте время разработчика на что-то еще, рук не хватает всем и всегда, даже если вы Google. По личной статистике — около 10% ресурсов команды -в абсолютно разных проектах — в среднем уходят на релиз-инженера, если релизы не автоматизированы.
Для автоматизации релизов надо разово вложиться в инфраструктуру. Это разовая издержка, которая включает в себя:
Хорошие автотесты
CI-автоматику для выкладки релизов
Если у вас сервера и deliverables:
- prestable/staging-окружения
- механизмы быстрого отката
- мониторинги и alert-ы (в идеале интегрированные с авто-откатами)
- аварийные сценарии (если релиз не прошел или прошел частично)
Если у вас публикация пакетов или артефактов — все зависит от вашего flow, но я буду рад помочь с построением релизного механизма, пишите
Если релизы редкие, нужны backport-ы ИЛИ если в один момент времени потенциально может существовать более чем один обслуживаемый релиз — они явно будут существовать в отдельных ветках, которые не должны мерджиться обратно. После того, как вы отбранчуете эту ветку от основной рабочей (master/develop/trunk), вам может понадобиться внести в них несовместимые изменения, или просто отдельные коммиты. Для второго есть отличный механизм в git — cherry-picking. Ваши изменения должны "течь" только в одну сторону — от разработчиков в прод, из прода в основную рабочую ветку им попадать в действительности не нужно.
- Чем меньше и атомарней коммиты, тем меньше проблем при их переносе
- Используйте агрессивные правила линтинга, которые защитят вас от ненужных конфликтов. В случае с JS — есть пара хороших наборов eslint-правил. Prettier может подойти в вашем случае (но не гарантированно).
Если у вас больше, чем 5-6 разработчиков, или опытная команда — вам может подойти подход trunk-based development для повседневной работы разработчиков (но не обязательно, что для релизов). Если счет разработчиков в одном репозитории идет на сотни — или вы хотите объединить сотни разработчиков в одном репозитории, у вас почти нет альтернативных вариантов, разве что сменить git на что-то еще. Google рапортовал в разных статьях о значительном приросте производительности после перехода на этот подход, но, к сожалению, цифры разнятся, хотя и значимы во всех источниках. Facebook не сообщает о цифрах, но известно, что они тоже пользуются этим подходом.
Несмотря на то, что Trunk-based — это просто "вливайте минимальные изменения сразу в рабочую ветку", он, в отличии от других подходов, требует вложений в инфраструктуру и настройку ее под себя. В целом, кроме обычных CI/CD, вам потребуется еще:
механика feature flags — это разовая издержка.
Для однопакетного репозитория стоимость внедрения сильно непредсказуема, но в целом должна быть не очень большой.
Для монорепозитория же она примерно пропорциональна количеству пакетов в монорепозитории. Переведите 2-3 разных и экстраполируйте, будет относительно точная, но слегка завышенная (потому что чем дальше, тем проще) оценка
В случае работы с короткоживущими ветками — merge queue, а в случае работы прямо в транке — механизм отката коммитов, не проходящих тесты.
второй вариант сделать сложнее, и он теоретически может провоцировать конфликты, так что лучше короткоживущие ветки.
В целом, эволюционный механизм для любого типичного проекта сейчас выглядит как-то так:
- github-flow
- осознание потребности контроля за качеством кода
- внедрение CI, автотестов
- осознание потребности релизных механизмов
- внедрение чистого git-flow или его вариации (любое решение с долгими ветками + релизными ветками)
- осознание потребности в CD
- настройка git-flow под свои нужды, внедрение CD, staging-релизов, интеграция с внешними инструментами
- осознание проблемы с синхронизацией работы разработчиков
- долгая работа над возможностью внедрения trunk-based и разгребание технического долга
- переход на trunk-based-подобный подход
Но забегать вперед — не всегда лучшая идея. Иногда стоит посидеть на github-flow или отложить разгребание техдолга (или на время нанять отдельного GitOps-а — да, такая роль и профессия теперь тоже есть). Более того, ваша реализация может и скорее всего должна начать отличаться от "эталонной". Это нормально, и много разных команд работают в своих собственных парадигмах, если описывать тут их все — это вполне может выйти в отдельный цикл статей.
Поймите, на каком этапе вы, что у вас болит, и что можно сделать, чтобы не болело.
Ваш Git — это часть вашей инфраструктуры и кодовой базы, в нем точно так же копится технический долг, и его точно так же надо обслуживать. К сожалению, это не очевидно для большинства, и это зачастую спотыкается о непонимание команд и руководителей.
Если вы ощущаете, что ваш Git делает вам больно — напишите мне, я буду рад помочь.
