следующий этап - это автоматизация таких вещей как тесты, статический анализ кода

цель не в том что бы в мастер все пушить, а в том что бы разбить твой гиганский рефакторинг на очень маленькие куски и пушить их в мастер что бы все работали с очень схожим кодом. ЧТо бы если у кого-то что-то сломалось - это было следствием небольших изменений а не жирного PR

Бывают рефакторинги, которые не делятся на куски, потому что очень много надо рефакторить.

Бывают рефакторинги, которые не делятся на куски, потому что очень много надо рефакторить.

бывает лень и отсутствие воображения. Почитай про branch by abstraction.

Это как?

бывает лень и отсутствие воображения. Почитай про branch by abstraction.

Вот тут ты опять меня шлешь почитать. :)

Ты лучше скажи, что делать конкретно в этом случае

http://continuousdelivery.com/wp-content/uploads/2011/05/branch_by_abstraction.png

как-то так)

я года 2 назад тоже думал что некоторые задачи нельзя разделить и "это неделя и не трогай"... но...

Очень малообъясняющая картинка :)

все всегда можно разделить, и это даже не сложно

Очень малообъясняющая картинка :)

ну так почитай)

не хочешь - не читай)

Так ты мне картинку скинул :)

ну а ты подумай. Вот решил ты фреймворк заменить или ORM.

работы явно больше чем на пару дней

а теперь посмотри на картинку и прикинь план

Но смотри. Ты предлагаешь избавиться от надуманной семантической проблемы и реальной проблемы конфликтов. Но при этом добавить себе проблем в рефакторинге, какой-то абстракции и еще и контроль за собой усилить. Разрабы - ленивые люди. И для этого и стали разрабами, чтобы многие вещи автоматизировать.

никаких проблем в рефакторинге - наборот удобнее

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

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

Вот как ты это будешь делить?

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

Именно. Ведь я с тобой беседую не чтобы почитать :) А чтобы ты сразу сказал, абстрактные слои - это вот на конкретном примере так и так

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

Ты же вот даже ленишься рассказать об этом. Шлешь читать. И говоришь что не ленивые :)

Вот как ты это будешь делить?

По 1 зависимости менять или ты хочешь весь проект за 1 раз зарефакторить? Он у тебя на ревью на неделю или больше зависнет))

Ты же вот даже ленишься рассказать об этом. Шлешь читать. И говоришь что не ленивые :)

это не те вещи о которых надо узнавать в чатах. Ну то есть в чатах надо узнавать о существовании вещей. Потом идти читать, день два переваривать в голове... ну ты понял

Иногда деланье тольк одной абстракции может быть похлеще всего рефакторинга

По 1 зависимости менять или ты хочешь весь проект за 1 раз зарефакторить? Он у тебя на ревью на неделю или больше зависнет))

Офигенно. :) ТОлько нет :) Это работает у тебя в голове в идеальном мире.

А в дерьмовом проекте, который требуется рефакторить - это так не работает

Иногда деланье тольк одной абстракции может быть похлеще всего рефакторинга

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

Ну ну

А в дерьмовом проекте, который требуется рефакторить - это так не работает

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

только они дальше пошли - пофиксил - git push -> деплой сразу на прод

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

Знание ребят - не означает, что ты знаешь все, верно? Случаи могут быть кардинально разными.

если сломалось - алертика быстро скажет что говно - откатываем билд. А так как ты сломал изменениями котоыре залил 10 минут назад - то ты точно знаешь что сломал

Знание ребят - не означает, что ты знаешь все, верно? Случаи могут быть кардинально разными.

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

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

У нас такой.

Очень эффективен.

А в дерьмовом проекте, который требуется рефакторить - это так не работает

Конечно выкатывать переписанный проект за 1 раз работает, ну ну. Ты учти что проект может и будет меняться пока ты его весь рефакторить будешь.

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

А если частенько обновляться с мастера - так вообще конфликтов практически не бывает. У нас в среднем на 10 разрабов в месяц - 1 случай конфликта.

А если частенько обновляться с мастера - так вообще конфликтов практически не бывает. У нас в среднем на 10 разрабов в месяц - 1 случай конфликта.

а сколько мерджжите PR в месяц?

