CTO: Порядок из хаоса

К вам уже приходили в этом году с вопросом "ожидаем х4 трафик, сервер выдержит?"
Новый год к нам мчится, а с ним и сезонные нагрузки.

Самый простой способ ответить на этот вопрос — бахнуть нагрузочный тест.
Посмотреть сколько вообще система переваривает, и как растут метрики под нагрузкой.
А если нет еще сервера, или вы сидите на интервью по систем дизайну, или вам для тех плана "монолит в микросервисы за 3 года!" нужно прикинуть сколько и каких железок нужно, что делать?

Давайте учиться считать. Как минимум на секции систем дизайна пригодится.

Что мы имеем.
Нужно держать 3000 rps, время ответа около 200ms.

1) нам нужно понять сколько CPU способны переваривать такой объем.
Запускаем профилировщик запроса (который будет крутиться на сервере), выкидываем оттуда I/O, обращения по сети, запросы к БД и прочему. Нас интересует только CPU time.
Обычно это 1-20ms на каждый запрос, у нас допустим 10 (для простоты счета). 1000ms / 10ms = 100 запросов в секунду в 1 потоке можем переваривать в идеальных условиях. Но, помните про теорию очередей и кривую утилизации? Умножаем на 0.6 (утилизация не более 60%) и получаем что нам нужно 3000 (rps) / (100 (запросов на ядро) * 0.6 (утилизация)) = 50 vCPU
Важно, 1 vCPU != "1 физическое ядро моего ноутбука". Снимайте профиль на целевой платформе а не у себя на ноуте.
Если CPU time 2ms — нужно 10 vCPU, если 20ms — 100 vCPU. Собственно поэтому так важна каждая миллисекунда CPU.

2) Кроме CPU на серверах еще и оперативная память есть.
Тут тоже все просто, количество запросов в системе в единицу времени умноженное на количество памяти необходимое на 1 запрос. (Вспоминаем закон Литтла, вот тут писал недавно)
У нас 3к rps. Время ответа 200ms. На 1 запрос требуется 80Mb.
Получаем 3000 * 0.2 * 80 =48Gb
А если время ответа 150ms а запрос потребляет 60Mb?
3000 * 0.15 * 60 =27Gb почти в 2 раза меньше, хотя мы поджали 25% задержку и на 20% оптимизировали по памяти (по отдельности не выглядит как что то сверх невероятное).
Модель грубая, в реальности потреблять будет меньше, из-за кэшей, пулов, куч/стеков/горутин (смотря что у вас за язык). Но порядок цифр посчитать удастся. Ну и утилизацию держим в районе 50-70%, остальное съедят I/O, системные/сайдкары, пики, фрагментация, GC.

Итого.
Чтобы держать 3к RPS при задержке 200ms и утилизации 60% нам потребуется 50vCPU и 80Gb памяти. При 10ms CPU time и 80Mb на запрос.
В реальности у вас будут естественно другие цифры, но порядок тот же.

PS. Есть сервисы где требуются экстремальные p99 — там утилизация вообще до 30-40% может опускаться, возможно у вас такой сервис (трейдинг, гейминг, финтех, etc), имейте это ввиду.

А вот и аналитика по инженерной зрелости компаний(статья на хабре), в которой многие из вас участвовали.
Помните мы устраивали опрос?
Большое спасибо всем кто принял в нем участие.
Ответ каждого из вас сделал эту статью более глубокой и честной.

А вот вам выводы для затравки
1) Для роста нужно не геройство, а системность
2) мы релизим так же хреново как ведем документацию. (такая вот авторская интерпретация подтвержденная цифрами)

притяного чтения)

PS. спасибо ребятам осуществлявшим информационную поддержку, без вас результаты были бы в разы скромнее)

я в поиске новой команды
той где нужно потушить жопки и зажечь глаза
подробности можно узнать в линкедин (буду благодарен за репосты, коменты, лайки) или в личке @TigAndTig
если знаете команду которой нужно помочь — дайте знать или помогите нам встретитсья) 🫶

