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

Z>·>Почему это непростой выбор? Поставьте ограничитель по времени, например: за минуту|час|день не пофиксили — реверт.
Z>Это подойдет в тех компаниях, где стейкхолдерам пофиг, когда выйдет фича и под ее выход ничего не планируется. В других компаниях за такие шутки можно пойти писать авто-тесты на UI, чтобы качество принятия решений пришло в соответствие с должностными обязанностями.
Это ты словоблудием занялся. Вопрос был "что делать, если релиз уже сегодня, а QA не хочет аппрувить одну фичу и отключить флагом её нельзя?". Предлагаешь объявлять компании банкротство или что? Твоя схема гитования ничем не поможет. И я уже писал, что это крайний случай, который требует разбора полётов.

Z>·>Костыль не дорогой на самом деле. Хотя требует некую культуру написания кода и тестов.
Z>·>Зато с лихвой окупается, т.к. бранчей/мержей требуется гораздо меньше, и они короткоживущие.
Z>·>Ещё и дополнительные возможности даёт типа A/B-тестирования.
Z>Фича флаг как общий подход безумно дорог в поддержке. Сложность между O(n^2) — O(n!). Сам по себе он конечно хорошо и зачастую незаменим, но как костыль для оперативного отключения нерабочей фичи в релизе — такое себе.
Это если фича-флаги не удалять. Такое будет при отсутствии культуры написания кода. Мол, выкатили фичу, в пабе обмыли и дальше пилим нетленку. А самый важный шаг — удаление флага — забывают. Количество фичафлагов в каждый момент времени должна быть 2-3 (недопиленные в течение спринта фичи). Меньше десятка уж точно. Но таки да, я видал ситуации, когда в проекте сотни флагов, созданных в течение десятка лет — это ужас.

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

·>Вот тут "стартуем ветку от release, вливаем в develop" — прежде чем влить в девелоп, надо с ним замержиться

Не надо так делать. Вливать мастер в релиз у нас нельзя, соответственно и в ветки его никто не вливает. Если делать как ты предлагаешь, весь смысл схемы теряется сразу.

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

Что за проект такой, что конфликты вливания дело настолько частое и нетривиальное? В таком проекте я крайне не рекомендую флоу с двойным вливанием.

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

Ну да, в гитфлоу мердж один. Ты как будто только что обнаружил, что в моей схеме два мерджа на одну таску, хотя об этом сразу было сказано.

·>Почти. Только "потом начинается тестирование всего" — это QA полной интерации всего и вся, а не конкретной таски.

Ты уклоняешься от описания процесса тестирования тасок и заявляешь о том, что это должны делать юниттесты. Описываемая схема именно для тестирования тасок.

·>Это ещё зависит от разных проектов. В одном из проектов QA команда тестирует релиз предыдущего спринта.
·>В другом проекте как таковой команды QA не было. В конце спринта делается таг и деплоится для теста как "релиз-кандидат" в staging. Потом каждый проверяет свои завершенные таски, кликая кнопки в нужном порядке, проверяя логи, что без ошибок, и т.п. — но тут не надо тестировать все возможные сценарии, которые уже покрыты юнит-тестами, а только общую интеграцию.
·>В ещё другом проекте на теге гонялись самые тяжелые авто-тесты.

Без QA на тасках смысл предлагаемой схемы теряется полностью. Мне казалось это очевидно, таски вливаются на стейдж именно для гранулярного тестирования.

·>Больше, чем любой другой sha1. Просто по определению.

Верится с трудом, но чем черт не шутит. Напиши примерный процесс со сроками типа:
— день 1. hash1 пошел в релиз, там 90 непротестированнных задач.
— день 2. QA протестировали функционал 25 из 90 задач, нашли 3 крита и 1 замечание. Они будут взяты в работу 4 программистами.
— день 3. у нас в релизе 4 новых мерджа, последний комит называется hash2
— ....

Вот тут мне хочется понять, как работает дальше твоя команда из десятков программистов и десятков QA. Через сколько времени появляется последний hash и по какому определению он тестируется дольше первого.

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

