Trunk based development

[Сабина]

NY команда порешила что у нас теперь будет - https://trunkbaseddevelopment.com/
При это все скрипты и весь continuous development and delivery заточен на branch-> develop-> master. То что эти скрипты никто не будет переписывать зуб даю - это помимо того что лично я например вообще не представляю как скажем новый код быстро тестировать в stage если таких скриптов нету?

Если кто уже работает по такому принципу - как оно вам ? Как тестируете ? Если переходили на это дело на вашем веку - поделитесь опытом

[Prosche]

Посмотрел по диагонали. Похоже на схему, которую мы применяем. Тикет-бранч-ревью-коммит-qa на билд-тикет закрыт. Так как скрам, то тикет максимум на пару дней. Работает как часы.

[Palych]

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

[Сабина]

Тикет-бранч-ревью-коммит-qa на билд-тикет закрыт. Так как скрам, то тикет максимум на пару дней. Работает как часы.

А если new feature, которую нельзя релизать без data migration например ?
То есть нельзя мерджить регулярнo with bug fixes and other new code пока не готово все для миграции ? Но при этом надо все девелопить , тестировать etc ?
PS. Это вы про новое место ?

[Prosche]

Тикет-бранч-ревью-коммит-qa на билд-тикет закрыт. Так как скрам, то тикет максимум на пару дней. Работает как часы.

А если new feature, которую нельзя релизать без data migration например ?
То есть нельзя мерджить регулярнo with bug fixes and other new code пока не готово все для миграции ? Но при этом надо все девелопить , тестировать etc ?
PS. Это вы про новое место ?

У меня немного другое направление, поэтому подобных проблем нет. Но если порассуждать, то фича не может превышать одного спринта. Это максимум 2 недели. Ну в виде исключения создать такой "длинный" бранч. Если же такая миграция требуется постоянно, то уволить к черту архитектора базы.

П.С. про старое.

[Сабина]

У меня немного другое направление, поэтому подобных проблем нет. Но если порассуждать, то фича не может превышать одного спринта. Это максимум 2 недели. Ну в виде исключения создать такой "длинный" бранч. Если же такая миграция требуется постоянно, то уволить к черту архитектора базы.

П.С. про старое.

В общем я не вижу как она будет у нас работать . Остается надеяться что decision maker-ы видят

[Prosche]

В общем я не вижу как она будет у нас работать . Остается надеяться что decision maker-ы видят

Будет, не волнуйтесь. У нас раньше было как у вас, в итоге я потратил 8 месяцев на то, чтобы слить 7 многолетних бранчей в один. И теперь при попытке сотворить подобное выезжаю на место и объясняю почему так делать не надо и все работает. И это совершенно изумительно когда все on the same page и фраза "а у меня работает" не возможна к появлению в принципе.

[valchkou]

NY команда порешила что у нас теперь будет - https://trunkbaseddevelopment.com/

работал с таким.
Весь тим сидел вместе и релизы были четко по правилам. Пока все что запланировано не закодили, релиз не случается.
Да в этом было неудобство. Но зато все auto & integration тесты были натравлены на транк и автоматом находили проблемы.
И девелоперам приходилась мержить каждый день все что наменяли другие. Вобщем все работало как часы.

В текущей работе такое не получается, потому что во первых тимов много, а во вторых много народу работает уделенно.
Транк стал не эффективен. В транк/мастер сливаем только перед тем как отправить в продакшн.

[John Smith]

чето мне кажется такое подойдет только тем кто не координирует релизы ни с кем.

[Palych]

чето мне кажется такое подойдет только тем кто не координирует релизы ни с кем.

Именно так.