Здравствуйте, Ziaw, Вы писали:

Z>·>Ну так она сделана и протестирована в девелопе, где Б уже влит. При этом кто-то решил, что А уже готова и влил в релиз, а Б ещё требует небольших правок и в релиз ещё не влит.
Z>Код Б в ветку А не может попасть случайно, автор А знает, что задачи связаны и отразил это в Jira. Если задачи связаны зависимостью, то выкатка А будет ждать полной готовности Б. Либо (скорее всего) они пойдут одним фичабранчем.
Откуда он это знает-то? Потестил таску немного сам — работает, влил в девелоп, немного порезолвил конфликты, вроде работает. QA начали тестировать — работает. Замержил в релиз — а оно сломалось, т.к. отсутствуют некоторые изменения от Б, которые ещё тестируются и чуточку дорабатываются. Или, хуже того, порешил конфликты немножко по-другому.

Z>А как ты решаешь эту проблему в git-flow? А и Б в мастере, в Б оказались критические проблемы и ты выбрал один из предложенных тобой путей. Отключил ее фича флагом или сделал ей git revert. Как твои QA узнали, что функционал А тоже надо перетестировать?
Тут надо по тому списку из 4 пунктов действовать. Тяжесть последствий возрастает от первого пункта к последнему. Поэтому если в проекте часто что-то уходит дальше первого-второго пункта, то надо делать разбор полётов и что-то менять в консерватории. В общем случае, правки в релизе требуют перетестировать все фичи данного релиза, если нет полной уверенности, что правка действительно точечная и ничего другого сломать не может. Скажем, на втором пункте обычно правится какая-то мелочь, отследить влияние которой обычно тривиально и понять влияние на все фичи релиза. Третий пункт подразумевает, что QA должны протестировать что feature flag действительно сработал и старое поведение функционирует.

Z>·>Т.е. у вас ещё один полный раунд QA и для релизной ветки?
Z>Не всегда. Чаще всего в этом нет необходимости, мы считаем, что код релиза всегда готов к раскатке.
Неясно на основании чего так считаете. Ведь этот данный код с данным sha1, судя по твоей схеме ни разу не тестировался.