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

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

Z>·>Ну и?
Z>

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

Z>

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

Z>То общий, то не каждый.
Общий в том смысле как методика реализации отключаемой фичи. Это вовсе не означает, что все фичи обязаны быть отключаемыми.

Z>·>Почему не вяжется-то? Это стандартная и давно известная техника.
Z>На таких объемам протестировать релиз спринта, выкатить его в прод, убедиться, что все работает и клиенты счастливы и пойти удалять фича-тоглы на следующий спринт — нереально. Разве что десятки разрабов пилят настолько простые фичи, что их включение и выключение тривиальны.
Ты не понял. Пилят рискованные фичи так, чтобы их включение и выключение было тривиальным.
Удаление фича-флага это два рефакторинга: подстановка константы (т.е. featureFlag==true) и удаление unreachable code (т.е. if(true){newStuff()}else{oldStuff()} — ветка else просто удаляется).

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

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

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

·>Релизный тег ставится на коммит девелопа, в конце спринта.

Те задачи, которые тестировали в спринте, тестируете заново в этом комите?

·>Общий в том смысле как методика реализации отключаемой фичи.

Может быть по другому что ли?

·>Ты не понял. Пилят рискованные фичи так, чтобы их включение и выключение было тривиальным.
·>Удаление фича-флага это два рефакторинга: подстановка константы (т.е. featureFlag==true) и удаление unreachable code (т.е. if(true){newStuff()}else{oldStuff()} — ветка else просто удаляется).

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

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

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

Z>·>Общий в том смысле как методика реализации отключаемой фичи.
Z>Может быть по другому что ли?
Не понял вопрос.

Z>·>Ты не понял. Пилят рискованные фичи так, чтобы их включение и выключение было тривиальным.
Z>·>Удаление фича-флага это два рефакторинга: подстановка константы (т.е. featureFlag==true) и удаление unreachable code (т.е. if(true){newStuff()}else{oldStuff()} — ветка else просто удаляется).
Z>Это ты не понял. Так можно выключать только простейшие фичи и только в определенных стеках. Например фича — новая система уведомлений пользователя так просто не переключится.
Сама нет, конечно. Просто напиши код так, чтобы новую систему уведомлений пользователя можно было переключить просто.

Z>В динамических языках ты не найдешь подстановки констант или удаления анричибл кода.
В javascript/groovy я нашел. Или это ненастоящие динамические языки?

Вот в качестве ликбеза статья: https://martinfowler.com/articles/feature-toggles.html , там как раз js используется в примерах.

Z>>В динамических языках ты не найдешь подстановки констант или удаления анричибл кода.
·>В javascript/groovy я нашел. Или это ненастоящие динамические языки?

Не везде можно поставить флаги, особенно так, чтобы их в runtime можно было переключитить: например версия зависимостей поменялась.
Кроме того, это определеный риск (вдруг ты где то забудешь измененный код в флаг обернуть).
А у QA может просто не быть свободного времени на тестирование корректной работы "переключателя".

Прокомментирую также некоторые другие утверждения:

·>Не понял. Ветка девелопа одна же на все доски. Как и когда организуется резет — вообще неясно в твоей схеме. И что происходит с тасками начатыми до резета — их придётся мучительно ребейзить.

Нет, при ресете develop не придется делать делать rebase для task-веток, т.к. они ответвляются от master (release), а не от develop. И merge из develop в task-ветки не производится.

	напомню схему:
	v QA/fix v done develop --------------------------------------- / / TASK-01-login-users ---------------------------- / \ release --------------------------------------- ^ develop/review ^ ready to deploy

·>Вообще, любой воркфлоу в которой происходит резет публичных веток — ущербен и опасен.

В описанной схеме ветка develop это просто ветка, где сливаются фичи. И как отметил Ziaw, ему она нужна, т.к. нет "железных" ресурсов для того, чтобы развернуть тестовое окружение под каждую фиче-(task)-ветку в отдельности.
Т.е. это не что иное, как Throw-away integration branch, описанный в документации по git.

По поводу failure/success path:

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

	приведу пример
	У нас на работе тестируют именно фиче-(task)-ветки и только после тестирования и получения отмашки от руководства вливают в upstream ветку, на которой будет ставится релизный тег. Делается так, потому что: 1) фича может быть совсем экспериментальная без определенной даты релиза вообще. При этом QA тоже участвуют в эксперименте 2) фича может передвинута на следующий релиз т.к.: 2.1) разрабочики/тестировщики не успевают доделать/протестировать или просто перекинуты на более приоритетную задачу 2.3) стейкхолдеры что-то там перетасовали 3) фичи могут изначально разрабатываться под разные релизы — например ближайший и следующий за ним (разница по времени полгода-год) Сдвиг фичи на другой релиз может произойти в любой момент: до, в ходе или после (успешного) тестирования. И как я заметил в начале сообщения, feature toggles далеко не всегда применимы.

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

