1.1 версия вышла, для нее завели ветку

а... ну да

в целом так и есть

и там теги клепают на каждый релиз

а ты монорепозитории курил?

типа вместо кучи репосов один?

да

в случае symfony это выглядит логично

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

та ну не

все крупные чуваки так делают)

https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

надо покурить

не задумывался в принципе

ну короч я сча даунгрейднулся на фичабрэнчи (надеюсь временно)

а, да, единственный момент - код ревью

с trunk-based dev у тебя чуть осложняется этот вопрос... я у себя решал это попытками парное программирование двигать, ну и пост фактум ревьювя код

но как быть в распределенной команде пока хз

ну по факту у нас есть фича бранчи

мы в них кодим, каждый тикет

потом реквест на мерж

мы ревьювим

сливаем в общую ветку и дальше это тестят там

ну то есть у тебя может быть ситуация когда разработчик пилит фичу 3-4 дня

и только потом вливает

он всегда ребейзит

от общей ветки

и ниибет

это да, но как бы... это всеравно не то

если он эти 3-4 дня не делал ребейс, то сам себе буратино)

ну а бывает такое что за день вообще никто не замерджил ничего в мастер?

на выходных)

ну короч я более радикальный - либо ты делаешь PR и его ревьювят и валивают в тот же день (ну то есть каждый день - новый PR)

либо без веток вообще

ну короч я более радикальный - либо ты делаешь PR и его ревьювят и валивают в тот же день (ну то есть каждый день - новый PR)

да

у нас на ревью мало времени выделяется

иногда это пост-ревью

ну типа ты поставил в известность людей

иногда это пост-ревью

а ну тогда разумно

они посмотрели код

и все

ибо мне порой приходится сутки ждать пока доберутся до PR)

ну такое только если ты в чужой код льешь

ну, где у тебя контекст не твой

скажем я как бекенд полезу на фронт и чет там поменяю

то буду ждать апрува

ай не, я лучше буду если лезу заранее договариваться о сессии парного программирования

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

я пока не могу точно тебе сказать, но есть стойкое убеждение что фичабрэнчи это не эффективно

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

вот главный аргумент против, это чтобы фичи быстрее в прод уходили

хочется хуяк-хуяк и в прод

не ожидая всего релиз цикла

я хочу добиться того что деплоймент != релиз

и мутить CD полноценный

хотьбы раз...

но для этого надо сначала CI полноценный и покрытие кода тестами увеличить (end-to-end для начала намашнить)

хренюлю с фосюзером и переопределенным registrationcontroller никто не ловил недавно?

Ну я конечно тоже в чем-то приверженец анархизма, но про фичабренч ветке не согласен народ )))

ERROR: S client not available

вопрос

юзаете LoggerAwareTrait

или инжектите логгер в конструктор?

Если это продукт не ОСС то мастер это и есть продакшн который можно каждый раз после изменения деплоить

а изменения через PR с форка т.е. таже фичабренч в форке, которая прошла rebase с текущим мастером и естественно уже грин по всем проверкам

Если это продукт не ОСС то мастер это и есть продакшн который можно каждый раз после изменения деплоить

Зависит от флоу, например в gitlab flow для продакшна рекомендуется отдельная ветка production

а изменения через PR с форка т.е. таже фичабренч в форке, которая прошла rebase с текущим мастером и естественно уже грин по всем проверкам

а зачем?

Зависит от флоу, например в gitlab flow для продакшна рекомендуется отдельная ветка production

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

ну то есть.... я вот как человек который работал и так и эдак могу сказать что master и код фриз в release ветку работает эффективнее

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

почему нужно разделять работу?

а зачем?

чтоб изалировать WIP от рабочего и проверенного кода

чтоб изалировать WIP от рабочего и проверенного кода

то есть continious integration это не православно?

чтоб изалировать WIP от рабочего и проверенного кода

зачем изолировать?)

https://martinfowler.com/bliki/FeatureBranch.html

чтоб изалировать WIP от рабочего и проверенного кода

1. как долго у тебя в среднем живут ветки? 2. как часто появляются конфликты? 3. насколько у вас распространен рефакторинг (постоянное переименование классов, методов, реструктуризация) 4. насколько у вас с авто тестами?

то есть continious integration это не православно?

CI то да, но даже когда каждая ветка таска проходит CI иногда после слияния могут возникать лажи

CI то да, но даже когда каждая ветка таска проходит CI иногда после слияния могут возникать лажи

фичабрэнчи плохо совместимы с CI

(я сча не про дженкинсы а про подход)

github.com/akeneo/pim-community-dev

https://ci.akeneo.com/blue

https://ci.akeneo.com/blue

так, CI это процесс а не тулы

Я понимаю что подход и не важно что начинает рулить таски проверки

это когда у тебя все мерджат в mainline хотя бы раз в день и все такое

Я понимаю что подход и не важно что начинает рулить таски проверки

95 брэнчей....

ад

чтоб изалировать WIP от рабочего и проверенного кода

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

нет, там какие то тестовые poc ветки которые out of focus вообще, все движение через PR

WIP отделен от "проверенного" кода, но при этом нет необходимости в изоляции каждой фичи