Но у нас дженкинс. А какие минусы подхода?

Но у нас дженкинс. А какие минусы подхода?

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

что до CI - нынче наладить CI примитивный - это максимум день работы если у тебя вообще небыло с ними опыта

а что у вас используется? смотрел TeamCity, вроде несложно

а что у вас используется? смотрел TeamCity, вроде несложно

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

https://trunkbaseddevelopment.com/

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

А хрен знает :) Постоянно все ПР билдит в дев веточные сабдомены, тесты все прогоняет. Понятно в каком домене какая фича.

А хрен знает :) Постоянно все ПР билдит в дев веточные сабдомены, тесты все прогоняет. Понятно в каком домене какая фича.

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

Спасибо. Буду читать.

А у вас что?

сейчас - фичабрэнчи) не могу пока уговорить отдельных лиц отказалсять и перейти на CI

до этого - trunk based development пол годика

фичабрэнчи - ветка под каждую задачу чтоли?

А у вас что?

в команде из 30-ти человек (10 бэкэндщиков, 20 тех кто пользовался, QA, фронтейндеры и прочие дизайнеры) trunk based показал себя ооочень хорошо

до этого - trunk based development пол годика

И, я так понимаю, было покруче?

И, я так понимаю, было покруче?

да. решало кучу проблем. Особенно в ситуациях когда проект подвергается довольно жесткому рефакторингу походу дела

у вас в мастере всегда рабочий код?

у вас в мастере всегда рабочий код?

не верный вопрос - верный вопрос - как узнать что в мастере рабочий код?)

ну скажем WIP который чет ломает, вы льете?

я про незаконченные фичи

небыло WIP котоыре что-то ломали... ну если и были - то там фиксилось в течении часа

да. решало кучу проблем. Особенно в ситуациях когда проект подвергается довольно жесткому рефакторингу походу дела

Я вижу одну проблему. Что релизы будут реже намного, так?

я в ноябре на общих сборах топил за фича бранчи, проходит 2 месяца и я заявляю что буду топить за противоположность

Я вижу одну проблему. Что релизы будут реже намного, так?

нет, наоборот

СТО сделал вот так

нет, наоборот

Так релиз бранч. В него ж вмердживать только когда весь мастер рабочий.

Так релиз бранч. В него ж вмердживать только когда весь мастер рабочий.

ну так не ломай мастер) и он всегда будет рабочим)

в идеале ты по сути разрабатываешь в проде)

CI/CD

Ну так фичи не готовые же могут в нем быть.

Ну так фичи не готовые же могут в нем быть.

могут, но они ничего не ломают)

фича флаги, абстрактные ветки

Есть такси которые не один день сидишь. А между ними баги фиксить.

Есть такси которые не один день сидишь. А между ними баги фиксить.

да хоть месяц - хоть раз в час пуш в мастер - просто не должно ничего ломаться. И да, это требует от тебя больше ответственности

ну то есть как, сломаться что-то может

А ещё не получится смотреть фича пулл реквесты

В джире

А ещё не получится смотреть фича пулл реквесты

а зачем тебе их смотреть если ты и так знаешь что все в мастере?

Те изменения которые относились к фиче

ну и опять же - линкуй задачи к коммитам - типа "PROJ-123: Add option field for bla bla"

Иногда надо инвестигейт делать как и когда сломалось.

Ну линкуются. Но смотреть 50 комитетов или один PR.

Иногда надо инвестигейт делать как и когда сломалось.

практика показывает что линки на задачи редко в этом помогают.

Ну линкуются. Но смотреть 50 комитетов или один PR.

а как тебе поможет просмотр PR который был влит месяц назад?

и что ты этим инвестигейтом хотел узнать?

кто виноват тебе скажет git blame

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

эм

заходишь в жиру

смотришь на TROLOLO-50

там список коммитов которые были влиты для нее

и выясняешь

после PR идет еще вагон фиксов как правило

которые не были заребейзены

Иногда надо инвестигейт делать как и когда сломалось.

1. ты ищешь не PR а место где сломано. Дальше ты смотришь git blame для этого места и смотришь коммит, он уже ведет на людей и задачу. 2. если тебе это надо делать часто - то на лицо более глубокие проблемы, которые возможно можно решить или как минимум минимизировать. И да, PR на 50 коммитов без код ревью (я так понимаю без) этому не сильно способствуют

а как тебе поможет просмотр PR который был влит месяц назад?

Ну что за вопрос? :)Скажи, тебе никогда не приходилось гулять по изменениями, чтобы понять, когда это сломалось.

1. ты ищешь не PR а место где сломано. Дальше ты смотришь git blame для этого места и смотришь коммит, он уже ведет на людей и задачу. 2. если тебе это надо делать часто - то на лицо более глубокие проблемы, которые возможно можно решить или как минимум минимизировать. И да, PR на 50 коммитов без код ревью (я так понимаю без) этому не сильно способствуют

