Здравствуйте, LaptevVV, Вы писали:
LVV>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>Или пушат и мержат все кому не лень без всякой политики?
Только мастер, релизы из мастера, фича ветки мерджатся в мастер в течение 1-2 дней после создания. Плюсы: разработчики не тратят время на мерджи. Минусы: нужно правильно выбирать задачи на реализацию и почти никогда не косячить.
Здравствуйте, ·, Вы писали:
·>Плохо. Будут мучения с резолвингом конфликтов. ·>Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени.
У нас флоу неплохо работает в проекте побольше, чем ты описал. Таски с зависимостями друг от друга объединяются в фичабранч, который и в тестирование и в релиз идёт одной веткой, а в ревью уходят пиары именно в него.
·>Это приведёт к конфликтам и они могут разрешаться немного по-разному. В итоге в release окажется код, который немного отличается от того, что было в develop.
Такая проблема редка, но есть. Она не является мучением. Ресолвит конфликты тот же человек. Отличия в ресолве редки и незначимы. Время от времени develop ресетится от release и отличия исчезают.
>Т.е. тестироваться будет не тот код, который релизится. Опасно.
У вас в тестирование задачи идет именно тот код, который будет релизиться? Поделишься опытом цикла релиза?
Здравствуйте, Ziaw, Вы писали:
Z> ·>Плохо. Будут мучения с резолвингом конфликтов. Z> ·>Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени. Z> У нас флоу неплохо работает в проекте побольше, чем ты описал. Таски с зависимостями друг от друга объединяются в фичабранч, который и в тестирование и в релиз идёт одной веткой, а в ревью уходят пиары именно в него.
Просто в общем случае невозможно определить — зависимы ли таски или нет.
Результат мержа в разные ветки — разный, а значит и работать может по-разному.
Z> ·>Это приведёт к конфликтам и они могут разрешаться немного по-разному. В итоге в release окажется код, который немного отличается от того, что было в develop. Z> Такая проблема редка, но есть. Она не является мучением. Ресолвит конфликты тот же человек. Отличия в ресолве редки и незначимы. Время от времени develop ресетится от release и отличия исчезают.
Ужас, ещё и reset. А если что-то в develop было замержено — то потеряется?
Z> >Т.е. тестироваться будет не тот код, который релизится. Опасно. Z> У вас в тестирование задачи идет именно тот код, который будет релизиться? Поделишься опытом цикла релиза?
Да вроде стандартно — в конце спринта делается тег на текущем девелопе и отдаётся в QA. Найденные QA баги правятся на релизной ветке и тут же мержатся назад в девелоп. Когда тестеры счастливы — тег идёт в прод. Если есть хотфиксы в проде, тоже идут в эту же релизную ветку и тут же портятся в девелоп.
[v1.0] — это тег.
Q — это багфиксы обнаруженные во время QA
H — это хотфиксы
* — коммиты.
Заметь, если багов/фиксов в релизном теге не обнаружено (идеальный случай), то релизная ветка собственно не нужна — релизы обозначаются тегами и ничего не ответвляется. Т.е. если вдруг обнаружился баг, то релизную ветку можно создать от тега и туда закоммитить хотфикс.
Здравствуйте, ·, Вы писали:
·>Просто в общем случае невозможно определить — зависимы ли таски или нет.
На практике я таких случаев не встречал. Если тебя блочит код другой таски ты знаешь про это и вы можете объеденить их в один фича-бранч, который лучше тестировать совметстно.
·>Результат мержа в разные ветки — разный, а значит и работать может по-разному.
Может и что? Чем это качественно отличается от того, что он может работать в релизе по разному и в твоем флоу?
·>Ужас, ещё и reset. А если что-то в develop было замержено — то потеряется?
Туда замерджены только таски в тестировании, они все на доске. Процедура ресета редкая, это не проблема для нас.
·>Да вроде стандартно — в конце спринта делается тег на текущем девелопе и отдаётся в QA. Найденные QA баги правятся на релизной ветке и тут же мержатся назад в девелоп. Когда тестеры счастливы — тег идёт в прод. Если есть хотфиксы в проде, тоже идут в эту же релизную ветку и тут же портятся в девелоп.
Ты про релиз и регресс сейчас написал, при чем тут он? Я в своем флоу вообще не касался этого процесса, хотя он становится заметно легче (не описание процесса, а само прохождение). Я спросил, как ты тестируешь таски именно в том коде который пойдет в релиз?
У тебя есть флоу тестирования конкретной таски, а не регресс релиза? Кстати, у тебя мобилка/десктоп/веб?
Здравствуйте, ·, Вы писали:
·>Угу, много чего интересного может случиться (где например хотфиксы в его схеме?), и появятся новые магические ветки. И в итоге у них получится кривоватое подмножество flow.
Проблема ветвления зависимых задач стоит в любом флоу и универсального решения на данный момент не имеет. Как ты в своем флоу ее решаешь?
Есть два вида зависимости:
— задача А требует функционал Б, как зависимость.
— А и Б работают по отдельности, но вместе не работает хотя бы кто-то из них.
Первая решается ровно такими же бранчами на несколько задач, как и в git-flow. Вторая решается только регрессом, зачастую это вопрос везения.
Здравствуйте, ·, Вы писали:
·>Да вроде стандартно — в конце спринта делается тег на текущем девелопе и отдаётся в QA. Найденные QA баги правятся на релизной ветке и тут же мержатся назад в девелоп. Когда тестеры счастливы — тег идёт в прод. Если есть хотфиксы в проде, тоже идут в эту же релизную ветку и тут же портятся в девелоп. ·>
Отдельно вынесу тред про недостаток гит-флоу, который и мотивировал нас использовать более сложный механизм. Речь идет о тестовом стенде, стейджинге. Либо QA может в два клика развернуть стенд с таской у себя локально или в облаке либо тестировать приходится на едином стейджинге для всех, в этот стейдж раскатывается ветка мастер через CI/CD.
В первом случае, каждая таска тестируется в своей песочнице и никакого понимания про то, как они будут работать вместе быть не может, они просто еще не смерджены. Впрочем это не наш случай, разводить по инстансу немаленького веб приложения на каждую таску мы не можем.
Во втором, для релиза нужен какой-то период, за который пройдут тестирование все таски, которые сейчас в мастере (и отдельный стенд на который раскатывается этот релиз). То есть любая таска возвращенная в доработку, требует остановить релиз и дождаться ее завершения, релиз откладывается на неопределенный срок. Это работает только когда вы можете себе такое позволить.
Здравствуйте, Ziaw, Вы писали:
Z>·>Просто в общем случае невозможно определить — зависимы ли таски или нет. Z>На практике я таких случаев не встречал. Если тебя блочит код другой таски ты знаешь про это и вы можете объеденить их в один фича-бранч, который лучше тестировать совметстно.
Странно. Часто бывает, когда меняются разные аспекты. Например, один таск — добавить поле ко всем сообщениям, а другой таск — добавить новый тип сообщения. В итоге может оказаться так, что в зависимости в каком порядке делать, в новом сообщении как может оказаться новое поле, так и может не оказаться.
Z>·>Результат мержа в разные ветки — разный, а значит и работать может по-разному. Z>Может и что? Чем это качественно отличается от того, что он может работать в релизе по разному и в твоем флоу?
В том, что в твоей схеме тестируется ревизия X, в прод уходит Y и X≠Y. В моей схеме X=Y.
Z>·>Ужас, ещё и reset. А если что-то в develop было замержено — то потеряется? Z>Туда замерджены только таски в тестировании, они все на доске. Процедура ресета редкая, это не проблема для нас.
Одна доска, это от силы десяток человек. Бывает гораздо больше.
Z>·>Да вроде стандартно — в конце спринта делается тег на текущем девелопе и отдаётся в QA. Найденные QA баги правятся на релизной ветке и тут же мержатся назад в девелоп. Когда тестеры счастливы — тег идёт в прод. Если есть хотфиксы в проде, тоже идут в эту же релизную ветку и тут же портятся в девелоп. Z>Ты про релиз и регресс сейчас написал, при чем тут он? Я в своем флоу вообще не касался этого процесса, хотя он становится заметно легче (не описание процесса, а само прохождение). Я спросил, как ты тестируешь таски именно в том коде который пойдет в релиз?
Тестируется результат мержа тасков в девелоп, одна из ревизий которого помечается релизным тегом.
Z>У тебя есть флоу тестирования конкретной таски, а не регресс релиза?
QA тестирует не код конкретной таски. Зачем? Для этого есть юнит-тесты, которые сами всё делают. Тестируется замерженный в девелоп код, который потенциально уйдёт в прод.
Z>Кстати, у тебя мобилка/десктоп/веб?
Эээ.. Ну ближе к вебу, скорее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ziaw, Вы писали:
Z>Отдельно вынесу тред про недостаток гит-флоу, который и мотивировал нас использовать более сложный механизм. Речь идет о тестовом стенде, стейджинге. Либо QA может в два клика развернуть стенд с таской у себя локально или в облаке либо тестировать приходится на едином стейджинге для всех, в этот стейдж раскатывается ветка мастер через CI/CD. Z>В первом случае, каждая таска тестируется в своей песочнице и никакого понимания про то, как они будут работать вместе быть не может, они просто еще не смерджены. Впрочем это не наш случай, разводить по инстансу немаленького веб приложения на каждую таску мы не можем.
Да и не надо. Для этого придумали юнит-тесты — как раз для изолированного тестирования. И сабж тут ортогонален.
Z>Во втором, для релиза нужен какой-то период, за который пройдут тестирование все таски, которые сейчас в мастере (и отдельный стенд на который раскатывается этот релиз). То есть любая таска возвращенная в доработку, требует остановить релиз и дождаться ее завершения, релиз откладывается на неопределенный срок. Это работает только когда вы можете себе такое позволить.
Это не все альтернативы. В релизной ветке можно: не анонсировать фичу, или анонсировать как "preview/PoC" с known issues, если клиенты позволяют.
если поломка мелкая, то просто быстро доработать.
если не получается доработать быстро, то просто закомментировать/отключить сломаную таску (см. feature flags — как общий подход).
Ну совсем всё сломано, даже feature flag глючит — git revert (но тут закономерный вопрос и обсуждение на ретроспективе — а как оно вообще попало в develop в таком виде??!).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ziaw, Вы писали:
Z>·>Угу, много чего интересного может случиться (где например хотфиксы в его схеме?), и появятся новые магические ветки. И в итоге у них получится кривоватое подмножество flow. Z>Проблема ветвления зависимых задач стоит в любом флоу и универсального решения на данный момент не имеет. Как ты в своем флоу ее решаешь?
Опытным путём. Проверяется смерженный код. А не делаются предположения о том какой будет результат мержа на основании тестирования частей.
Z>Есть два вида зависимости: Z>- задача А требует функционал Б, как зависимость.
В твоей схеме А может уехать в прод до Б и ничего даже не пискнет.
Z>- А и Б работают по отдельности, но вместе не работает хотя бы кто-то из них.
Поэтому и надо тестировать их вместе перед отправкой в прод.
Z>Первая решается ровно такими же бранчами на несколько задач, как и в git-flow. Вторая решается только регрессом, зачастую это вопрос везения.
Ещё проблема в том, что нет никакого простого критерия, чтобы достоверно предварительно определить, что задача А хоть как-то зависит от задачи Б или нет. Теорема Райса и всё такое.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Странно. Часто бывает, когда меняются разные аспекты. Например, один таск — добавить поле ко всем сообщениям, а другой таск — добавить новый тип сообщения. В итоге может оказаться так, что в зависимости в каком порядке делать, в новом сообщении как может оказаться новое поле, так и может не оказаться.
Такое должны тесты выявлять. Описаная проблема случается независимо от флоу.
·>В том, что в твоей схеме тестируется ревизия X, в прод уходит Y и X≠Y. В моей схеме X=Y.
В твоей схеме вообще не показано, как тестируется таска. Только регресс при релизе. Этот процесс можно делать в обоих флоу, он за рамками того, о чем я писал.
·>Одна доска, это от силы десяток человек. Бывает гораздо больше.
Это актуально для каждой доски.
·>Тестируется результат мержа тасков в девелоп, одна из ревизий которого помечается релизным тегом. ·>QA тестирует не код конкретной таски. Зачем? Для этого есть юнит-тесты, которые сами всё делают. Тестируется замерженный в девелоп код, который потенциально уйдёт в прод.
У вас тестируется весь результат спринта команды гораздо больше 10 человек? То есть к тестированию приступаете, только когда все таски влиты?
Здравствуйте, ·, Вы писали:
·>Да и не надо. Для этого придумали юнит-тесты — как раз для изолированного тестирования. И сабж тут ортогонален.
Если у вас задачи катятся в мастер до регресса без тестирования, тогда конечно git-flow сильно лучше. Хотя бы тем, что заметно проще.
·>Это не все альтернативы. В релизной ветке можно: ·> ·> не анонсировать фичу, или анонсировать как "preview/PoC" с known issues, если клиенты позволяют. ·> если поломка мелкая, то просто быстро доработать. ·> если не получается доработать быстро, то просто закомментировать/отключить сломаную таску (см. feature flags — как общий подход). ·> Ну совсем всё сломано, даже feature flag глючит — git revert (но тут закономерный вопрос и обсуждение на ретроспективе — а как оно вообще попало в develop в таком виде??!). ·>
Другими словами, во время регресса приходится принимать решение, катить неготовую фичу, быстр допилить либо срочно ревертить. Вот от этого непростого выбора мы и отказались собственно.
feature flag как общий подход выглядит здесь как дорогой костыль, прикрывающий полуготовые фичи.
Здравствуйте, ·, Вы писали:
·>Опытным путём. Проверяется смерженный код. А не делаются предположения о том какой будет результат мержа на основании тестирования частей.
Это красивые слова. В итоге проверяется код, от которого начался процесс тестирования и потом фрагментарно допроверятся результат фиксов, откатов, доливок, отключений фича флагов и всего подобного.
Z>>- задача А требует функционал Б, как зависимость. ·>В твоей схеме А может уехать в прод до Б и ничего даже не пискнет.
Она не сможет, она именно требует этот функционал. То, что она сделана и работает означает, что требуемый функционал в ней появился.
Z>>- А и Б работают по отдельности, но вместе не работает хотя бы кто-то из них. ·>Поэтому и надо тестировать их вместе перед отправкой в прод.
Ты снова говоришь про общий регресс перед релизом, который вообще за скобками описываемой схемы ветвления.
Здравствуйте, Ziaw, Вы писали:
Z>·>Странно. Часто бывает, когда меняются разные аспекты. Например, один таск — добавить поле ко всем сообщениям, а другой таск — добавить новый тип сообщения. В итоге может оказаться так, что в зависимости в каком порядке делать, в новом сообщении как может оказаться новое поле, так и может не оказаться. Z>Такое должны тесты выявлять. Описаная проблема случается независимо от флоу.
Которые? Юнит-тесты тестируют юниты. А QA это для результата полной интеграции. По твоей схеме тестируется результат интеграции в девелопе, а в прод идёт результат другой интеграции в совершенно другой ветке, без какого либо QA, судя по твоей картинке.
Z>·>В том, что в твоей схеме тестируется ревизия X, в прод уходит Y и X≠Y. В моей схеме X=Y. Z>В твоей схеме вообще не показано, как тестируется таска. Только регресс при релизе. Этот процесс можно делать в обоих флоу, он за рамками того, о чем я писал.
Она тестируется в составе ветки девелопа. Принципиальная разница в том, какая ревизия (commit sha1) проверяется QA и какая уходит в прод. В моей схеме, как правило, ревизия ровно та же, эквивалент с точностью до бита. В твоей — что попало.
Z>·>Одна доска, это от силы десяток человек. Бывает гораздо больше. Z>Это актуально для каждой доски.
Не понял. Ветка девелопа одна же на все доски. Как и когда организуется резет — вообще неясно в твоей схеме. И что происходит с тасками начатыми до резета — их придётся мучительно ребейзить.
Вообще, любой воркфлоу в которой происходит резет публичных веток — ущербен и опасен.
Z>·>Тестируется результат мержа тасков в девелоп, одна из ревизий которого помечается релизным тегом. Z>·>QA тестирует не код конкретной таски. Зачем? Для этого есть юнит-тесты, которые сами всё делают. Тестируется замерженный в девелоп код, который потенциально уйдёт в прод. Z>У вас тестируется весь результат спринта команды гораздо больше 10 человек? То есть к тестированию приступаете, только когда все таски влиты?
Тестирование идёт постоянно, в течение спринта. Накладывание релизного тега — это "freeze" изменений в конце спринта с целью прогона всех самых возможных QA проверок для sign-off релиза.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ziaw, Вы писали:
Z>·>Опытным путём. Проверяется смерженный код. А не делаются предположения о том какой будет результат мержа на основании тестирования частей. Z>Это красивые слова. В итоге проверяется код, от которого начался процесс тестирования и потом фрагментарно допроверятся результат фиксов, откатов, доливок, отключений фича флагов и всего подобного.
Frozen код с точечными правками проверять проще (при этом другие девы не блокируются и продолжают гадить в девелоп как обычно).
Z>>>- задача А требует функционал Б, как зависимость. Z>·>В твоей схеме А может уехать в прод до Б и ничего даже не пискнет. Z>Она не сможет, она именно требует этот функционал. То, что она сделана и работает означает, что требуемый функционал в ней появился.
Ну так она сделана и протестирована в девелопе, где Б уже влит. При этом кто-то решил, что А уже готова и влил в релиз, а Б ещё требует небольших правок и в релиз ещё не влит.
Z>>>- А и Б работают по отдельности, но вместе не работает хотя бы кто-то из них. Z>·>Поэтому и надо тестировать их вместе перед отправкой в прод. Z>Ты снова говоришь про общий регресс перед релизом, который вообще за скобками описываемой схемы ветвления.
Т.е. у вас ещё один полный раунд QA и для релизной ветки?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну так она сделана и протестирована в девелопе, где Б уже влит. При этом кто-то решил, что А уже готова и влил в релиз, а Б ещё требует небольших правок и в релиз ещё не влит.
Код Б в ветку А не может попасть случайно, автор А знает, что задачи связаны и отразил это в Jira. Если задачи связаны зависимостью, то выкатка А будет ждать полной готовности Б. Либо (скорее всего) они пойдут одним фичабранчем.
А как ты решаешь эту проблему в git-flow? А и Б в мастере, в Б оказались критические проблемы и ты выбрал один из предложенных тобой путей. Отключил ее фича флагом или сделал ей git revert. Как твои QA узнали, что функционал А тоже надо перетестировать?
·>Т.е. у вас ещё один полный раунд QA и для релизной ветки?
Не всегда. Чаще всего в этом нет необходимости, мы считаем, что код релиза всегда готов к раскатке.
Здравствуйте, Ziaw, Вы писали:
Z>·>Ну так она сделана и протестирована в девелопе, где Б уже влит. При этом кто-то решил, что А уже готова и влил в релиз, а Б ещё требует небольших правок и в релиз ещё не влит. Z>Код Б в ветку А не может попасть случайно, автор А знает, что задачи связаны и отразил это в Jira. Если задачи связаны зависимостью, то выкатка А будет ждать полной готовности Б. Либо (скорее всего) они пойдут одним фичабранчем.
Откуда он это знает-то? Потестил таску немного сам — работает, влил в девелоп, немного порезолвил конфликты, вроде работает. QA начали тестировать — работает. Замержил в релиз — а оно сломалось, т.к. отсутствуют некоторые изменения от Б, которые ещё тестируются и чуточку дорабатываются. Или, хуже того, порешил конфликты немножко по-другому.
Z>А как ты решаешь эту проблему в git-flow? А и Б в мастере, в Б оказались критические проблемы и ты выбрал один из предложенных тобой путей. Отключил ее фича флагом или сделал ей git revert. Как твои QA узнали, что функционал А тоже надо перетестировать?
Тут надо по тому списку из 4 пунктов действовать. Тяжесть последствий возрастает от первого пункта к последнему. Поэтому если в проекте часто что-то уходит дальше первого-второго пункта, то надо делать разбор полётов и что-то менять в консерватории. В общем случае, правки в релизе требуют перетестировать все фичи данного релиза, если нет полной уверенности, что правка действительно точечная и ничего другого сломать не может. Скажем, на втором пункте обычно правится какая-то мелочь, отследить влияние которой обычно тривиально и понять влияние на все фичи релиза. Третий пункт подразумевает, что QA должны протестировать что feature flag действительно сработал и старое поведение функционирует.
Z>·>Т.е. у вас ещё один полный раунд QA и для релизной ветки? Z>Не всегда. Чаще всего в этом нет необходимости, мы считаем, что код релиза всегда готов к раскатке.
Неясно на основании чего так считаете. Ведь этот данный код с данным sha1, судя по твоей схеме ни разу не тестировался.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Откуда он это знает-то? Потестил таску немного сам — работает, влил в девелоп, немного порезолвил конфликты, вроде работает. QA начали тестировать — работает. Замержил в релиз — а оно сломалось, т.к. отсутствуют некоторые изменения от Б, которые ещё тестируются и чуточку дорабатываются. Или, хуже того, порешил конфликты немножко по-другому.
Откуда в его ветке появился код Б с которым он это немного потестил?
·>Тут надо по тому списку из 4 пунктов действовать. Тяжесть последствий возрастает от первого пункта к последнему. Поэтому если в проекте часто что-то уходит дальше первого-второго пункта, то надо делать разбор полётов и что-то менять в консерватории. В общем случае, правки в релизе требуют перетестировать все фичи данного релиза, если нет полной уверенности, что правка действительно точечная и ничего другого сломать не может. Скажем, на втором пункте обычно правится какая-то мелочь, отследить влияние которой обычно тривиально и понять влияние на все фичи релиза. Третий пункт подразумевает, что QA должны протестировать что feature flag действительно сработал и старое поведение функционирует.
Не могу понять как у тебя все устроено. Команда из сильно больше (?) десятка программистов клепает фичи целый спринт и только потом начинается тестирование всего, что они накодили. В процессе тестирования в релиз докидываются хотфиксы найденных багов и из него выпиливаются или отключаются те фичи, правка которых не делается парой строк и может затянуться. Я ничего не перепутал?
·>Неясно на основании чего так считаете. Ведь этот данный код с данным sha1, судя по твоей схеме ни разу не тестировался.
А ты узнай сколько времени тестировался код sha1 которого ушел в твой последний релиз. Может оказаться, что тоже не так много.
Здравствуйте, 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.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ziaw, Вы писали:
Z> Другими словами, во время регресса приходится принимать решение, катить неготовую фичу, быстр допилить либо срочно ревертить. Вот от этого непростого выбора мы и отказались собственно.
Почему это непростой выбор? Поставьте ограничитель по времени, например: за минуту|час|день не пофиксили — реверт.
Z> feature flag как общий подход выглядит здесь как дорогой костыль, прикрывающий полуготовые фичи.
Костыль не дорогой на самом деле. Хотя требует некую культуру написания кода и тестов.
Зато с лихвой окупается, т.к. бранчей/мержей требуется гораздо меньше, и они короткоживущие.
Ещё и дополнительные возможности даёт типа A/B-тестирования.
Здравствуйте, ·, Вы писали:
·>Почему это непростой выбор? Поставьте ограничитель по времени, например: за минуту|час|день не пофиксили — реверт.
Это подойдет в тех компаниях, где стейкхолдерам пофиг, когда выйдет фича и под ее выход ничего не планируется. В других компаниях за такие шутки можно пойти писать авто-тесты на UI, чтобы качество принятия решений пришло в соответствие с должностными обязанностями.
·>Костыль не дорогой на самом деле. Хотя требует некую культуру написания кода и тестов. ·>Зато с лихвой окупается, т.к. бранчей/мержей требуется гораздо меньше, и они короткоживущие. ·>Ещё и дополнительные возможности даёт типа A/B-тестирования.
Фича флаг как общий подход безумно дорог в поддержке. Сложность между O(n^2) — O(n!). Сам по себе он конечно хорошо и зачастую незаменим, но как костыль для оперативного отключения нерабочей фичи в релизе — такое себе.