Главное не забудь про это, когда будешь описывать процесс выше.

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

·>Это ты словоблудием занялся. Вопрос был "что делать, если релиз уже сегодня, а QA не хочет аппрувить одну фичу и отключить флагом её нельзя?". Предлагаешь объявлять компании банкротство или что? Твоя схема гитования ничем не поможет. И я уже писал, что это крайний случай, который требует разбора полётов.

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

·>Это если фича-флаги не удалять. Такое будет при отсутствии культуры написания кода. Мол, выкатили фичу, в пабе обмыли и дальше пилим нетленку. А самый важный шаг — удаление флага — забывают. Количество фичафлагов в каждый момент времени должна быть 2-3 (недопиленные в течение спринта фичи). Меньше десятка уж точно. Но таки да, я видал ситуации, когда в проекте сотни флагов, созданных в течение десятка лет — это ужас.

У тебя команда из десятков программистов пилит 2-3 фичи в спринт? Как построен процесс выпиливания флагов?

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

Z>·>Вот тут "стартуем ветку от release, вливаем в develop" — прежде чем влить в девелоп, надо с ним замержиться
Z>Не надо так делать. Вливать мастер в релиз у нас нельзя, соответственно и в ветки его никто не вливает. Если делать как ты предлагаешь, весь смысл схемы теряется сразу.
Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.

Z>весь смысл схемы теряется сразу.
Было бы что терять.

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

Z>·>В моей схеме такого просто нет. Все мерж-конфликты разрешаются тут же. Я даже пайплайн настраивал — при сборке хотфикса в релизной ветке — вначале происходит автомерж в девелоп, потом только сборка проекта.
Z>Ну да, в гитфлоу мердж один. Ты как будто только что обнаружил, что в моей схеме два мерджа на одну таску, хотя об этом сразу было сказано.
Я обнаружил, и начал разговор с объяснений, что два мержа — это кака, мучительно, ненадёжно и никаких преимуществ.

Z>·>Почти. Только "потом начинается тестирование всего" — это QA полной интерации всего и вся, а не конкретной таски.
Z>Ты уклоняешься от описания процесса тестирования тасок и заявляешь о том, что это должны делать юниттесты. Описываемая схема именно для тестирования тасок.
Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.

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

Z>·>Больше, чем любой другой sha1. Просто по определению.
Z>Верится с трудом, но чем черт не шутит. Напиши примерный процесс со сроками типа:
Z>- день 1. hash1 пошел в релиз, там 90 непротестированнных задач.
Т.е., несколько сотен коммитов!

Z>- день 2. QA протестировали функционал 25 из 90 задач, нашли 3 крита и 1 замечание. Они будут взяты в работу 4 программистами.
Z>- день 3. у нас в релизе 4 новых мерджа, последний комит называется hash2
Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.

Z>- ....
Z>Вот тут мне хочется понять, как работает дальше твоя команда из десятков программистов и десятков QA. Через сколько времени появляется последний hash и по какому определению он тестируется дольше первого.
При таком кол-ве задач их можно тестировать в процессе спринта. Большинство критов будет пофикшено в девелопе в течение спринта. В конце спринта создаётся таг и прогоняются тесты ещё раз на теге.

Z>·>Чисто теоретически, результаты любых проверок для sha1 X нельзя проецировать на другой sha1 Y.
Z>Главное не забудь про это, когда будешь описывать процесс выше.
Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.

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

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

Т.е. отличие в общем настроении.
Твоя схема ориентирована на failure path, когда фичи к QA попадают полусырые, глючные, к релизу не готовые, девелоп-бранч кишит багами, контроля над кодом и функциональностью нет. Начинается футбол тестеров с девами с критами и замечаниями, допиливая и на ходу и пытаясь запрыгнуть в отправляющийся поезд релиза.

Моя схема ориентирована на success path — большинство фич пилятся в более менее готовом виде, мелочи закрываются точечными правками, девелоп бранч поддерживается в releaseable виде.

