Комментарии 5
Больная тема для нас, и хоть у нас Юнити, а не Анрил - думаю все равно окажется в рамках этой статьи.
Какие у вас условия для заезда ПРа в девелоп (или мастер, смотря какая ветка у вас считается стабильной)? Помимо апрувов от лидов и прочих заинтересованных? Гоняете ли вы для каждого ПРа тесты, в том числе мануальные, собираете ли билд чтобы выявить ошибки компиляции и в целом не сломалась ли сборка.
А после вливания ПРа в стабильную ветку - делаете ли повторные тесты, чтобы убедиться что после мерджа не сломалось ничего нового? :)
Привет, сейчас попробую ответить на ваш вопрос и даже больше, все-таки в самой статье я слишком мало рассказал про то, как мы работаем с ветками (в самой статье считай, что ничего толком и не было сказано кроме того, что у нас их бывает больше, чем одна), поэтому постараюсь хотя бы тут хоть как-то, но поделится нашим опытом.
Сразу же процитирую сам себя:
У нас внутри работают независимые друг от друга команды, у каждой из которых есть своя история, свой опыт и набитые шишки, а соответственно, и свои стандарты.
И тут все дело обстоит точно также, поэтому расскажу именно за опыт своей команды.
Основной рабочей веткой является 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)
Спасибо за такой развернутый ответ!
А как долго у вас собираются билды и как долго ранятся автотесты? Потому что процесс прям как у нас, но у нас проблема с тем что долго ПРы заезжают. Билд может собираться час, тесты могут каких полчаса бежать, потом еще мануальное тестирование в ветке ПРа (заафекченного функционала) пройдет - а там уже глядишь и девелоп пару раз обновился, а замерджиться можно только если разница между веткой и девелопом (по количеству коммитов в девелоп) должна быть минимальной. И погнали по новой - билд, автотесты (которые еще и флаки порой бывают). Еще и вручную нельзя завозить ПРы - все делает бот, который для скорости собирает несколько ПРов в батч, и если один из них в чем-то зафейлится - весь батч будет пересобиратья и ждать. В итоге среднее время заезда ПРа - неделя после его создания. И несмотря на всю хитрую схему все равно случается что девелоп ломается - тесты ведь не на весь код запускаются, а только на изменения, иначе отрабатывали бы несколько часов, да и автомерджилка может пошалить на мердже юнитевских ямл файлов, когда автоматически разруливает конфликты.
Причем, на прошлом проекте тестирование у нас проводилось только вручную и только в девелопе, и стабильность последнего была не сильно хуже ( у нас автотестов и в помине не было - только на сервере). Так что придя на проект, сразу возник вопрос - а стоит ли игра свеч, если итоговая стабильность не 100%?
ну, смотрю у вас схема похожая, так что может такова наша се ля ви - страдать )
Насчёт Plastic Scm - пользовался с уе (и поднимал) Perforce, GIT и сам Plastic. Для использования с UE лучше пластика человечество ничего не изобрело. Содержит все плюсы гита и перфорса и не содержит основных минусов и того и другого. Звучит, конечно, слишком сладко чтобы быть правдой, так что и ложка дёгтя - у нас после февральских как-то на пару месяцев отключили весь доступ, так что надо будет всегда держать бекап в том же гите, например. Ну и ценник, если хотите держать свой сервак (не клауд решение) ~25$ за лицо не оч приятно. Но с точки зрения пользования это килерфича, честно, оч крутой инструмент. Мб напишу постик с подробнее инфой.
Какие технологии, процессы и решения мы используем при разработке на Unreal Engine 4 — опыт Allods Team