TBD, стоит ли заморачиваться

WMix

герр M:)ller
Партнер клуба
у кого есть опыт TBD
мне коллега все уши прожужал, мол ветвление гоуно, фэйсбук и гугл юзят TBD, хочу релизю, коммитю не думаю и как решение отключения ненужного кода в продакшине feature toggle.
мол есть код, нужно часть заменить, находишь место, вставляешь toggle point, конфиг на это место и пишем, коммитим в транк. мол допишем переключим... а так не мешает.
чтот я сомневаюсь, что думаете вы, какие камни, о чем стоит подумать?
 

AmdY

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

Adelf

Administrator
Команда форума
мы у себя запланировали перейти на фича флаги. но на фича-бранчи забивать... как-то не хочется :) возвращаться в каменный век?
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
@WMix, есть методология, называется - пишите код б.лин
 

WMix

герр M:)ller
Партнер клуба
@c0dex, это как раз об этом... нет ветвлений, слияний, все в одну кучу слили нехай разбираются что включать что выключать, наше дело простое, найти место и туда if зафигачить, попросят, уберем.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Я о том, что писать надо как тебе удобно, но чтобы при этом не ломать/не мешать коллегам.

У нас онли фича бранчи + dev ветка, где делаются микро-фиксы. А фича бранчи долгие - по пол года могут девелопиться =\
 

fixxxer

К.О.
Партнер клуба
git flow хорош простотой и понятностью, не вижу смысла от него отказываться.

Если хочется сделать фиче-флаги - ну, я не вижу, как это противоречит git flow
 

WMix

герр M:)ller
Партнер клуба
не вижу смысла от него отказываться
зачем отказываться, все можно, но основной процесс проще, те практически как в детстве, да нужно изолировать код, да синтаксис страдать не должен (fatal error), ну те для начала минимальное, а плюсы на виду. можно хоть ежечасно коммитить, не думаем о ветвлении, нет дистанции между проектом и основной веткой, большая часть if'ов переключаемые фичи, простой ci и деплой,. ну те вижу одни плюсы и понять не могу нафига все так сложно?
 

Вурдалак

Продвинутый новичок
После гугления на тему TBD у меня сложилось впечатление, что основная суть этого подхода — заставлять разработчика быстрее релизить фичу. Тут должна срабатывать психология: коммитить нужно чаще, если ты не коммитишь, то ты не работаешь. Плюс больше думать над тем, что коммитишь.

Я бы сказал, что с точки зрения разработчиков удобнее git flow, потому что лично я могу 10 раз переписать свой новый код, могу сразу выпиливать ненужные файлы, если новая фича в них не нуждается и так далее. Как ещё одно следствие, при TBD неизбежно будет «грязная» история.

Есть, конечно, плюс в плане конфликтов, их по идее должно быть меньше. С git flow вроде бы можно просто релизиться почаще, но с практической точки зрения это сложнее, чем с TBD, потому что если захочешь что-то изменить, то либо ждать релиза, либо отзывать свою заявку из релиза и опять-таки ждать до следующего раза. Но для меня проблема конфликтов не стоит настолько остро, даже с учётом того, что разработчиков у нас не так мало.

Спроси коллегу в чём удобство лично для него как для разработчика. Часто ли у него возникают конфликты или это просто модно?
 

fixxxer

К.О.
Партнер клуба
@WMix, если фичеветка дольше одного дня, я хотя бы раз в день делаю rebase на develop-ветку. Ну и перед финальным пушем для PR, разумеется. На разгребание конфликтов уходит максимум 5 минут в 99% случаев.

А с ифами все не так просто. А если я что-то добавляю в билдилку, как туда прокинуть? А если я вообще класс, метод или файл переименовал?

Мне кажется, такой процесс приводит к фактическому запрету на рефакторинг.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
фэйсбук и гугл юзят TBD
Ага, и гит-репозитории вида "все в одной куче" размером по 100 гигов.
То, что они крупны и коммерчески успешны, это не повод на них слепо равняться во всём. У них могут быть свои причины, которые актуальны только для них, причем с большой вероятностью ответом будет "так сложилось".
 

WMix

герр M:)ller
Партнер клуба
@Вурдалак, в общем все правда, коммитить чаще, история грязная, приходиться чуток больше думать об изоляции.
коллега, он деплоит и хоть с конфликтами легко справляется, любви к ним не испытывает, обещает, в чем сомневаюсь (cherry-picking), релизить чаще. основной его довод заключается в том, что если два разработчика работают в отдельных ветках, они не имеют шанса проверить как два проекта после слияния будут работать вместе. а когда все слили времени на исправления практически не остается. при tbd же подобные ошибки будут заметны сразу, тк "дистанции" между ветками не существует, юниты и деплой на тестовый сервер автоматические, ну и не на самом последнем месте упростить для новичков основной процесс разработки.
Ага, и гит-репозитории вида "все в одной куче" размером по 100 гигов.
 

WMix

герр M:)ller
Партнер клуба

Вурдалак

Продвинутый новичок
основной его довод заключается в том, что если два разработчика работают в отдельных ветках, они не имеют шанса проверить как два проекта после слияния будут работать вместе.
Честно говоря, я не помню такой проблемы у себя. В крайних случаях я договаривался с разработчиком, что релизиться будем одновременно. Но тут не совсем «проверить как два проекта (?) после слияния будут работать вместе», а тупо чтобы конфликтов избежать.
 

WMix

герр M:)ller
Партнер клуба
Feature toggle отношения к branching model не имеет
там в середине доклада он проговорился (5я минута)...
В крайних случаях я договаривался
я о другом, конфликтовать могут 2 проекта если выбран одинаковый идентификатор и это может произойти на любом уровне, имя метода, css-class, html-element-id итд
 

Вурдалак

Продвинутый новичок
я о другом, конфликтовать могут 2 проекта если выбран одинаковый идентификатор и это может произойти на любом уровне, имя метода, css-class, html-element-id итд
Я такого не помню. Правда вёрсткой не занимаюсь.

Что касается ссылок на крупных игроков, то это всё-таки argumentum ad verecundiam. Есть вероятность, что при очень большом количестве параллельных правок это просто меньшее из зол и для проектов поменьше это бессмысленно.
 

AmdY

Пью пиво
Команда форума
там в середине доклада он проговорился (5я минута)...

я о другом, конфликтовать могут 2 проекта если выбран одинаковый идентификатор и это может произойти на любом уровне, имя метода, css-class, html-element-id итд
так такое может произойти и при работе в одной ветке. а могут и вовсе удалить css-класс на который ты ссылаешься и ты об этом не узнаешь и будешь потом каким-нибудь git bisect искать, когда твоя фича отвалилась.
на проектах с одним транком обычная ситуация когда пол дня вся команда курит, а потом овертаймит, пока бранч чинит один человек, которого все уже ненавидят.
 
Сверху