Здравствуйте, ·, Вы писали:
·>Ох, т.е. в таск-ветке девелопа нет? И при вливании в релиз все эти конфликты придётся снова разрешать второй раз? Мда уж.
Да, второй. Понимаю, что чукча не читатель, но ты пошел по кругу уже как писатель даже.
·>Что значит не сработает? Эта схема привычна для старинных СВК типа cvs/svn и т.п., которые в мержи и в граф истории не умеют. Однако ими пользовались многие годы. Выбора не было. А сегодня не пользоваться современными средствами организации истории, просто неэффективно.
Это не так. Эта схема вообще не подходит для VCS без нормальных веток. Прекращай уже высасывать из пальца.
·>Через неделю я обычно забываю что я делал, и конфликты разрешать сложнее. Плюс сливаться приходится с бОльшим кол-вом изменений. Чем дольше растут ветки, тем больше они diverged. Это факт.
Изменения одни и те же, конфликты практически идентичны. Нет, я понимаю, что задел твою какую-то больную тему с кривыми ресолвами, но в нашей практике эта проблема от разработчиков не звучит совсем.
·>У меня болезненный опыт организации нормального процесса управлениями ветками.
Почти готов тебе поверить, но то как ты меняешь показания на лету, больше походит на то, что ты этот опыт сейчас придумываешь на ходу.
·>Судя по твоей схеме QA тоже тестируют в девелоп бранче. Внезапно.
Вот именно. И я не вижу в этом проблемы.
·>В моей схеме потом делается фриз с помощью тега и делается QA sign-off. В таком случае никаких 3 критов в подавляющем случае тупо не будет.
Что за заклинание, которое заставляет десятки программистов не допустить ни одного крита за спринт?
·>Для коммита в три строчки — почему бы и нет?
Не испытываю доверия к практикам в которых программист диктует QA, что нужно тестировать, а что нет.
Z>>Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом? ·>Да.
Вот уж определился так определился.
·>Потому что на нём прогоняются все авто-тесты, которые гоняются на девелопе, плюс всякие медленные тесты, плюс на нём гоняются ручные тесты обнаруженных критических мест и т.п. И отличается от девелопа всего на < ~3 коммитов, которые видны как на ладони.
Это должно быть сильно меньше чем нормальный регресс по результатам которого найдены причины для трех комитов. Ну и автотесты всякие вы же гоняете не просто так, они что-то изредка ловят? Это надо чинить?
Ты правильно описал, твоя схема работает когда все хорошо и к моменту конца спринта ветка девелоп практически готова к релизу. Судя по описанию, ее тестирование у вас практически формальность.
·>В твоей схеме на релизной ревизии тестов гоняется очевидно меньше, чем на дев-ветке. И разница в коде в принципе неизвестна, тупо выяснить разницу между тем что тестировали в девелопе и что сейчас в релизе — очень сложно, т.к. история у них серьёзно diverged.
