Vladloiq
Это когда фича закончена, бранч влит в дев и тот в стенде
А разработчик занят другой фичей.
Да, я в одной замечательной компании приходил в ситуацию, которую запустили. Там было 40 зависших бранчей, которые подвесили за год. И это не говоря, о том, что завесили за 8 лет истории.
Не поверите - решилось всего 1 переговорами с оунером. Просто показав стоимость поддержки такого зависания.
Дропнули все в итоге. Внимательно согласовали механизм приоритезации и не меняли больше, перестав перекидываться на фичу до окончания разработки приоритезированной, оцененной, взятой в работу. Компания работает и ей пользуется в РФ ну процентов 5 населения, наверное.
абсолютно согласен
пример размещён публично. Поэтому комментируется публично.
читают пример разные люди - им полезно понимать, что это под продажу пример, а не решение обозначенных проблем, как мне кажется
У разрабов так получается, когда не налажены процессы в разработке. Когда процессы налажены - такого нахлёста нет.
Баг не надо показывать тестировщику конечно же, когда вы делаете хот фикс. Если это хот фикс, то он скорее всего пойдёт прямо на стейджинг. Если это фикс, то он должен оказаться на интеграционном стенде, а не показанным тестировщику. В большом кол-ве проектов правильным является локальный стенд на машине разработчика, если проект маленький - как раз для ведения разработки фичи. А в больших проектах есть разные способы обеспечить фича неймспейсы. В целом, не хочется устраивать лекцию из комментария моего. Безусловно инфраструктура с тестированием должна быть. Вопрос в том, что к проблемам надо правильные решения подбирать. Иначе затыкая одну проблему не её решением, а затычкой - проблема остаётся и фактически продолжает отъедать время. Та же поддержка зависших бранчей продолжит поедать время разработчиков, как минимум на восстановление сборки и интеграции спустя время (зависимости внешние и внутренние соответственно).
Простите заранее за некоторый негатив
Сама задачи нескольких окружений под фичи - очень классная, в контексте тех самых очередей.
Но 90% того что приведено в обосновании - это диагноз системной проблемы в разработке и управлении беклогом в продукте, которая несколькими окружениями не лечится никак. Системные проблемы лечат системным образом, в том числе: несколько фич в параллель у разработчика, незаконченные фичи, конфликтующие фичи - что делать в интеграции и пр.
спасибо, Кэп. Ваш комментарий очень важен для нас...
решение очевидно в повышении качества решений разработчика и налаживании процессов разработки на уровне модулей, которые делаются без тестировщика
И да, завершённая задача в модуле, прошедшая ревью, зарытая модульными тестами и пр составляющими нормальный dod - да, такая задача вполне закончена и может не ждать никакого тестировщика. Дальше при баге на уровне интеграции вы делаете в dev-у фикс. Это позволяет вам не вешать бранчи, не возвращаться к бранчам и пр. И на чамом деле позволяет снизить проблемы в интеграции - ведь у вас ещё несколько разработчиков рядом пишут свои задачки и им надо их тоже вливать в dev и тоже гнать на интеграцию. В целом мероприятия для снижения проблем на интеграции в виде бекмерджей раз в пару дней максимум - это не простая, но обязательная культура.