Почему Trunk Based Development - лучшая модель ветвления // Андрей Александров, Express 42)
ฝัง
- เผยแพร่เมื่อ 14 มี.ค. 2019
- "Почему Trunk Based Development - лучшая модель ветвления", Андрей Александров (Express 42)
В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.
Слайды: speakerdeck.com/devopsmoscow/... - วิทยาศาสตร์และเทคโนโลยี
Леруа, если вы это увидите - СПАСИБО что исправили 5ти месячный косяк с черным меню вариантов поиска, я думал - не доживу
1:39 Ветки должны жить не более 2х дней.
6:15 ничего не мешает посмотреть PR спустя 5 дней :)
Почему-то ни у кого не возникло три логичных вопроса:
1) Что будет если постоянно отвлекать программиста на 2-10 минутные ревью чужого кода? Обычно вы пилите фичу и вы погружены в неё, вам не хочется отвлекаться. Имхо, если программиста дёргать каждые 10 минут, то его производительность упадёт практически до нуля. Если типичная фича занимает 5-6 коммитов, то получается что каждому разработчику нужно отвлечься примерно 6 раз в час на ревью, и это ужасно. А если будет смотреть не вся команда, а только 2-3 человека, то не соблюдается то, о чем говорит автор: каждый член команды знает все изменения во всех местах (зачем это вообще?). Если в команде много человек, то по-моему это привращается в неконтролируемый ад. В свою очередь, обычные пулл реквесты (branch by feature) обеспечивают возможность нормально ревьюить всю задачу за раз.
2) Во что превращается code review, если все фичи разбиты на изменения абстракций, и еще они все перемешаны в мастере (не идут последовательно)? Тут мне кажется очевидно, что когда ревьюишь фичу, хочется видеть все относящиеся к ней измнения вместе, а не искать по миллиону разбитых и перемешанных коммитов в мастере.
3) Как можно быстро переключаться между фичами, если разрешено мержить в мастер незаконченную функциональнось? Рассмотрим пример с колёсами из доклада: я сделал фичу на половину, дошёл до пулл реквеста в котором поменял первые колёса, а вторые пока не успел. Залил в мастер. Теперь приходит PM/лид и говорит: срочно переключись на другую задачу. Ок, переключаюсь, неизвестно на сколько. Пока я её делаю, мы решили задеплоиться. Автор доклада говорит, что мастер при таком подходе всегда deploy ready. Окей, деплоим, в прод попадает машина с двумя разными колёсами.
Может быть я что-то не понял)
Update: Эти вопросы скорее всего разжёваны на оф сайте модели ветвления(trunkbaseddevelopment.com), но мои вопросы адресованы именно к докладу и докладчику, эти моменты как будто вообще никто не заметил
1. Палка о двух концах. Что будет, если разработчик ждет ревью своего ПРа по 2-3 дня? Берет другую задачу, начинает её делать. Его ПР смотрят, он оставляет вторую задачу возвращается к первой, отправляет правки по первой задаче, отдает на ревью снова, возвращается ко второй задаче. И так далее. А может еще и третью задачу возьмет, если вторую успеет сделать. Были в такой ситуации? Я был. И был в ситуации описанной автором. С точки зрения разработки лично для меня продуктивней иногда отвлекаться, но при этом чтобы твои ПРы не застревали. Отправил ПР, его посмотрели и ты сразу же доделываешь, либо закрываешь задачу и берешь следующую.
По поводу ревью 6 раз в час - вы работали в командах, где отправляют 6 ПРа в час?)) Надуманный пример мне кажется.
2. Аргумент из разряда "зачем декомпозировать фичу, давайте всё разом бахнем". Маленькие задачи закрывать легче, чем большие. Декомпозиция всегда влечет за собой некую долю того, что ты держишь в уме "сначала я делаю а потом б и потом в". И не всегда "а", "б" и "в" выглядят понятными в отрыве от остальных шагов. Надо разговаривать с тем, кто ПР отправил, чтобы прояснить ситуацию)) Как это относится к TBD или gitflow - непонятно.
3. Если бизнес логика допускает машины с разными передними и задними колесами, то в таком случае ПР, где меняются только передние колеса допустим. Если бизнес правила не допускают разных колес то и ПР такой нельзя делать, ты в таком случае ломаешь мастер и он больше не deploy ready. Если разработчик решил закоммитить дичь, то TBD магическим способом не вылечит мастер и не сделает его deploy ready. Поговорку про то, что всё можно сломать знаете)
Кстати, если логичных вопроса два, то какой из этих трех нелогичный? 😜
@@ilyaeremin4329
1. С ожиданием код ревью 2-3 дня нет проблем, всегда помню что я писал 2-3 дня назад. Ваш пример логичный, но согласитесь отвлекаться раз в 1-2 дня лучше чем раз в 15-20 минут? Вообще такие переключения с задачи на задачу это нормальная часть процесса, мне кажется. И кстати пока читал, подумал что ведь не зря крупные компании нанимают fullstack-ов и убирают ежедневные созвоны? Это как раз для того чтобы не отвлекать разработчика, он взял себе кусок работы и сделает его, без тупых отвлечений на ревью чужого кода каждые 20 минут. Ну и опять-таки, ваш пример усугубляет сам себя: вы представьте если те же самые 2-3 задачи пересекутся, и надо будет ревьить 18 ПРов (условно по 6 на каждую фичу), и вы будете переключаться между этими маленькими. Я бы назвал это чистым адом.
По поводу 6 ПРов в час: да, работал, компания называется Яндекс.
2. Вот это полная бредятина сразу же. "Надо разговаривать с тем, кто ПР отправил, чтобы прояснить ситуацию))". Да, действительно, вот это очень удобно. Особенно когда коммитов 6. Да и вообще, по тому что я сейчас вижу в российском биг теке, никто не использует trunk based у себя. И даже не думает в его сторону. При этом я отлично понимаю что декомпозия это замечательная штука, но использование её здесь - явно ошибка. "Маленькие задачи закрывать легче, чем большие." А у вас цель какую задачу закрыть? Маленькую или большую? Большую. Вот и не выебывайтесь, закрывайте её у себя локально как хотите, можете декомпозировать хоть на 1000 абстракций, но только локально. Можете еще разбить всё по коммитам в ветке, будет тоже хорошо. Но скидывать по отдельному ПРу не надо, это бред. Человек который будет это смотреть будет думать типо: "а где остальной код-то, когда ждать? Пойду на перекур на 15-20 минут, а он пока еще один ПР откроет". Это просто ужас, таких ожиданий быть не должно быть. Возможно я что-то не так понял, но выглядит именно так. Пока что вообще не понимаю как всякие гуглы и прочие работают с этим (так утверждает автор).
3. Бизнес-логика чаще всего не допускает машин с разными колёсами. Часто видите на улице машины с разными колёсами? Я нет. Получается что здесь декомпозировать задачу никак. Ну и смысл тогда этого примера? Если мне придётся заливать одним ПРом изменения всех колёс, то это уже почти то же самое, что заливать всю задачу одним ПРом. Пример автора тупо не работает, он высосан из пальца. Если уж пытаешься показать что-то, то надо показывать на реальных жизнеспособных вещах. Я вот сейчас читаю это еще раз, и думаю: судя по всему автор какой-то лох который повёлся на новенькое, ну ведь нельзя было так облажаться, сказать про deploy ready и показать НЕ deploy ready пример.
По поводу двух логичных вопросов добавил апдейт у первого комментария)
@@user-zu6ts5dx7z
1. Согласен, что чем реже отвлекаешься, тем лучше. Но тут важно понимать что из этого следует. Большие ПРы -> дольше ревью. За эти 2-3 дня могут поменяться требования. И уже помимо правок по ПРу если они будут, карточка уходит на дополнительную работу. В итоге ты работаешь над двумя карточками. Что не конец света, но не самая приятная ситуация. Это нормальная ситуация для вас потому что ВЫ к ней привыкли. Что лучше: работать над одной задаче и переходить к другой или переключаться между задачами?
2-3 задачи не пересекутся при tbd, потому что ревью происходит быстро. Я завершил задачу, её посмотрели, я её смержил (либо доработал и вернул на ревью снова). ВСЁ. Я забыл про этот ПР и перешел к следующей задаче. В этом прелесть.
Сколько человек было в команде яндексе, в которой вы работали? В том компоненте, над которым вы работали. Интересно откуда 6 ПРов в час.
По поводу фулстека тут можно поспорить почему компании так делают, но вряд ли в первую очередь потому чтобы разработчики меньше отвлекались, скорей чтобы сократить расходы на найм. Но про митинги согласен, просто ненавижууу (сижу на одном из них и пишу вам).
2. "общаться с коллегами - бредятина" (с) Егор Пищальников 2021 😂. Если фичу можно разбить и отправить в прод часть и это не помешает бизнесу - так и нужно делать. Чем чаще ты интегрируешь код в мастер, тем проще каждая интеграция, тем проще понять что пошло не так. Вас же не смущает, что прилетают правки по фичам, которые уже в проде и вы работаете над ними. В чем проблема сделать то же самое, но разбить её самостоятельно не нарушая бизнес требований?
Опять же, вы пишете, что у того, кто смотрит ПР будет возникать вопрос "когда ждать следующий ПР". Его не надо ждать. Каждый ПР может быть смержен в мастер и забыт. То, что ПРы маленькие, не означает что в одном ПРе я коммичу "@уй пи3@а", а во втором "джигурда". Конечно ПРы должны иметь смысл в отрыве друг от друга. Забейте вы про карточки, которые вам создают менеджеры, они без понятия как пишется код и как лучше менегерить ваш транк.
3. Пример про колеса абстрактный, такой вы занудный)) Но, если вы уж полезли в подробности, то
а. Согласно пдд на разные оси авто допускается установка разных шин (а значит колес).
б. Некоторые авто с идут с разными колесами на осях с ЗАВОДА.
в. Разные колеса не рекомендуются на полноприводных авто. Быстрый гугл говорит, что меньше половины авто в России полноприводные.
Получается в большинстве случаев, если брать Россию, бизнес логика допускает разные колеса на оси, Раз уж взялись утверждаете что-то, не палите наобум))
Обратно к коду... Я уже выше писал, разница большими ПРами и маленькими, чтобы интегрировать ВАШИ изменения с мастером как можно чаще. Если что-то сломается вы узнаете это раньше. Смысл тут есть даже в примере этими колесами. Когда ты создаешь абстракции вокруг функционала, чтобы потом поменять реализацию и выкатываешь эти изменения, то так ты можешь проверить конкретно эти изменения. Не появилось новых ошибок в проде = ты молодец, рефактор у тебя действительно рефактор. Это будет минус одна вещь, на которую придется задумчиво смотреть в случае если в проде будет косяк.
Можно копить изменения в одном ПРе и разом мержить, то это больше тестирования, больше мест, где что-то могло сломаться. Если задача дробится сильней, то почему нет? Я не говорю, что это надо делать всегда, но если вместо задачи на 5 дней, ты можешь сделать 3 задачи поменьше, то это может иметь смысл. Конечно мало смысла разбивать задачу на пару часов еще сильней, сама декомпозиция займет может занять больше времени. Короче смысл именно в том, чтобы избежать долгоживущих веток и всех неудобств, которые они с собой несут (мерж конфликты, более сложная интеграция в мастер, долгий ревью).
@@ilyaeremin4329 ты победил.
Можно сделать умное назначение ревьюера. Из тех, кто уже целый час ничего не ревьюил )
Вот читаю комментарии и почему ни у кого не возникает вопрос о том, а как внедрить фича флаги в код, да и еще так, чтобы эта херота нормально работало и управлялась. И не менее важный момент заключается в том, что никто не говорит как не нужный код потом убирать из проекта. А то получается что гавнокода накрутили, а потом его там же и оставили, отключив его лишь неким флагом.
ну обычно на таблице завязываются где прописаны какой фича флаг его описание и статус, и просто через if завязываются на блоке коде которым нужно управлять, но как будто элегантней можно через аннотации
смешно видеть в спонсорах такой конфы леруамерлен с его вечно глючным и неудобным сайтом
А что за книжка?
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
"SOLID нам говорит - делай объект и делай вокруг него еще и абстракцию" 🙈дети дядюшки Боба, которые пихают абстракции где нужно и где нет :) Тут наверное, если колесо было покрыто Unit Test-ом, то абстракция скорее всего уже была создана для мока и ее создание вызвано необходимостью клиента (сам Test выступает в качестве полноценного клиента кода), а не следованию принципа покрыть все интерфейсами. Советую Теплякова почитать на эту тему
ИМХО. Мне кажется, что Trunk Base Development так активно продвигается девопсами по заговору. Т.к. по сути это отвратительный вариант. Единственный плюс которого - это самый простой, быстрый и ленивый вариант - конвеер тупо льёт всё подряд безконрольно (если тесты на фичу не написали, значит и ошибки в них не будет :) ), контроль тупо на разработчике и администраторе системы - есть ли флаг, вкл его и выкл. :) Никто не проверит. Это, кхэм, простите, а с каких это пор у нас стала поставка НЕ работающих, не заверщённых и непротестированных фич в проде плюсом? :)
Чисто тупо мнение ленивых разработчиков времён, когда все пилили сразу в прод без всяких там гитов и прочей лабуды.
Какой еще Continuous Code Review? Вы бредите) Dave Farley никогда не упоминал ни про какой Continuous Code Review, потому что он достаточно умен и опытен что бы понимать, что это полная хрень) Вместо этого, он говорит про Pair Programming с постоянной ротацией пар. Но даже он признает, что эта методика хорошо работает для новых проектов, когда много чего еще не известно, но не особо продуктивна в условиях "рутинных" тасок ввиде накатывания бизнесс логики по готовым тех процессах с устоявшейся архитектурой и код конвеншнами.
Название наоборот