Comments 12
Я как техлид больше всех нарушал последнее правило. Смотришь мердж-реквест, видишь мелкую фигню и думаешь: «Сейчас я сам поправлю». Идешь, коммитишь, а потом видишь — изменения пропали. Потому что автор параллельно форс-пушнул что-то свое.
Так запретите форс-пуши.
Еще один лайфхак — мы отказались от релизных веток. Просто релизимся с транка. Законом не запрещено.
Похоже на Gitlab Flow.
Спасибо за комментарий!
Так запретите форс-пуши.
Мы запретили друг-другу работать в чужих ветках и оно работает ещё лучше :) Хочет автор сделать форс-пуш в своей ветке - пожалуйста. Если хочется сделать прям доработку - надо делать отдельную задачу+ветку, хочется поправить что-то в рамках текущей задачи/МР - оставляем комментарий и просим автора доработать. Думаю, тут главным злом было моё желание "да щас 5 сек сам сделаю".
Похоже на Gitlab Flow.
Сходства есть, но есть радикальное отличие в плане использования этих веток. В TBD ветки никуда не ставятся (ну, кроме локали), путь один - в trunk.
В целом, TBD - это не какая-то магия, прорыв или серебряная пуля, просто набор хороших практик, которые работают при соблюдении "правил игры". Но работать по нему довольно приятно, когда получилось настроить процесс.
Если автор хочет форс-пушнуть, значит ему не привили культуру совместной разработки. Его ветка только одна - на его машине. Всё, что на сервере - это общедоступные ветки, если в них подделывать историю, то это создаёт множество проблем: от конфликтов историй при синхронизации, до сломанного бисекта. Как техлид, вы должны это знать и не допускать.
Вы перепутали gitlab и gihub, это разные flow. Будьте внимательнее.
Если автор хочет форс-пушнуть, значит ему не привили культуру совместной разработки. Его ветка только одна - на его машине. Всё, что на сервере - это общедоступные ветки, если в них подделывать историю, то это создаёт множество проблем: от конфликтов историй при синхронизации, до сломанного бисекта.
Но если что-то пушнуть в ветку другого человека без его ведома, то это тоже не похоже на совместную разработку :)
И у меня возникает вопрос: а как же люди тогда ребейзят, сквоши делают и т. д.? Не имел проблем с форс-пушем, если он запрещен на защищённых ветках. Возможно, я ещё просто не обжёгся. Другой вопрос, что это в принципе инструмент довольно опасный, тут абсолютно согласен.
Вы перепутали gitlab и gihub, это разные flow. Будьте внимательнее.
Да, пардон, начал читать сверху, а ссылка вела на самый последний раздел, спасибо, что поправили. Тогда апдейт - да, действительно, идея похожая.
Есть тайная сущность разработчика: долго делаешь фичу, преодолеваешь проблемы, и когда все готово, хочется побыстрее от этого избавиться. Закидываешь мердж-реквест и думаешь: «Ребят, все, пока. Когда «вольете», сообщите».
Мы инвертировали ответственность. Зафиксировали в документации: за мердж-реквест отвечает его автор. Если он не попадает в транк в течение дня — это проблема автора.
Подождите, а что, быть ответственным за свой код - это была не норма? Кто лучше автора кода может разрешить мерж конфликт? О_о
Согласен, может звучать дико. При этом ответственность за свой код - штука довольно очевидная, и вряд ли кто-то это отрицает или искреннее не понимает. Но простая манифестация аля "чувак, если твой MR застрял, то иди попингай ревьюеров/мейнтейнеров" или "чувак, если твой MR долго смотрят, возможно стоит его разделить на куски" нам помогла ускорить процесс. Было на что ссылаться, и со временем такая культура укоренилась в команде. Возможно, больший эффект был именно от других мер, но, как говорится, из песни слов не выкинешь, делюсь всем :) Спасибо за комментарий!
Еще один важный элемент при таком подходе, это постоянно вливать в бранчи все изменения из транка (как правильно простенькой автоматизации хватает). Отсутствие мерж конфликта не означает, что изменения не конфликтуют на уровне бизнес логики. Поэтому для ревью необходимо иметь версию, где все тесты проходят на "текущей" версии транка.
Если нет релизных веток - то где править баги, которые обнаружили (клиенты) в релизе? В транке? Но он мог слишком сильно "убежать" вперед.
Вопрос отличный! Делюсь опытом.
Сейчас мы уже экспериментируем с Continuous Deployment, и в таком случае - всегда в транк.
А если вернуться к контексту статьи, то есть такая фишка, что релизную ветку можно "отрезать" ретроспективно - от того коммита, который сейчас на ПРОД, и в котором найден баг. Дальше делаем фикс TBDшным образом: баг-фикс через MR в trunk, а потом коммит с баг-фиксом черри-пикается во вновь отведённую релизную ветку, после чего на этот коммит ставится новый тэг (на релизной ветке) и катится на ПРОД.
Также не стоит забывать, что новые фичи (или важные доработки) всегда должны быть под фича-тогглом, следовательно, если есть критичный баг в новой фиче, то фичу можно просто отключить и спокойно пофиксить баг в транке. После выкатки баг-фикса снова включить фичу на ПРОД.
"Хороший тамада и конкурсы интересные" (с), т.е. здорово, что стало лучше и более по-взрослому, тем не менее, с моделью ветвления все четыре озвученных изначальных проблемы связаны приблизительно никак. Бескультурье и бардак вполне можно вернуть и при TBD, как и навести порядок и окультуриться в любой другой версии процесса.
Отказ от интеграционных веток, безусловно, ход конём, достойный восхищения, но как бы и намекающий, что в ваших обстоятельствах они может изначально были не особенно нужны. В каких-то других обстоятельствах собрать конфигурацию фича-тоглов или аналогов могло бы оказаться заметно сложнее, чем взять конкретную ветку. А могло бы оказаться более продуктивно активно пихать в общую промежуточную ветку и ее уже сквошить и катить в прод после тестирования. Беспредметно, в отрыве от всех обстоятельств вроде характера разрабатываемого продукта, его объёма, организации работы со смежными подразделениями, управления задачами и планирования, истории о лихом воплощении радикальных подходов не более интересны, чем объяснение полиморфизма на классах Cat и Dog.
Но, в любом случае, здорово, что куда-то подвигались и получилось. Может однажды и про техническую сторону тех самых пайплайнов, про организацию тестирования и систематизацию управления фича-тоглами расскажете. Будет интересно узнать.
Спасибо за конструктив!
с моделью ветвления все четыре озвученных изначальных проблемы
Бескультурье и бардак вполне можно вернуть и при TBD, как и навести порядок и окультуриться в любой другой версии процесса.
Согласен, что проблемы универсальны для любой модели ветвления и решения часто похожие. Особенно момент с культурой ревью. Некоторые же решения важны в бОльшей мере из-за специфики TBD.
Отказ от интеграционных веток, безусловно, ход конём, достойный восхищения, но как бы и намекающий, что в ваших обстоятельствах они может изначально были не особенно нужны.
Абсолютно так. Если мы можем без них жить - значит они не нужны.
Беспредметно, в отрыве от всех обстоятельств вроде характера разрабатываемого продукта, его объёма, организации работы со смежными подразделениями, управления задачами и планирования, истории о лихом воплощении радикальных подходов не более интересны, чем объяснение полиморфизма на классах Cat и Dog.
Услышал, что нужно больше "мяса", спасибо, буду улучшаться :)
Но, в любом случае, здорово, что куда-то подвигались и получилось. Может однажды и про техническую сторону тех самых пайплайнов, про организацию тестирования и систематизацию управления фича-тоглами расскажете. Будет интересно узнать.
Раз есть интерес - обязательно поделюсь опытом! Про тогглы, тесты и пайпы действительно есть что рассказать.
Один транк, чтобы править всеми: год экспериментов с TBD