Привет. 
Как обычно принес что то полезное, но в этот раз сначала спрошу)
Кто знает в середине спринта успеет команда закрыть задачи в этот раз или нет?
А кто знает через сколько реально завершится эпик который пилим уже 2 месяца и переносим сроки в третий раз?
Сколько было scope creep за этот спринт? А за предыдущий? За минуту сможете ответить?

В большинстве команд до 20 человек это все неизвестные. PM в лучшем случае в последней четверти спринта начинает понимать что не справились. И понимание строится  на основе количества задач в колонке "в работу".

Фиксится все это (неопределенность, а не проблема) обычным burndown chart (вот тут мини статья от jira, для понимания).

Но просто подключить и смотреть — мягко говоря бессмысленно. Давайте разберемся "что там показывают".
Скорость сгорания — тут понятно. Сколько закрыли в день.
Требуемая скорость — и тут понятно. Сколько нужно закрывать в день чтобы успеть.
Стабильность скопа — это скачки на диаграмме когда вы добавляете таски или меняете оценку у текущих.
Риск не успеть — чем больше разница между фактической и требуемой скоростью сгорания — тем выше шанс что вы зафакапите (и сколько зафакапите).
Блокеры — горизонтальные участки без сгорания при неизменном скопе. Оказывается и это тоже видно, даже без вопросов команде.

Посмотри на burndown за последние 3-4 спринта и все проблемы как на ладони...

Чем это помогает,
Если актуальная скорость ниже требуемой пару дней — пора что то делать.
Перепреоритезация внутри спринта. Важное (в вашем понимании) в начало, неважное в хвост или под нож.
Управление скопом. Если тренд стабильно хуже — выбросьте пару задач еще в середине спринта вместо героического дожимания. Это снимет эффект забитой колонки.
Увидел плато — опять же, пора что то делать.

Типичные паттерны
Если начинает гореть только к концу спринта — упираетесь в тесты/ревью/деплой. Нужно обратить внимание, распараллелить, усилить.
Если скоп на графике часто растет — проблема с DoR, планированием, и залетающими горящими задачами.
Если сгорает лесенкой — батч ревью/релизы, нет потока. (Как со сгоранием к концу спринта, но не так страшно)
Рваная линия — плохое дробление и неверные оценки. (Больше внимания декомпозиции задач и системе оценок)

Грубые оценки.
При 2х недельном спринте на 3 день должно сгореть 20-25%. Если нет — вы уже отстаете.
Изменения скопа больше 10% — пересматривайте цели, если хотите управлять а не надеяться.
Предсказание. Оставшееся / средняя скорость за 3 дня. Если результат больше чем осталось дней в спринте — вы не успеваете, не обманывайте себя.

Скинь PM'у, или подключай сам.
Всего час чтобы досконально разобраться во всех нюансах, и ты в другой лиге.

Ну что, закончили с понедельничной утренней рутиной?
Вышла моя статья на Хабре "Когда дашборды лгут. Гайд по перцентилям, очередям и e2e-бюджету" (продолжение постов на канале тык и тык )

5-7 минут на чтение, картинки, формулы и чуть чуть про способы бюджетирования e2e задержек

Хорошего дня и приятного чтения)

Сегодня поговорим про закон Литтла (Little’s Law).
И совсем немножко про математику.

Формула простая: L = λ × W
L — среднее количество элементов в системе (например запросов в обработке или элементов в очереди)
λ — средняя скорость поступления элементов (запросов в секунду)
W — среднее время, которое элемент проводит в системе
Формула — проще некуда, но очень полезная.

Сколько запросов обрабатывается одновременно?
Дано: λ = 100 req/s, W = 200ms
L = 100 × 0.2 = 20 запросов в системе одновременно
Теперь вы можете посчитать сколько к примеру на сервере будет съедено памяти и сколько используется коннектов к БД

Какая средняя задержка при заданной нагрузке?
Дано: λ = 50 req/s, L = 5 (лимит воркеров/соединений)
W = L/λ = 5/50 = 0.1s = 100ms - средняя задержка. При условии что воркеры справляются можете писать в SLA 100ms. (но сначала дочитайте)

Какая пропускная способность у системы?
Дано: W = 300ms, L = 10 (лимит воркеров/соединений)
λ = L/W = 10/0.3 = 33.3 req/s максимум.