Конечно выкатывать переписанный проект за 1 раз работает, ну ну. Ты учти что проект может и будет меняться пока ты его весь рефакторить будешь.

КОнечно работает, если ты не забываешь перед тем как начать работать, делать git pull origin master

а без конфликтов но чтоб сломалось бывает?)

10? 50?

а сколько мерджжите PR в месяц?

Ща гляну. Гитхаб перед глазами

а без конфликтов но чтоб сломалось бывает?)

Тестами все покрыто. Не мерджится, пока не починиться и 2 человека ревью не заапрувит. И QA не заапрувит

Тестами все покрыто. Не мерджится, пока не починиться и 2 человека ревью не заапрувит. И QA не заапрувит

если все покрыто тестами - зачем нужны PR?

для код ревью? сколько у тебя в среднем живет один PR?

1-2 дня? неделю?

если в большинстве случаев - день - то более менее. В этом случае trunk-based тебе просто ускорит процесс за счет устранения лишних звеньев

Примерно 100 мерджей в месяц

10 человек?

Сейчас вообще 6

то есть примерно 17 PR с человека в месяц.

срок жизни PR?

если в большинстве случаев - день - то более менее. В этом случае trunk-based тебе просто ускорит процесс за счет устранения лишних звеньев

Не день. У нас СТО ревьюит каждый ПР. Очень детально.

из цифр - 1-2 дня, но в реальности?

Не день. У нас СТО ревьюит каждый ПР. Очень детально.

оооо.... э - эффективность и микромэнеджмент

Поэтому бывает иногда ПР может и неделю висеть. А вообюще зависит от сложности задания. QA тоже возвращает если баги какие-то

оооо.... э - эффективность и микромэнеджмент

Ну он как-то вот так вот хочет. Но при этом он на ревью отлавливает кучу багов

Поэтому бывает иногда ПР может и неделю висеть. А вообюще зависит от сложности задания. QA тоже возвращает если баги какие-то

то есть у вас нормально когда у одного человека висит по 5-6 его PR не влитых в мастер?

то есть у вас нормально когда у одного человека висит по 5-6 его PR не влитых в мастер?

Да.

Отправил на ревью, переключил ветку и работаешь над другой таской.

я что-то сомневаюсь про 1 конфликт в месяц. Может быть 1 у каждого хотя бы?)

Нет.

ERROR: S client not available

Если регулярно тянуть с мастера, то конфликты оооочень маленькие.

Типа в 1 файле 1 строчка.

так пр неделю висят а мастер меняется

потом в этих повисших появляются конфликты

Проблемы бывают, только когда работают над одним и тем же.

Вот я не вру. Очень мало конфликтов. Либо они настолько простые, что не стоят того, чтобы Транкфлоу заводить

Если регулярно тянуть с мастера, то конфликты оооочень маленькие.

маленькие? ну то есть их уже больше чем 1 в месяц?)

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

Нет.

Хорошо. Если их в 2 раза больше

2 раза в месяц

Это что-то меняет?

Это что-то меняет?

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

а ты просто не обращаешь внимания из-за волшебного auto-merge

Хорошо. Давай предположим, что у меня 1 конфликт в день.

или у вас настолько грамотно планирование работы происходлит что конфликты не возникают

И чем же плох волшебный автомердж?

или никто ничего толком и не меняет - только добавляет новое (абсолютный open/close)

Если тестами покрыто.

Юнит тестами, ненавистными интеграционными и фича тестами

Если тестами покрыто.

как часто после вливания мастера в твою ветку они фэйлятся?

Почле вливания в мастер за 2 года работы - 0!

На стадии ПР - очень часто.

Но при мердже в мастер - 0

После мерджа, точнее

Но при мердже в мастер - 0

нет, при мердже МАСТЕРА в твою ветку

ну то есть в процессе работы над PR

А в мою ветнку?

вот у тебя были зеленые тесты в твоей ветке, ты влил мастер и они стали красными

Типа, у меня все работает. Я ничего не трогаю, тяну мастер и прогоняю тесты, так?

да

и еще пара вопросов - каков средний объем изменений (количество файлов или количество инсертов/делитов на PR) - что пилите? CRM? вэбсайт?