в этой теме уже были комментарии, что если фичи существенно пересекаются по коду, то делается доп. ветка task1+task2 в которой они и разрешаются.
Т.е. при merge в develop (а потом в release) каких-то существенных конфликтов быть не должно.

По поводу diverged history:
·>Чисто теоретически, результаты любых проверок для sha1 X нельзя проецировать на другой sha1 Y.
.>И никак не обеспечить, что порядок мержа 90 веток в девелоп будет ровно таким же как в релиз. А значит у тебя есть 90! вариантов как может выглядеть релизная ветка.

Если речь идет о commit id, то он вычисляется на основе многих составляющих в т.ч. commit id родителей.
Я к тому, результаты проверок имеет смысл проецировать на основе идентичности кода, а не commit id.
Сравнение кода позволит выявить потенциальные ситуации, когда конфликты при merge в master(release) разрешены иным образом, чем при merge в develop.

Кроме того для повторного разрешения конфликтов можно использовать git-rerere
Вот пример использования git-rerere в flow, очень похожем на обсуждаемый: A pragmatic guide to the Branch Per Feature git branching strategy
(разница только в том, что там две throw-away интеграционные ветки: одна чисто для разрешения конфликтов, вторая — для QA)

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

Важно строить политику гитования отталкиваясь от:
— типа ПО: SaaS, десктоп, мобилки, железячный софт
— релизных политик: раз в день, раз в полгода, катится на прод, отдается заказчикам самая свежая версия на данный момент
— типа софта: аутсорс, проектная работа, продуктовая разработка
— количества людей в команде

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

Например, dev/main ветки хорошо, когда у тебя SaaS и тебе нужно катить в прод один или несколько раз в неделю и/или у тебя есть стейджинг-окружение наряду с продом. Но такая политика не нужна, когда ты делаешь коробочный продукт — там достаточно main.

Еще пример: если на проекте два человека, то для них может быть оптимальным вообще main + 2 персональных ветки.

Ну и так далее. Я на личном опыте видел, как в десктоп продукт тащили main+dev только потому, что привыкли так на саасном проекте или прочитали где-то. Хотя там это было во вред. И обратные примеры тоже видел.

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

m> Z>>В динамических языках ты не найдешь подстановки констант или удаления анричибл кода.
m> ·>В javascript/groovy я нашел. Или это ненастоящие динамические языки?
m> Не везде можно поставить флаги, особенно так, чтобы их в runtime можно было переключитить: например версия зависимостей поменялась.
Флаги можно делать и compile-time, и build-time.

m> Кроме того, это определеный риск (вдруг ты где то забудешь измененный код в флаг обернуть).
Ну тестировать нужно, конечно.

m> А у QA может просто не быть свободного времени на тестирование корректной работы "переключателя".
Это какая-то вялая отмаза. Если код недостаточно тестируется, то он может быть недостаточно качественным. И тут неважно переключатель тут тестируется или что-то ещё.

m> ·>Не понял. Ветка девелопа одна же на все доски. Как и когда организуется резет — вообще неясно в твоей схеме. И что происходит с тасками начатыми до резета — их придётся мучительно ребейзить.
m> Нет, при ресете develop не придется делать делать rebase для task-веток, т.к. они ответвляются от master (release), а не от develop. И merge из develop в task-ветки не производится.
Так ещё терпимо, да. Но всё равно создаёт хаос, т.к. "так а я же вчера уже это выкатил! Тестируйте! Ой, не работает, а мы резет же сделали...". Вместо плавного потока у тебя бурление какое-то туда-сюда.
Т.е. следить за всем этим делом становится сложнее. Ещё как-то синхронизовать резеты нужно глобально между всеми разработчиками и QA.