Z> ·>Это если фича-флаги не удалять. Такое будет при отсутствии культуры написания кода. Мол, выкатили фичу, в пабе обмыли и дальше пилим нетленку. А самый важный шаг — удаление флага — забывают. Количество фичафлагов в каждый момент времени должна быть 2-3 (недопиленные в течение спринта фичи). Меньше десятка уж точно. Но таки да, я видал ситуации, когда в проекте сотни флагов, созданных в течение десятка лет — это ужас.
Z> У тебя команда из десятков программистов пилит 2-3 фичи в спринт?
Большие фичи, которые меняют поведение, да. Далеко не каждая фича требует флага.

Z> Как построен процесс выпиливания флагов?
После того как фича выкачена в прод, всё работает, клиенты счастливы, флаг и все соответствующие if-ветки удаляются. Clean-up таск для следующего спринта обычно.

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

·>Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.

Не понимаю почему ты решил учить меня гиту. Для разрешения конфликтов вливание мастера не требуется, это факт.

·>Было бы что терять.

Ну да? Ты поэтому уже который пост придумываешь ситуации, в которых схема не сработает )))

·>Тривиально когда ты вливаешь сейчас. А через неделю уже может быть нетривиально.

На практике заметной разницы чаще всего нет.

·>Я обнаружил, и начал разговор с объяснений, что два мержа — это кака, мучительно, ненадёжно и никаких преимуществ.

Я не понимаю, зачем ты это объясняешь тому, кто уже несколько лет применяет это на практике? Откуда эта уверенность, что твои фантазии объективнее моего опыта? Откуда уверенность, что твой опыт регулярного болезненного разрешения конфликтов универсален?

·>Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.

Если таски QA тестируют в девелоп бранче, то проблема того, что следующая задача может повлиять на тестируемую никуда не девается. То, что ты называешь надежным, становится гораздо менее надежным моей схемы, когда ты сильно правишь или откатываешь таски из релиза.

·>Таски тестируются уже слитыми в один бранч во время аппрува релиза. Потому что релиз релизит либо всё, либо ничего (если происходит роллбак). Неясно в чём преимущество тестирования по отдельности, если в проде будет целое.

Ты же писал, что есть практика отката одной задачи? Куда она делась?

·>Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.

Серьезно? Вы смотрите в код каждого фикса и сообщаете QA, что именно стоит перетестировать в регрессе релиза?

·>При таком кол-ве задач их можно тестировать в процессе спринта. Большинство критов будет пофикшено в девелопе в течение спринта. В конце спринта создаётся таг и прогоняются тесты ещё раз на теге.

Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом?

·>Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.

Теперь расскажи, как получается, что именно последний тестируется больше всего?

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

Z>·>Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.
Z>Не понимаю почему ты решил учить меня гиту. Для разрешения конфликтов вливание мастера не требуется, это факт.
Ох, т.е. в таск-ветке девелопа нет? И при вливании в релиз все эти конфликты придётся снова разрешать второй раз? Мда уж.

Z>·>Было бы что терять.
Z>Ну да? Ты поэтому уже который пост придумываешь ситуации, в которых схема не сработает )))
Что значит не сработает? Эта схема привычна для старинных СВК типа cvs/svn и т.п., которые в мержи и в граф истории не умеют. Однако ими пользовались многие годы. Выбора не было. А сегодня не пользоваться современными средствами организации истории, просто неэффективно.

Z>·>Тривиально когда ты вливаешь сейчас. А через неделю уже может быть нетривиально.
Z>На практике заметной разницы чаще всего нет.
Через неделю я обычно забываю что я делал, и конфликты разрешать сложнее. Плюс сливаться приходится с бОльшим кол-вом изменений. Чем дольше растут ветки, тем больше они diverged. Это факт.

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

Z>Откуда уверенность, что твой опыт регулярного болезненного разрешения конфликтов универсален?
У меня болезненный опыт организации нормального процесса управлениями ветками.

Z>·>Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.
Z>Если таски QA тестируют в девелоп бранче, то проблема того, что следующая задача может повлиять на тестируемую никуда не девается. То, что ты называешь надежным, становится гораздо менее надежным моей схемы,
Судя по твоей схеме QA тоже тестируют в девелоп бранче. Внезапно.
В моей схеме потом делается фриз с помощью тега и делается QA sign-off. В таком случае никаких 3 критов в подавляющем случае тупо не будет.