Всего за минуту мы с вами насчитали вон сколько полезного, но закон Литтла сам по себе не учитывает насколько загружена система.

Если поверх него добавить простейшую модель очереди (M/M/1), получится интересная зависимость. Детали опущу, много математики, сразу дам выводы.
При утилизации в 50% средняя задержка вырастет в 2 раза от базовой.
75% — в 4 раза.
90% — в 10 раз.
99% — в 100 раз.
При 100% загрузке — очередь неограниченно растет.
И это при условии идеализированной модели. В реальности и средняя и p95/p99 растет сильно быстрее.

Теперь вы знаете как посчитать нагрузку и почему нужно оставлять запас по утилизации серверов. (и заложите правильный запас для SLA)

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

Самое большое расхождение — в качестве код-ревью, почти 1,5 балла

Так что, если вы тимлид — вероятно, переоцениваете качество код-ревью.
Ну или если вы разработчик — вероятно недооцениваете.
Я хз..

Кто прав?))

Ну наконец то! Принимаю в комментариях шутки traktorist-like
Трехсотому подписчику персональный привет)🤝

Ребят, а вы знаете свою среднюю задержку по сервису?
Если да — вы уже делаете то, чего большинство не делает.

Если вы знаете задержку для каждого эндпоинта, участвующего в CUJ — это ещё круче.
Правда, тут легко наступить на грабли. Начнёте мониторить каждый эндпоинт отдельно — можете случайно положить свой мониторинг от кардинальности. Или получить красивый счёт от облачного провайдера. Даже не знаю что лучше.

Но главная проблема не в этом. Без p95/p99 у вас получается как в старом анекдоте — директор ест мясо, рабочие едят капусту, в среднем по компании все едят голубцы.

Окей, следим за p95/p99. Теперь-то точно всё под контролем?
Почти. Но есть нюанс.

Важно помнить, что перцентили не складываются и не усредняются — потому что это квантиль распределения, а не среднее значение. Считайте p95 через агрегированные гистограммы (суммируйте бакеты, потом считайте квантиль).
Если вы усредняете поминутные p95 за день — вы измеряете не задержку, вы измеряете надежду.

Это уже 3 из 5 уровней зрелости в работе с задержкой:
1) Нет измерений, "работает же".
2) Среднее время отклика.
3) Перцентили, но без latency budget.
4) E2E-бюджет, мониторинг хвоста, SLO.
5) Управление бюджетом и отмена запросов, прогнозирование.

Большинство компаний застряли на 2 уровне, искренне считая, что у них всё под контролем, и не могут перешагнуть на следующую ступеньку. Не потому что им не хватает мотивации или нет инструментов, а потому что 3-я ступенька — это про другое мышление. Переход от реактивного тушения пожаров к проактивному проектированию надёжности.

И как по мне — лучше до этой мысли дойти самостоятельно, чем после смачного пенделя от бизнеса.

Сегодня вышел пятничный пост на Хабре — про петуха на проекте.
Не с целью оскорбить тимлидов, а рассказать, какие бывают 🙂

Но кроме тимлидов у нас есть и другие роли.
- Ворона (PM). Сидит на заборе, громко каркает: «Мало яиц! Лиса близко! Корм заканчивается!». Не помогает, но информирует и следит, чтобы все были в курятнике вовремя. Иногда ворует яйца, но делает вид, что не она. Петух с ней не дружит, но на заборе достать не может.
- Белка (QA). Таскает яйца в разные места. «Из дупла выкатится? А если закопаю — протухнет? А если уронить — треснет?». Часть теряет, часть разбивает. Но те, что возвращает — проверены на все случаи жизни. Петух скрипит зубами, но терпит, качество дороже.
- Кролик (BA). Копается в куче соломы. «По статистике, 70% яиц несутся по утрам, 30% — когда фермер не смотрит!». Множит документацию на капустных листах и диаграммы из морковок. Куры в шоке. Петух косится подозрительно. Никто не признаётся, что документацию не читал.
- Выдра (DevOps). Живёт возле поилки, зачем-то крякает и ругается на тех, кто трогает воду руками. Может уронить корзину с яйцами просто проходя мимо. Петух постоянно чего-то от неё хочет, но не может объяснить что. Автоматизировала доставку яиц из гнезда в корзину, но все по старинке носят вручную.