Неверно понимаешь. У нас очень жесткое Код ревью

Ну что за вопрос? :)Скажи, тебе никогда не приходилось гулять по изменениями, чтобы понять, когда это сломалось.

ммм... нет. Я обычно ищу в мастере или своей ветке конкретное место в коде, а дальше - git blame если нужно

код ревью не панацея

и мало че решает

иногда блейм не дает ответа, так как чувак например делал это 80 лет назад и не помнит

для этого есть линк на задачу с описанием

Неверно понимаешь. У нас очень жесткое Код ревью

сколько времени у тебя в среднем займет ревью 1-ого коммита с изменением 10-ти файлов или 50-ти коммитов с изменениями 50-ти файлов? какой процент факапов ты не заметишь?

Иногда удаленные строки не показывают блейм )

иногда блейм не дает ответа, так как чувак например делал это 80 лет назад и не помнит

линк на таску в джиру

Иногда удаленные строки не показывают блейм )

если они удаленные - значит это не нужно)

ERROR: S client not available

Они удалены и как раз сломали что-то. :)

Мне кажется, ты пытаешься оправдать фичу :)

Я считаю, что нужны все возможности.

Я считаю, что нужны все возможности.

приведи реальный пример подобного инвестигейта

как часто (сколько раз в год) тебе это нужно?

А еще говоришь "Вот тут будет понеудобнее, тут по больше проблем, но в целом-то все это фигня. Главное фича классная" Ж)

А еще говоришь "Вот тут будет понеудобнее, тут по больше проблем, но в целом-то все это фигня. Главное фича классная" Ж)

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

приведи реальный пример подобного инвестигейта

ВДруг обнаружили, что пропала какая-то секция. Известно что были таски примерно связанные с этим. Ты находишь таску, смотришь ПР, видишь что сломано, чинишь.

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

Мертворожденная - это слишком громкое заявление :)

Phpstorm и git history позволяют даже по части файла чекать изменения и строки и т.д. никаких проблем с инвестигейтом

ВДруг обнаружили, что пропала какая-то секция. Известно что были таски примерно связанные с этим. Ты находишь таску, смотришь ПР, видишь что сломано, чинишь.

а зачем тебе стэпы между "сломано" и "чинишь"?

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

Люди были и будут распиздяями. С этим ты ничего не поделаешь.

а зачем тебе стэпы между "сломано" и "чинишь"?

Иногда проще вернуть как было, чем делать заново.

Люди были и будут распиздяями. С этим ты ничего не поделаешь.

почитай историю о том как форд (вроде они) с тайота объединились)

почитай историю о том как форд (вроде они) с тайота объединились)

Ну емана. Не надо так делать :)

Иногда проще вернуть как было, чем делать заново.

чем тебе тут помогут PR или джира? у тебя ж никто историю коммитов не отменяет. Более того - делать git rever маленьких коммитов проще

Ну ок. Я допускаю, что я просто думаю в категориях фичабренчей и не представляю транк-разработка как ведется.

а не не оно... не найду сейчас

Ну ок. Я допускаю, что я просто думаю в категориях фичабренчей и не представляю транк-разработка как ведется.

https://trunkbaseddevelopment.com/

Но я совершенно уверен, что фичабренчи - рабочий и вполне крепкий тип

Ну ок. Я допускаю, что я просто думаю в категориях фичабренчей и не представляю транк-разработка как ведется.

это еще что - ты про монорепозитории еще видимо не думал)

Да это уже кинул же ты :)

Но я совершенно уверен, что фичабренчи - рабочий и вполне крепкий тип

фаулер с тобой не согласен)

А фаулер если бы слушал других - не стал бы фаулером :)

Другие были бы фаулерами :)

> Indeed I see this as the decisive reason why Feature Branching is a bad idea. Once a team is afraid to refactor to keep their code healthy they are on downward spiral with no pretty end. (с) Мартин Фаулер, сказ о семантических конфликтах и рефакторинге

В данной статье я увидел только 1 против фича бренчей - конфликты. ВСЕ!

Вот серьезно. Я просто не имею опыта в транке.

В данной статье я увидел только 1 против фича бренчей - конфликты. ВСЕ!

I'll go so far as to discount textual conflicts for the purposes of this article. The problem I worry more about is a semantic conflict.

Вот серьезно. Я просто не имею опыта в транке.

суть не просто в том что бы опыт был, нужно в целом уметь анализировать имеющиеся решения)

Я просто представляю себе это так: Я решил сделать огромный рефактор. Я беру транк, делаю рефактор. КТо-то за это время назаливал изменений. У меня конфликты. Я их чиню. И пушу в транк. В чем разница? Кроме того, что я не могу быстро начать фиксить какой нить хотфикс?

а мне просто скучно и я накидываю что бы ты задумался - не являются ли те элементы процесса которые у тебя сложились не решением проблем, а ее прикрытием?