Re[11]: Политика гитования
От: Ziaw Россия  
Дата: 10.07.23 14:57
Оценка:
Здравствуйте, ·, Вы писали:

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


Откуда в его ветке появился код Б с которым он это немного потестил?

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


Не могу понять как у тебя все устроено. Команда из сильно больше (?) десятка программистов клепает фичи целый спринт и только потом начинается тестирование всего, что они накодили. В процессе тестирования в релиз докидываются хотфиксы найденных багов и из него выпиливаются или отключаются те фичи, правка которых не делается парой строк и может затянуться. Я ничего не перепутал?

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


А ты узнай сколько времени тестировался код sha1 которого ушел в твой последний релиз. Может оказаться, что тоже не так много.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.