Всем хорошей пятницы)

привет, ребят)
сегодня я немного отойду от формата канала, и вместо полезной информации попрошу вас стать соучастниками будущего большого поста и пары статей (ну одной так точно).

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

с ходу накину: если у вас жопа — вы просто в среднестатистической компании. вместе с костылями, фейлами и толком не работающими алертами. так что не расстраивайтесь)

но, "я своё отбоялся. отплакался, отбоялся, ваще по цензура" (с), поэтому я в поиске драйверов, которые дадут максимум профита с минимальным усилием всем и каждому.

на стартовом наборе данных уже нащупал корреляцию между скоростью пайплайнов и качеством код-ревью, между алертингом и качеством релизов. даже наличие или отсутствие конкретной роли в команде может очень сильно поменять картинку. например одна роль поднимает удовлетворение от релизов на 4 пункта (это просто пропасть). угадаете какая?

сейчас мы собираем расширенный набор данных, чтобы убрать шум и подтвердить предположения.
поэтому прошу каждого, кто добрался до этих строк, пройти опрос (ссылка на форму).
да, он не маленький, порядка 60 вопросов, но он работает в 2 стороны. не только помогает нам со сбором данных, но ещё и является чек-листом зрелости инженерных процессов внутри компании. 7-10 минут — и вы поймёте, что у вас не так.

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

PS. сбрось, пожалуйста, ссылку ребятам, кому может быть это интересно, особенно тем кто постоянно жалуется на процессы). чем больше респондентов, тем смелее мы сможем говорить о корреляциях (а там есть очень и очень любопытные)
PPS. спасибо всем, кто уже поддержал сбор данных в своих каналах, вы очень сильно забустили)

На заре своего становления как программиста я использовал trunk-based development (TBD).
Если это подходит для Гугла, Нетфликса и Фейсбука, с их тысячами коммитов в день — подойдёт и для меня. Логично же. Там не тупые ребята сидят, между прочим.

Я проработал так примерно полгода, пока на проект не пришли ещё два трейни.
И этот ваш TBD оказался полной хренью. Ну неудобно же! Постоянно конфликты, постоянно что-то отваливается. Кто это вообще придумал?
Мы тут с тремя коммитами справиться не можем, а они в своём Гугле тысячу в день льют...
В общем, мы посовещались — и перешли на GitFlow.

А всё почему?
А всё потому, что мы неправильно понимали TBD.
Оказалось, что это не ARAM (All Random All Master).
Если ты пушишь в мастер по вечерам, а утром пуллишь обратно — это не TBD.
Даже если ты пушишь с ребейзом, запустил тесты локально, делаешь merge request вместо прямого пуша в мастер — это все равно не trunk-based development...

Сейчас trunk уже нельзя представить без Merge Queue / Train — чтобы никто не ломал master.
- Без быстрого CI/CD — иначе ваши частые мержи будут висеть на длинных пайплайнах. (А если нет частых мержей, зачем вообще брали trunk?)
- Без feature flags — иначе вы не сможете запушить незавершённые фичи или быстро отключить фичу в случае фейла.
- Без короткоживущих, атомарных, итеративных веток — иначе получите большой дрейф и конфликты. Короткие MR — это основа trunk-ритма.
- Без быстрых автотестов (unit + integration) на каждый мерж.
- Без observability и алертов. (Формально это про CD Maturity, но я готов спорить до хрипоты, что это неотъемлемая часть любого флоу.)

Вот и получается, что trunk — это не про одну ветку и не про “пушим в мастер”,
а про зрелость команды и процессов, без которых всё превращается в ARAM и merge-hell.

Если у тебя эталонный trunk — похвастайся, бахни 😇 (если только на словах — 👻)

#GitFlowRelease

Вчера я упомянул протокол релиза.
А в этом посте писал про чеклист релиза.