m> ·>Вообще, любой воркфлоу в которой происходит резет публичных веток — ущербен и опасен.
m> В описанной схеме ветка develop это просто ветка, где сливаются фичи. И как отметил Ziaw, ему она нужна, т.к. нет "железных" ресурсов для того, чтобы развернуть тестовое окружение под каждую фиче-(task)-ветку в отдельности.
m> Т.е. это не что иное, как Throw-away integration branch, описанный в документации по git.
Ну если почитать этот параграф повнимательнее, и ещё следующий "Branch management for a release", то можно заметить, Throw-away branch больше для демок и экспериментов, чем часть release-пайплайна. Т.е. основная разработка и тестирование всё равно ведётся отдельно в и в релиз уходит таг, т.е. то за что я топлю. По твоей же схеме QA происходит только в Throw-away branch, потом всё перезаливается второй раз (удваивая усилия на мержы-конфликты) в другой бранч и тут же объявляется релизом, без QA. То что результат мержа не тестируется — меня удивляет больше всего. А если перетестируете всё, то это удваивает нагрузку и на QA, а потом совершенно неожиданно: "у QA может просто не быть свободного времени".

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

m> И как я заметил в начале сообщения, feature toggles далеко не всегда применимы.
Ок, вполне поверю, что такие случаи можно придумать. Но это должно быть редким исключением, чем правилом и основным способом организации пайплайна, и требовать специального подхода и тестирования.

m> .> Ну я не сразу понял, что оно настолько жутко... На 90 таск-ветках конфликты будут гарантированно. Т.е. твоя схема не только требует резет публичных веток, но и постоянный резолв конфликтов
m> в этой теме уже были комментарии, что если фичи существенно пересекаются по коду, то делается доп. ветка task1+task2 в которой они и разрешаются.
Это вообще неясно как организовать надёжно.
Как и в каких единицах измерить "существенность пересечения"?
Как детектить неявные пересечения? Даже изменения в разных файлах могут давать логические пересечения — конфликта vcs нет, а код не работает — это самые подлые проблемы.
Что если потом внезапно окажется, что task1 — очень срочно надо, протестировано, требуется релизить, а task2 — "не успевают доделать/протестировать" и вообще "стейкхолдеры что-то там перетасовали"?

m> Т.е. при merge в develop (а потом в release) каких-то существенных конфликтов быть не должно.
Проблема в том, что мерж веток A,B,C может работать очень по-другому, с разными конфликтами чем B,C,A — и это нетривиально понимать как всё работает.

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

m> Если речь идет о commit id, то он вычисляется на основе многих составляющих в т.ч. commit id родителей.
m> Я к тому, результаты проверок имеет смысл проецировать на основе идентичности кода, а не commit id.
m> Сравнение кода позволит выявить потенциальные ситуации, когда конфликты при merge в master(release) разрешены иным образом, чем при merge в develop.
Каким образом ты будешь сравнивать код? С учётом того, что как ты выразился выше, не всё может быть замержено. Дифы могут быть практически любого размера и сложности. Т.е. весь этот процесс нетривиальный, запутанный, легко пропустить ошибки. В отличие от того, чтобы тупо сравнить два commitId — это работает железно.

m> Кроме того для повторного разрешения конфликтов можно использовать git-rerere
m> Вот пример использования git-rerere в flow, очень похожем на обсуждаемый: A pragmatic guide to the Branch Per Feature git branching strategy
m> (разница только в том, что там две throw-away интеграционные ветки: одна чисто для разрешения конфликтов, вторая — для QA)
Это 2013 год, для "project first switched from Subversion to Git" — наверное сгодится.
Чуваки наученные к траходному с vcs пока сидели на svn — считают нормой писать магические ruby-скрипты и централизованно постоянно что-то ребейзить.

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

M>Если речь идет о commit id, то он вычисляется на основе многих составляющих в т.ч. commit id родителей.
M>Я к тому, результаты проверок имеет смысл проецировать на основе идентичности кода, а не commit id.
Подумалось тут... Иметь идентичный tree id, но сознательно отказываться от идентичности commit id — это уже шизофрения какая-то.

·>Флаги можно делать и compile-time, и build-time.

Это усложняет поддержку кода. При разработке новых фичей придется учитывать присутствие в коде этой отложенной (на неопределенный срок) фичи.

m>> А у QA может просто не быть свободного времени на тестирование корректной работы "переключателя".
·>Это какая-то вялая отмаза. Если код недостаточно тестируется, то он может быть недостаточно качественным. И тут неважно переключатель тут тестируется или что-то ещё.

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

m>> Т.е. это не что иное, как Throw-away integration branch, описанный в документации по git.
·>Ну если почитать этот параграф повнимательнее, и ещё следующий "Branch management for a release", то можно заметить, Throw-away branch больше для демок и экспериментов, чем часть release-пайплайна. Т.е. основная разработка и тестирование всё равно ведётся отдельно в и в релиз уходит таг, т.е. то за что я топлю. По твоей же схеме QA происходит только в Throw-away branch, потом всё перезаливается второй раз (удваивая усилия на мержы-конфликты) в другой бранч и тут же объявляется релизом, без QA. То что результат мержа не тестируется — меня удивляет больше всего. А если перетестируете всё, то это удваивает нагрузку и на QA, а потом совершенно неожиданно: "у QA может просто не быть свободного времени".