Z>когда ты сильно правишь или откатываешь таски из релиза.
Это редкая редкость, это означает серьёзный факап. Может раз в год такое в худшем случае.
Ещё я забыл пунктик, что в такой ситуации можно просто отложить релиз, а особо необходимые таски замержить в виде хотфиков на прод.

Z>·>Таски тестируются уже слитыми в один бранч во время аппрува релиза. Потому что релиз релизит либо всё, либо ничего (если происходит роллбак). Неясно в чём преимущество тестирования по отдельности, если в проде будет целое.
Z>Ты же писал, что есть практика отката одной задачи? Куда она делась?
Это не повседневное практика, а разгребание последствий серьёзного факапа.

Z>·>Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.
Z>Серьезно? Вы смотрите в код каждого фикса и сообщаете QA, что именно стоит перетестировать в регрессе релиза?
Для коммита в три строчки — почему бы и нет?

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

Z>·>Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.
Z>Теперь расскажи, как получается, что именно последний тестируется больше всего?
Потому что на нём прогоняются все авто-тесты, которые гоняются на девелопе, плюс всякие медленные тесты, плюс на нём гоняются ручные тесты обнаруженных критических мест и т.п. И отличается от девелопа всего на < ~3 коммитов, которые видны как на ладони.
В твоей схеме на релизной ревизии тестов гоняется очевидно меньше, чем на дев-ветке. И разница в коде в принципе неизвестна, тупо выяснить разницу между тем что тестировали в девелопе и что сейчас в релизе — очень сложно, т.к. история у них серьёзно diverged.

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

·>Как она поможет релизнуть в условиях "где стейкхолдерам НЕ пофиг, когда выйдет фича"?

Ей достаточно быть лучше предлагаемой тобой схемы — ждите наш следующий регресс.

·>Вырезаем из текущего релиза и откладываем до следующего если ВНЕЗАПНО обнаружилось, что не готово. А в твоей схеме — пытаемся не мержить в релиз, пока не готово.

Почему пытаемся? Не мерджим, доводим до нужного качества в песочнице.

·>Т.е. отличие в общем настроении.
·>Твоя схема ориентирована на failure path, когда фичи к QA попадают полусырые, глючные, к релизу не готовые, девелоп-бранч кишит багами, контроля над кодом и функциональностью нет. Начинается футбол тестеров с девами с критами и замечаниями, допиливая и на ходу и пытаясь запрыгнуть в отправляющийся поезд релиза.

Нет, это не так.

·>Моя схема ориентирована на success path — большинство фич пилятся в более менее готовом виде, мелочи закрываются точечными правками, девелоп бранч поддерживается в releaseable виде.

Да, это так. Твоя схема нормально работает только в success path.

·>Большие фичи, которые меняют поведение, да. Далеко не каждая фича требует флага.

Вот именно.

·>После того как фича выкачена в прод, всё работает, клиенты счастливы, флаг и все соответствующие if-ветки удаляются. Clean-up таск для следующего спринта обычно.

Как-то не вяжется это с процессом команды в десятки разработчиков. Ты уж извини.

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

·>Ох, т.е. в таск-ветке девелопа нет? И при вливании в релиз все эти конфликты придётся снова разрешать второй раз? Мда уж.

Да, второй. Понимаю, что чукча не читатель, но ты пошел по кругу уже как писатель даже.

·>Что значит не сработает? Эта схема привычна для старинных СВК типа cvs/svn и т.п., которые в мержи и в граф истории не умеют. Однако ими пользовались многие годы. Выбора не было. А сегодня не пользоваться современными средствами организации истории, просто неэффективно.

Это не так. Эта схема вообще не подходит для VCS без нормальных веток. Прекращай уже высасывать из пальца.

·>Через неделю я обычно забываю что я делал, и конфликты разрешать сложнее. Плюс сливаться приходится с бОльшим кол-вом изменений. Чем дольше растут ветки, тем больше они diverged. Это факт.

