Привет, сейчас попробую ответить на ваш вопрос и даже больше, все-таки в самой статье я слишком мало рассказал про то, как мы работаем с ветками (в самой статье считай, что ничего толком и не было сказано кроме того, что у нас их бывает больше, чем одна), поэтому постараюсь хотя бы тут хоть как-то, но поделится нашим опытом.
Сразу же процитирую сам себя:
У нас внутри работают независимые друг от друга команды, у каждой из которых есть своя история, свой опыт и набитые шишки, а соответственно, и свои стандарты.
И тут все дело обстоит точно также, поэтому расскажу именно за опыт своей команды.
Основной рабочей веткой является develop, от него уже создаются новые ветки (фиче-ветки) и в него они же и попадают обратно, Trunk-Based development подход, но со своими допущениями, например некоторые фиче-ветки могут жить больше 2–3 дней, над этим мы пока что работаем. При этом мы соблюдаем следующее правило: "develop должен всегда собираться в независимости на каком этапе разработки находится проект", если кто-то залил что-то что ломает сборку develop, мы сразу же реагируем на это и отправляемся фиксить проблему. Именно от develop собираются Nightly Stable Build, который отправляются на smoke тест нашим QA каждое утро.
Post Commit Build у нас работает на каждой ветке по умолчанию, не важно с какой целью ветка была создана (интеграция нового контента/новая фича/новая карта/etc), бывают исключения из правил, но обычно это custom-случаи, которые оговариваются внутри (Например: ветка для подготовки проморолика или эксперименты).
Что касаемо фиче-веток, тут дело обстоит следующим образом:
Под задачу создается фиче-ветка, в которой ведется вся связанная работа.
После коммитов осуществляется Post Commit Build.
По мере необходимости разработчик может пригласить QA для тестов своей ветки.
Как только все работы закончены в фиче-ветку мерджиться develop.
После чего QA проводят regression тест, в случае необходимости вносятся правки.
Как только regression тест пройден ветка мерджиться обратно в develop.
В случае если между моментом мерджа develop’а в фиче-ветку и прохождением regression тестов (сами тесты, плюс правки могут занимать не мало времени, тут очень зависит от фичи) появились новые изменения в develop (а так очень часто бывает) происходит повторный мердж. В случае если новые изменения в develop никак не связаны с фичей, то тогда разрешается замерджить фиче-ветку сразу в develop минуя regression тестирование, в противном случае проводится повторное regression тестирование, но только с фокусом на то, что было затронуто. Были ли случаи, когда приходилось проверять все по несколько раз? Да! Но стабильность требует жертв!
Что касаемо веток под релиз и около подобных. На момент разработки мы уже создаем внутренние микро релизы, на этот счет у нас есть своё правило: "Результатом каждого mileston'a должна быть версия проекта, при этом результативный билд не должен содержать блокеры и криты!". Для того чтобы подготовить такую версию, перед концом mileston'a мы делаем фича фриз (момент фича фриза оговаривается заранее при планировании mileston'a), при этом зачастую работы в develop должны продолжаться и именно поэтому мы не можем блокировать именно сам develop, поэтому мы создаем RC (Release Candidate) ветку под текущую подготовку версии, в которой уже мы ведем все дальнейшие работы по подготовке к сдаче (багфиксы, полишинг), как только QA дает нам отмашку что RC соответствует всем требованиям, RC мерджиться в stable из которого уже и собирается финальный билд, при этом в сам stable у нас запрещено что либо заливать кроме как мерджа RC. Сам же RC по мимо того, что мерджиться в stable, мерджиться в develop, чтобы в нём также были все фиксы ошибок что были найдены во время тестирования. Сама ветка stable остается жить с нами, чтобы в случае чего у нас была возможность собрать, именно тот билд, который мы сдавали последним.
А вот на момент релиза между RC и stable добавляется ветка lotcheck (ветка, из которой собирается версия для прохождения lotcheck'a на платформах) если все хорошо, и версия прошла лотчек, то ветка мерджиться в stable. А контроль фичей которые попадают в финальный билд, мы осуществляем при помощи feature flags.
Что касаемо самих Pull-Request, то мы их используем крайне редко, причиной тому является Trunk-Based development подход. Но если мы и используем Pull-Request то обычно только как механизм code review, не более.
Как итог, если вкратце ответить на вопрос, мы не так часто используем Pull-Request, но тесты активно гоняем (в нашем случае автотесты являются частью Post Commit Build, а про regression написано в шаге 6) Но если бы и использовали (ввиду процессов что описаны выше) то условиями заезда в develop были бы:
Code Review (в нашем случае оно проходит между шагом 3 и 4, исполнитель приглашает своего ментора для проведения ревью)
Соответствие ожидания и результата, проводится фичеовнером (в нашем случае результат уже отсматривается после мерджа в develop либо же прям в момент разработки на шаге 3)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
С удовольствием бы почитал постик, пока что звучит как минимум интересно!
Привет, сейчас попробую ответить на ваш вопрос и даже больше, все-таки в самой статье я слишком мало рассказал про то, как мы работаем с ветками (в самой статье считай, что ничего толком и не было сказано кроме того, что у нас их бывает больше, чем одна), поэтому постараюсь хотя бы тут хоть как-то, но поделится нашим опытом.
Сразу же процитирую сам себя:
И тут все дело обстоит точно также, поэтому расскажу именно за опыт своей команды.
Основной рабочей веткой является develop, от него уже создаются новые ветки (фиче-ветки) и в него они же и попадают обратно, Trunk-Based development подход, но со своими допущениями, например некоторые фиче-ветки могут жить больше 2–3 дней, над этим мы пока что работаем.
При этом мы соблюдаем следующее правило: "develop должен всегда собираться в независимости на каком этапе разработки находится проект", если кто-то залил что-то что ломает сборку develop, мы сразу же реагируем на это и отправляемся фиксить проблему.
Именно от develop собираются Nightly Stable Build, который отправляются на smoke тест нашим QA каждое утро.
Post Commit Build у нас работает на каждой ветке по умолчанию, не важно с какой целью ветка была создана (интеграция нового контента/новая фича/новая карта/etc), бывают исключения из правил, но обычно это custom-случаи, которые оговариваются внутри (Например: ветка для подготовки проморолика или эксперименты).
Что касаемо фиче-веток, тут дело обстоит следующим образом:
Под задачу создается фиче-ветка, в которой ведется вся связанная работа.
После коммитов осуществляется Post Commit Build.
По мере необходимости разработчик может пригласить QA для тестов своей ветки.
Как только все работы закончены в фиче-ветку мерджиться develop.
После чего QA проводят regression тест, в случае необходимости вносятся правки.
Как только regression тест пройден ветка мерджиться обратно в develop.
В случае если между моментом мерджа develop’а в фиче-ветку и прохождением regression тестов (сами тесты, плюс правки могут занимать не мало времени, тут очень зависит от фичи) появились новые изменения в develop (а так очень часто бывает) происходит повторный мердж. В случае если новые изменения в develop никак не связаны с фичей, то тогда разрешается замерджить фиче-ветку сразу в develop минуя regression тестирование, в противном случае проводится повторное regression тестирование, но только с фокусом на то, что было затронуто. Были ли случаи, когда приходилось проверять все по несколько раз? Да! Но стабильность требует жертв!
Что касаемо веток под релиз и около подобных.
На момент разработки мы уже создаем внутренние микро релизы, на этот счет у нас есть своё правило: "Результатом каждого mileston'a должна быть версия проекта, при этом результативный билд не должен содержать блокеры и криты!".
Для того чтобы подготовить такую версию, перед концом mileston'a мы делаем фича фриз (момент фича фриза оговаривается заранее при планировании mileston'a), при этом зачастую работы в develop должны продолжаться и именно поэтому мы не можем блокировать именно сам develop, поэтому мы создаем RC (Release Candidate) ветку под текущую подготовку версии, в которой уже мы ведем все дальнейшие работы по подготовке к сдаче (багфиксы, полишинг), как только QA дает нам отмашку что RC соответствует всем требованиям, RC мерджиться в stable из которого уже и собирается финальный билд, при этом в сам stable у нас запрещено что либо заливать кроме как мерджа RC. Сам же RC по мимо того, что мерджиться в stable, мерджиться в develop, чтобы в нём также были все фиксы ошибок что были найдены во время тестирования.
Сама ветка stable остается жить с нами, чтобы в случае чего у нас была возможность собрать, именно тот билд, который мы сдавали последним.
А вот на момент релиза между RC и stable добавляется ветка lotcheck (ветка, из которой собирается версия для прохождения lotcheck'a на платформах) если все хорошо, и версия прошла лотчек, то ветка мерджиться в stable. А контроль фичей которые попадают в финальный билд, мы осуществляем при помощи feature flags.
Что касаемо самих Pull-Request, то мы их используем крайне редко, причиной тому является Trunk-Based development подход. Но если мы и используем Pull-Request то обычно только как механизм code review, не более.
Как итог, если вкратце ответить на вопрос, мы не так часто используем Pull-Request, но тесты активно гоняем (в нашем случае автотесты являются частью Post Commit Build, а про regression написано в шаге 6)
Но если бы и использовали (ввиду процессов что описаны выше) то условиями заезда в develop были бы:
Code Review (в нашем случае оно проходит между шагом 3 и 4, исполнитель приглашает своего ментора для проведения ревью)
Соответствие ожидания и результата, проводится фичеовнером (в нашем случае результат уже отсматривается после мерджа в develop либо же прям в момент разработки на шаге 3)