В чём разница?
Чеклист — инструмент проверки. Он помогает убедиться, что ничего не забыли и не пропустили.
Протокол — инструмент управления. Он показывает, в какой последовательности выполняется, кто за что отвечает и по каким признакам, каждый шаг по отдеьности и релиз в целом, считается успешным.

В аттаче — базовый шаблон протокола релиза.

#GitFlowRelease

Когда-то у нас в команде была практика парных ночных релизов.

Не то чтобы это была какая-то гениальная стратегия — просто так исторически сложилось. Один разработчик проверял действия другого, подстраховывал, и вообще…
Парный ночной релиз... Сейчас понимаю насколько это было рисковано, но тогда мы верили, что это как минимум в два раза безопаснее, чем если бы релизил один.

Как это выглядело.
У одного — доступ к продакшену и руки, набирающие команды.
У другого — знания, в каком порядке мержить, как откатывать, что и как смокать.

Уже немного сомнительно, да?

И вот на одном из релизов «знающий» уснул. Просто вырубился от усталости. Ни докричаться в хадле, ни дозвониться на мобильный.
А второй, с руками но без контекста, остался в одиночестве посреди ночи.
Закончилось всё хэппи-эндом. К пяти утра, наощупь, методом проб и ошибок он всё-таки собрал релиз.

Для красивой истории тут я должен написать, что утром он предложил ввести протокол релизов, но ещё полгода вместо протокола у нас был кофе.

А потом мне наконец-то дали порулить.
Так в команде появился первый шаблон релиза. 30 минут времени и больше никакого кофе по ночам.

У вас релизы на людях или на процессах?
#GitFlowRelease

Серия: Gitflow & Release discipline. Пост 5/10 — трустори.
Все имена и события вымышлены. Любые совпадения случайны.
Далее — рассказ от имени моего воображаемого друга, который, конечно же, не я.

Однажды я уронил прод одной госструктуры.
Минут на пятнадцать. Но наглухо.
Не то чтобы я был злоумышленником — просто мы работали по принципу «мерж, молись, деплой».
Иногда связь с высшими силами пропадала. Или они были заняты.
И тогда деплой, мягко говоря, получался… не очень.

Мы старались, правда старались. Но раз в пару недель — обязательный факап.
Любой релиз был стрессом для всей команды.
Вероятность, что что-то отвалится, была сильно не нулевая.
А релизы у нас шли «как бог на душу положит»: то ни одного за две недели, то два за день.

Если два за день — это волнительно, то представьте, что творилось, когда накапливался мегапак за 2–3 недели.
Сто процентов что-то пойдёт не так.
А значит — нас снова ждёт лекция о «криворуких» и «уволить всех к чёртовой матери».
Мне кажется, я не один с такой историей.
 
Отчёт Harness — The State of Software Engineering Excellence 2025 говорит:
50 % деплоев всё ещё делаются вручную.
64 % пайплайнов содержат ручные шаги.
67 % команд не могут собрать и протестировать dev быстрее чем за 15 минут.
И 10 % компаний регулярно (!) ловят критические (!) баги на проде.

Выходит, я работал в абсолютно нормальной, среднестатистической компании.
Как и многие из вас, наверное.
Вот только беда в том, что «нормой» до сих пор считаются костыли, ручные операции и героизм вместо отстроенных процессов.

Ладно, поныли — теперь про хэппи-энд.

Сначала мы внедрили CI/CD-пайплайны.
Они убрали часть человеческих ошибок при деплое и упростили ролбэк.
Потом защитили master — теперь влить можно только через merge request с обязательным ревью.
Благо, с ревью проблем не было.
Дальше — зафиксировали даты релизов.
Ввели фриз за сутки: чтобы попасть в релиз, фича должна пройти локальное тестирование.
Менеджерам сначала досталось — клиенты привыкли «хочу здесь и сейчас».
Но доводы про качество подействовали.
И внезапно стало нельзя обещать всё на свете к следующему демо — пришлось сокращать скоуп спринта.
И о чудо:
ёмкость команды выросла,
багов стало меньше,
разработка — предсказуемее.
Даже QA вздохнули: очередь на smoke-тесты резко сократилась.
Фейл на проде стал событием из ряда вон, а не «ну мы же релизились, чего вы хотели».