Изменения одни и те же, конфликты практически идентичны. Нет, я понимаю, что задел твою какую-то больную тему с кривыми ресолвами, но в нашей практике эта проблема от разработчиков не звучит совсем.

·>У меня болезненный опыт организации нормального процесса управлениями ветками.

Почти готов тебе поверить, но то как ты меняешь показания на лету, больше походит на то, что ты этот опыт сейчас придумываешь на ходу.

·>Судя по твоей схеме QA тоже тестируют в девелоп бранче. Внезапно.

Вот именно. И я не вижу в этом проблемы.

·>В моей схеме потом делается фриз с помощью тега и делается QA sign-off. В таком случае никаких 3 критов в подавляющем случае тупо не будет.

Что за заклинание, которое заставляет десятки программистов не допустить ни одного крита за спринт?

·>Для коммита в три строчки — почему бы и нет?

Не испытываю доверия к практикам в которых программист диктует QA, что нужно тестировать, а что нет.

Z>>Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом?
·>Да.

Вот уж определился так определился.

·>Потому что на нём прогоняются все авто-тесты, которые гоняются на девелопе, плюс всякие медленные тесты, плюс на нём гоняются ручные тесты обнаруженных критических мест и т.п. И отличается от девелопа всего на < ~3 коммитов, которые видны как на ладони.

Это должно быть сильно меньше чем нормальный регресс по результатам которого найдены причины для трех комитов. Ну и автотесты всякие вы же гоняете не просто так, они что-то изредка ловят? Это надо чинить?

Ты правильно описал, твоя схема работает когда все хорошо и к моменту конца спринта ветка девелоп практически готова к релизу. Судя по описанию, ее тестирование у вас практически формальность.

·>В твоей схеме на релизной ревизии тестов гоняется очевидно меньше, чем на дев-ветке. И разница в коде в принципе неизвестна, тупо выяснить разницу между тем что тестировали в девелопе и что сейчас в релизе — очень сложно, т.к. история у них серьёзно diverged.

Не серьезно.

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

Z> ·>Ох, т.е. в таск-ветке девелопа нет? И при вливании в релиз все эти конфликты придётся снова разрешать второй раз? Мда уж.
Z> Да, второй. Понимаю, что чукча не читатель, но ты пошел по кругу уже как писатель даже.
Ну я не сразу понял, что оно настолько жутко... На 90 таск-ветках конфликты будут гарантированно. Т.е. твоя схема не только требует резет публичных веток, но и постоянный резолв конфликтов.

Z> ·>Что значит не сработает? Эта схема привычна для старинных СВК типа cvs/svn и т.п., которые в мержи и в граф истории не умеют. Однако ими пользовались многие годы. Выбора не было. А сегодня не пользоваться современными средствами организации истории, просто неэффективно.
Z> Это не так. Эта схема вообще не подходит для VCS без нормальных веток. Прекращай уже высасывать из пальца.
Почему не подходит? Нормальные мержи ничего интересного не в твоей схеме не дают. Коммиты можно просто копировать на другую базу как в каком-нибудь svn. Именно потому во всяких svn-ах твоя модель и была распространена. Сейчас просто мержат, получая красивый DAG.

Z> ·>Через неделю я обычно забываю что я делал, и конфликты разрешать сложнее. Плюс сливаться приходится с бОльшим кол-вом изменений. Чем дольше растут ветки, тем больше они diverged. Это факт.
Z> Изменения одни и те же, конфликты практически идентичны.
Нет, совсем нет. Т.к. у тебя таска мержится разное кол-во раз в девелоп и в релиз.
И никак не обеспечить, что порядок мержа 90 веток в девелоп будет ровно таким же как в релиз. А значит у тебя есть 90! вариантов как может выглядеть релизная ветка.

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

Z> ·>У меня болезненный опыт организации нормального процесса управлениями ветками.
Z> Почти готов тебе поверить, но то как ты меняешь показания на лету, больше походит на то, что ты этот опыт сейчас придумываешь на ходу.
Какие показания меняю? Я просто участвовал в очень разных проектах. Даже участвовал в ужасе переезда с clearcase (в котором использовалась твоя схема) на git.

