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

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

И даже после аппрува QA обоих А и Б — нет никакого способа определить порядок их вливания в релиз. Начинается бардак и конфликты с ручным разрешением.


Да, ещё веселуха начинается, когда таск T завершен, залит в девелоп, а QA сейчас заняты и начинают тестировать неделю спустя. Вроде всё ок, аппрув дали — мол, вливайте в релиз, happy days! А чувак который пилил T на больничный ушел и вообще за неделю уже всё забыл после пьянки. При вливании обнаруживаются конфликты и никто толком не знает как их правильно разрешать... В итоге простой случай должен быть самым простым и частым — головная боль.

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

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

Z>·>Неясно на основании чего так считаете. Ведь этот данный код с данным sha1, судя по твоей схеме ни разу не тестировался.
Z>А ты узнай сколько времени тестировался код sha1 которого ушел в твой последний релиз. Может оказаться, что тоже не так много.
Больше, чем любой другой sha1. Просто по определению.

Чисто теоретически, результаты любых проверок для sha1 X нельзя проецировать на другой sha1 Y.