Видели ли мы картину целиком, когда всё это начинали? Конечно нет.
Просто шаг за шагом делали чуть лучше. День за днём, неделя за неделей.
Итог — факапы в проде упали с 2-3 в месяц до 0 за квартал.

Это очень большой повод для гордости.
Если получилось у нас — получится и у вас.

Сегодня: делай ничего. Сегодня пятница, никаких изменений по пятницам.
В понедельник — протокол релиза end-to-end: шаги, роли, тайминги — чтобы «спокойно» стало нормой.

#GitFlowRelease

Серия: Gitflow & Release discipline.
Пост 4/10 — чем пахнет ваш флоу.

Знаете, чем пахнет огонь? Он пахнет палёными волосками в носу.
Вряд ли вы стали бы терпеть этот запах, или пробовать ещё раз.

Но с рабочими процессами всё иначе. Мы часто не замечаем запаха — или путаем один с другим.
Синильная кислота пахнет абрикосовыми косточками, а абрикосовые косточки — синильной кислотой.
Вкусно, но смертельно.

Нам кажется, что вроде всё работает как нужно, не замечая или игнорируя запахи.
А на деле наш флоу медленно расползается. Ошибки копятся и приводят к сбоям в системе.

Все знают, что по пятницам релизить нельзя. Это уже мем.
Но я готов поспорить — среди нас есть герои, у которых релизы проходят именно по пятницам.
Отзовитесь в комментах, расскажите свою печальную историю — пусть она спасёт кого-то.

Топ-5 причин, разрушающих процессы
0️⃣ Пятничный мердж (вне топа)
Релизы и крупные вливания делаются «перед выходными».
Плохо: повышает риск аварий и хотфиксов в субботу. Мы же любим работать по ночам и на выходных — никто не мешает.
Фикс: freeze с четверга, пятница — только хотфиксы и ретро.

1️⃣ PR/MR-кладбище
Десятки реквестов висят неделями без ревью.
Плохо: теряется контекст, растут конфликты, ревью становится фикцией.
Я не помню, что утром делал — а тут попробуй вспомни, о чём реквест, который был две недели назад…
Фикс: SLA на ревью ≤48 ч, дробите на более мелкие (в идеале < 400 LOC).

2️⃣ Слепой апрув
«Апрув веры». Или «лени». Или «заколебали, дайте поработать».
В общем, ревью на отвали — ради галочки, что ревью есть.
Плохо: ошибки уходят в прод, качество падает, ревью перестаёт быть префильтром и инструментом инженерной культуры.
Фикс: ≤3 ревью в день на человека; smoke-тест перед апрувом (если возможно); ревьюер несёт ответственность за мерж.

3️⃣ Плавающий релиз
Релиз «по готовности».
Плохо: предсказуемости нет, QA не успевают, разработка, тестирование и деплой живут в разных ритмах.
Фикс: фиксируйте день и час релиза.
Если не успели запилить фичу — не сдвигаем релиз на завтра, а переносим её в следующий релиз.

4️⃣ Долгие freeze’ы
В преддверии релиза всё замирает на несколько дней или даже недель.
Плохо: копятся долги, фичи, команда теряет темп.
Фикс: freeze ≤ 48 ч; включайте фичи под флагами, чтобы не блокировать разработку. (если применимо)

5️⃣ Дежурный герой
Один человек знает весь процесс и тащит всё сам.
Плохо: bus factor = 1. Отпуск, заболел, уволился — релизы встали колом.
Фикс: ротация DRI и явный протокол релиза (чтобы любой мог провести релиз при необходимости).


Сегодня: выберите один запах, который нервирует вас больше всего, и наметьте план фикса (или даже пофиксите).
Завтра — кейс как из «мерж, молись, деплой» вышли к стабильному ритму и нулевому CFR. (и такое бывает)

Кто релизит по пятницам — признавайтесь в коментах.

#GitFlowRelease

Серия: Gitflow & Release discipline.
Пост 3/10 — как выбрать схему ветвления под свой контекст.

Серия: Gitflow & Release discipline.
Пост 3/10 — как выбрать схему ветвления под свой контекст.
 