Z> ·>Судя по твоей схеме QA тоже тестируют в девелоп бранче. Внезапно.
Z> Вот именно. И я не вижу в этом проблемы.
Именно. А раз там всё протестировано, то можно и зарелизить. Зачем что-то перемерживать-то?!

Z> ·>В моей схеме потом делается фриз с помощью тега и делается QA sign-off. В таком случае никаких 3 критов в подавляющем случае тупо не будет.
Z> Что за заклинание, которое заставляет десятки программистов не допустить ни одного крита за спринт?
Крита в релиз-кандидате же. А спринт идёт на девелопе, там криты — не больно совершенно.

Z> ·>Для коммита в три строчки — почему бы и нет?
Z> Не испытываю доверия к практикам в которых программист диктует QA, что нужно тестировать, а что нет.
Почему диктует-то? Просто сообщается известная инфа — в чём был root cause найденного крита и каким способом пофикшен. А решение о том что и как тестировать — принимает QA.

Z> Z>>Ты определись, вы тестируете задачи в процессе спринта или это делают юниттесты, а QA нужны для регресса перед релизом?
Z> ·>Да.
Z> Вот уж определился так определился.
Непонятно почему ты в меня ложными альтернативами кидаешь. Мы и тестируем, и юнит-тесты пишем, и QA проверяет, и регресс, и прогресс.

Z> ·>Потому что на нём прогоняются все авто-тесты, которые гоняются на девелопе, плюс всякие медленные тесты, плюс на нём гоняются ручные тесты обнаруженных критических мест и т.п. И отличается от девелопа всего на < ~3 коммитов, которые видны как на ладони.
Z> Это должно быть сильно меньше чем нормальный регресс по результатам которого найдены причины для трех комитов.
Ну да. Принять решение об упрощённом QA после трёх точечных коммитов — легко.

Z>Ну и автотесты всякие вы же гоняете не просто так, они что-то изредка ловят? Это надо чинить?
Не понял почему это вообще проблема. Автотесты гоняются на девелопе. Следовательно когда ставишь тег [1.0] — автотесты заведомо зелёные. Потенциальный багфикс для [1.1] — это один PR, который тоже вроде как зелёный должен быть для аппрува — сломаться там нечему, т.к. это просто fast-forward, тот же sha1 что и у PR.

Z> Ты правильно описал, твоя схема работает когда все хорошо и к моменту конца спринта ветка девелоп практически готова к релизу.
А почему должно быть не так? Иначе в чём смысл спринта?

Z>Судя по описанию, ее тестирование у вас практически формальность.
Не формальность, нужно тестирование интеграции всего со всем, того, что пойдёт в прод.

Z> ·>В твоей схеме на релизной ревизии тестов гоняется очевидно меньше, чем на дев-ветке. И разница в коде в принципе неизвестна, тупо выяснить разницу между тем что тестировали в девелопе и что сейчас в релизе — очень сложно, т.к. история у них серьёзно diverged.
Z> Не серьезно.
В твоём релизе как минимум 90 лишних мерж-коммитов каждой таски, каждый из которых с каким-то неизвестным conflict resolution. Я считаю, что 90 коммитов серьёзно отличается от трёх.

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

Z> ·>Моя схема ориентирована на success path — большинство фич пилятся в более менее готовом виде, мелочи закрываются точечными правками, девелоп бранч поддерживается в releaseable виде.
Z> Да, это так. Твоя схема нормально работает только в success path.
Это то к чему должно стремиться состояние проекта. Чтобы запиливаемые фичи работали. А не проходили через круги отладки и доработки напильником, и всё стоит колом блокируя релиз.

Z> ·>Большие фичи, которые меняют поведение, да. Далеко не каждая фича требует флага.
Z> Вот именно.
Ну и? Это означает, что залитая фича в "песочницу" ничего не ломает и релизить её можно без проблем. Неясно зачем перемерживать её ещё раз, рискуя налажать на неизбежных конфликтах.