QA пишут интеграционные автотесты. Они прогоняются на каждом build`е, в т.ч. после merge. Вручную результат merge не проверяется.

·>Это вообще неясно как организовать надёжно.
·>Как и в каких единицах измерить "существенность пересечения"?
·>Как детектить неявные пересечения? Даже изменения в разных файлах могут давать логические пересечения — конфликта vcs нет, а код не работает — это самые подлые проблемы.
·>Что если потом внезапно окажется, что task1 — очень срочно надо, протестировано, требуется релизить, а task2 — "не успевают доделать/протестировать" и вообще "стейкхолдеры что-то там перетасовали"?

Такие решения принимаются заблаговременно (я привел ниже ориентиры по нашим срокам релизов для наглядности).
Были конечно ситуации, когда фичу с пересечениями передвинули на след. релиз, и были применены feature toggles. Но так получилось из-за "экономии" на ветках (source control был не на Git).

m>> Т.е. при merge в develop (а потом в release) каких-то существенных конфликтов быть не должно.
·>Проблема в том, что мерж веток A,B,C может работать очень по-другому, с разными конфликтами чем B,C,A — и это нетривиально понимать как всё работает.
m>> .>И никак не обеспечить, что порядок мержа 90 веток в девелоп будет ровно таким же как в релиз. А значит у тебя есть 90! вариантов как может выглядеть релизная ветка.

Конкретизирую: у нас обычно на релизный цикл (4-8 месяцев) порядка 10-15 бизнес-фичей. В конфликтах по коду (файлам) участвуют максимум 2-3 фичи (на конфликт), логическое пересечения где-то в таком же объеме.
Есть ещё bugfix и support, он обычно попадает к QA на тестирование уже в release ветке (практически как в твоем workflow).
А также не-бизнес-фичи (всякий тех. долг, аудит кода и т.п.) без первоначальной привязки к релизу.
Кстати bugfix (на который ещё нет автотестов) вполне может проверяться вручную для каждой релизной ветки отдельно. И это в общем-то неизбежно.

m>> Сравнение кода позволит выявить потенциальные ситуации, когда конфликты при merge в master(release) разрешены иным образом, чем при merge в develop.
·>Каким образом ты будешь сравнивать код? С учётом того, что как ты выразился выше, не всё может быть замержено. Дифы могут быть практически любого размера и сложности. Т.е. весь этот процесс нетривиальный, запутанный, легко пропустить ошибки. В отличие от того, чтобы тупо сравнить два commitId — это работает железно.

через git diff по подкаталогам.
Конкретизирую: у нас monorepo (плюс пара субмодулей под бинарники и т.д) продукта, который поставляется конечному пользователю в одном инсталляторе, но внутри содержить много независимых по пользовательскому функционалу решений, которые пересекаются только по некоторым общим библиотекам. Поэтому сравнивать весь репо бессмысленно.
Если какая-то фича была "выкинута", то разрешить конфликты вручную заново. Проблему потенциальных "логических" пересечений закрыть через автотесты.

m>> Вот пример использования git-rerere в flow, очень похожем на обсуждаемый: [url=https://drupalsun.com/katherinebailey/2013/03/05/pragmatic-guide-branch-feature-git-branching-strategy]A pragmatic guide to the Branch Per
·>Это 2013 год, для "project first switched from Subversion to Git" — наверное сгодится.

Ну они пишут, что попробовали сначала git-flow, но в итоге отказались о него

M>>Ну раз Вам всё просто и понятно, то можете прокомментировать ситуацию описанную здесь.
M>>Так ли опасна ситуация, как пишет автор статьи, и почему для решения не достаточно "культуры", а нужен pre-receive hook.

N>Зависит от конкретной команды. У нас можно в течение 5-10 минут собраться и устно всё порешать.

Сомневаюсь насчет возможности порешать за 5-10 минут. Разве что всем всё равно.

N>А ещё более менее известно, кто и за какой кусок кода отвечает.

Но если репо один, то история общая как и проблемы с ней.

На реддите эта статья обсуждалась несколько лет назад и, как обычно бывает в случае git, мнения разделились.
Ссылка (запасная ссылка на web.archive).

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

LVV>А кто нибудь за этим следит?
Используется Azure DevOps и там прописаны права кто куда пушить может, ну и code-review прямо на web странице делается, что удобно.
Я особо в эту кухню не вникал.