Что выбрать, gitflow или trunk? 🤨
Если выбирать только из 2 — вы потеряли минимум пару вариантов.
У нас есть 5 схем (не считая вариации), и у каждой своя польза, цена, и риск.
И важно не «что сейчас модно», а чего вы хотите избежать — потери скорости или потери предсказуемости.
 
Trunk-based — для быстрых циклов и фич под флагами. Минимум веток, максимум автоматизации. Стильно, модно, молодежно, микросервисно.
Gitflow (классика) — релизные ветки, freeze и кандидаты. Хорош, если есть QA-окна и регресс-пакеты.
GitLab Flow — упрощённая адаптация Gitflow под CI/CD: main + feature + hotfix, деплой по тегам.
Release Train Flow — "поездатый ритм" и фиксированные даты, работает при большом масштабе.
Environment Flow — отдельная ветка на среду, когда релизы проходят аудит (CAB, ISO, GxP). Динозавр из нулевых (крупные банки, фарма, телеком), сейчас используется редко.
Custom Mix — гибрид из trunk и release под ваш контекст, свои правила тегов, гейтов и вообще чего угодно. Опасно, но продуктивно — если знаешь, что делаешь.

Файл с матрицей и гайд — в следующем сообщении.
 
Сегодня: пройди матрицу выбора (5 стратегий × 16 критериев) — за 10 минут поймёшь, какой флоу минимизирует твой риск. (Может пора менять текущий?)
Завтра — разберем чем может пахнуть флоу.

А у вас — «сам решу» или «так исторически сложилось»? Будете менять?

Серия: Gitflow & Release discipline.
Пост 2/10 — релиз как процесс: «до / во время / после».

Релиз — это не кнопка «выкатить». Это процесс с тремя разными шагами и режимами ответственности.
Больше всего факапов случается на стыках — особенно между «во время» и «после», когда пропадает владелец шага и за продом никто не следит.
Чек-лист (в файле) закрывает именно эти стыки ответственности.

Если мыслить датой релиза — управлять рисками негде.
Мыслите фазами.
«До» — подготовка: freeze изменений, согласованный набор задач, план отката и чёткие критерии go/no-go. Цель — предсказуемость.
«Во время» — окно релиза: нужные люди на связи, сборка воспроизводима, быстрый smoke-тест, наблюдаемость в норме.
«После» — наведение порядка: back-merge, релиз-ноты, заметки по инцидентам, проверка алертов и таймингов.

Сегодня: назначьте владельцев для «до», «во время» и «после».

Завтра: покажу как выбрать схему ветвления под ваш контекст


💾 Сохраните пост и файл, поделитесь с тимлидом и QA.

#GitFlowRelease

Серия: Gitflow & Release discipline.
Пост 1/10 — ветки не спасут без релизной дисциплины.

Когда у вас следующий релиз? Если ответ — «как соберём» или «к концу спринта», на самом деле ответа нет. У релиза нет ритма и хозяина.

Gitflow сам по себе не даёт стабильности. Любая схема ломается, если релиз ведёт «кто свободен», а не назначенный владелец — DRI (Directly Responsible Individual, единолично отвечает за прохождение релиза по шагам). Без DRI срывается ритм, PR-ы тянутся неделями, растут «служебные» ветки ради видимости порядка — а хаос остаётся.

Мы видели это десятки раз: «по готовности» релизы копятся, баги приезжают пачками. Стоило ввести недельный ритм и DRI — и хаос начал исчезать.

Что работает: фиксированный ритм (например, раз в неделю), явный DRI на каждый выпуск и минимальные релиз-гейты — короткий список обязательных проверок.
Базовый набор: суточная заморозка релизов перед выкладкой, smoke-тест сразу после, готовый план роллбэка. Тогда ветки — инструмент управления риском, а не «магия из блога».

🗓️ Сегодня: за 15 минут зафиксируйте две ближайшие даты и частоту релизов. Назначьте DRI на каждый выпуск.
Завтра — чек-лист релиза на один экран: что проверить до/во время/после, чтобы ничего не упустить.

Как вы решали вопрос релизного ритма до сегодняшнего дня: фиксированные релизы, по готовности или «как получится»?
#GitFlowRelease