Z> ·>После того как фича выкачена в прод, всё работает, клиенты счастливы, флаг и все соответствующие if-ветки удаляются. Clean-up таск для следующего спринта обычно.
Z> Как-то не вяжется это с процессом команды в десятки разработчиков. Ты уж извини.
Почему не вяжется-то? Это стандартная и давно известная техника.

В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.

Если проект очень активно разрабатывается — на период активной разработки делается две ветки — dev и main. В dev пишутся новые фичи, main типа стабилизированная ветка.

В целом долгоживущие параллельные ветки считаю неудобным в использовании, слишком много суеты по ребейзам.

Технически запрета на пуш в любую ветку нет, т.к. в гитхабе такого функционала для халявщиков нет. Но желательно нетривиальные изменения через пул-реквест проводить.

У нас программистов мало (<10), а модулей много (несколько десятков). Над одним проектом больше трёх программистов не работает, обычно один. Не знаю, насколько такой процесс скалируется выше, нам пока его хватает.

vsb>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
А кто такой процесс установил?
И когда ?
Где-то прописано?
Или новичку на словах объясняется ?

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

vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?

Я установил, примерно полтора года назад. Объясняется на словах. Часть правил прописаны в CI. До меня примерно так же было, но без конкретики, я чуток формализовал всё. Где-то расписывал текстом, но сейчас уже не найду.

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

vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?

Логика то в чем: у нас есть в один момент времени несколько версий кода находящихся на разных этапах конвейера разработки. Веток может быть много, под каждый такой этап. Есть только общие моменты:
prod/realise — здесь код который уже работает
main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
функциональные ветки — здесь код в стадии разработки
dev — здесь происходит слияние резных версий кода, разбор конфликтов.
А все остальное вы можете под себя добавить или убрать лишнее.

Q>Есть только общие моменты:
Q>prod/realise — здесь код который уже работает
Одна ветка ?
Q>main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
Q>функциональные ветки — здесь код в стадии разработки
Каждый заводит свою под решаемую задачу ?
Q>dev — здесь происходит слияние резных версий кода, разбор конфликтов.
Интересно: специальная ветка для слияния и разбора конфликтов
Сливаем сюда функциональные ветки, проверяем работу после устранения конфликтов и направляем в ветку prod/realise ?

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

Q>>Есть только общие моменты:
Q>>prod/realise — здесь код который уже работает
LVV>Одна ветка ?
Одна на выпускаемый продукт

Q>>main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
Q>>функциональные ветки — здесь код в стадии разработки
LVV>Каждый заводит свою под решаемую задачу ?
Да.
Q>>dev — здесь происходит слияние резных версий кода, разбор конфликтов.
LVV>Интересно: специальная ветка для слияния и разбора конфликтов
LVV>Сливаем сюда функциональные ветки, проверяем работу после устранения конфликтов и направляем в ветку prod/realise ?
Да, конфликты лучше разбирать на самой ранней стадии.

Q>>>dev — здесь происходит слияние резных версий кода, разбор конфликтов.
LVV>>Интересно: специальная ветка для слияния и разбора конфликтов
LVV>>Сливаем сюда функциональные ветки, проверяем работу после устранения конфликтов и направляем в ветку prod/realise ?
Q>Да, конфликты лучше разбирать на самой ранней стадии.
Супер!
Спасибо за интересное решение.

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

·>Это то к чему должно стремиться состояние проекта. Чтобы запиливаемые фичи работали. А не проходили через круги отладки и доработки напильником, и всё стоит колом блокируя релиз.

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

·>Ну и?

Далеко не каждая фича требует флага.

если не получается доработать быстро, то просто закомментировать/отключить сломаную таску (см. feature flags — как общий подход).

То общий, то не каждый.

·>Почему не вяжется-то? Это стандартная и давно известная техника.

На таких объемам протестировать релиз спринта, выкатить его в прод, убедиться, что все работает и клиенты счастливы и пойти удалять фича-тоглы на следующий спринт — нереально. Разве что десятки разрабов пилят настолько простые фичи, что их включение и выключение тривиальны.

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

·>Какие показания меняю? Я просто участвовал в очень разных проектах. Даже участвовал в ужасе переезда с clearcase (в котором использовалась твоя схема) на git.

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

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