Схема работы с git и dev-сервером. Что посоветуете?
Всем привет!
Что имеется:
1) репозиторий на github в котором две ветки: main и develop. Вся разработка ведется на develop (под каждую задачу создается отдельная ветка и потом сливается с develop);
2) сервер production;
3) сервер staging.
После мержа с develop изменения отправляются на staging сервер где происходит тестирование нового функционала. После тестирования develop сливается в main и всё улетает в production. Тут всё ок, такая схема более чем устраивает.
Проблемы начали возникать когда появился новый разработчик и в прод стали попадать задачи которые еще не протестированы на staging сервере.
Подскажите, как тут быть? В общих словах, схема должна быть такой:
1) основная рабочая ветка - develop
2) каждый разработчик делает ветку от develop под свою задачу
3) после завершения работ над задачей она должна оказаться на staging-сервере для тестирования и, либо будет закрыта, либо отправится на доработку
4) когда несколько задач будут закрыты, нужно каким-то образом слить их в main, но исключив незавершенные задачи
С ветки main настроен автодеплой на production сервер, а с ветки develop - на сервер staging
Проблемы начали возникать когда появился новый разработчик и в прод стали попадать задачи которые еще не протестированы на staging сервере.
Видимо нужно запретить push в main и разрешить мержить в main только через PR-ы.
Делается это в настройках репозитория. Branches-> add branch protection rule
Проблема в том, что в develop есть завершенные задачи, и есть задачи которые требуют доработки. В main хочу чтобы попадали только завершенные задачи.
Пример:
есть ветка develop и 3 ветки от нее по задачам task-1, task-2, task-3
все 3 задачи готовы, они смержены в develop, на staging сервере их тестируют. Предположим, что task-1 и task-2 приняты, а task-3 требует доработок. Пока разработчик работает над task-3 я хочу готовые задачи слить в main, но когда я это делаю, то в main все равно попадает не доделанная task-3
Сергей Воробьев, тогда предлагаю такой подход, если хочется сохранить stage и prod, но с другим раскладом веток и экшенов:
1. Избавляемся от ветки develop, в которую мержат все кому не лень
2. Добавляем ветки для релизов (раз мы релизим сразу пачку фичей, а не по готовности)
3. Убираем автоматическую раскатки на stage. Разрешаем деплоить на stage любую ветку
1. Разработчик создаёт ветку для своей фичи и выполняет в ней всю работу
2. Разработчик создаёт PR для мержа в какой-то релиз.
3. Когда нужно протестировать на stage - разработчик вручную тригерит action для раскатки своей фичи на stage
4. После тестирования фичи - она мержится в релизную ветку
5. При приближении даты релиза - вводится запрет на мерж новых фичей в релизную ветку
6. Проводится финальное тестирование всех фичей в релизной ветке, делаются хотфиксы, если какие-то фичи между собой конфликтуют.
7. Релизная ветка мержится в main, создаётся новая релизная ветка.
Василий Банников, эта механика имеет право на жизнь, но только в случае, если можно создать по копии приложения (на поддоменах например) для каждой релизной ветки отдельно, иначе это ревьюить просто ад (и в таком случае "релизная ветка" не имеет никаких преимуществ перед просто "фича веткой").
"Review apps" их обычно называют, и это может вылиться страшным геморроем)
Без них же любая релизная ветка, влитая на стейдж, до момента окончания тестирования будет блокировать выкат любой другой (ну или выкат будет собирать матюки всех причастных "б.., да я не закончил ещё а ты всё убрал"), и если процесс тестирования длиннее пары часов (что почти всегда), то тут на коммуникацию времени больше уйдёт чем потенциальный выигрыш
Вообще есть такое ощущение проблемы XY от вопроса, отпишу автору в отдельном сообщении
Сергей Воробьев, я даже немного стесняюсь спросить, а зачем вы почкуете фича-ветки от develop, а не от master, тем более не имея релизного цикла и привязанных к нему задач?
Делайте ветки от master'a и это решает все ваши проблемы. Тем более что у вас, очевидно, получается закрывать задачи так, чтобы master с develop не расходились на тысячу коммитов по итогам квартала
Максим Морев, спасибо за ответ, а можете подробнее описать процесс если делать ветки от мастера? Вообще, в main хочется скидывать только выполненные и завершенные задачи. Готовность задачи определяется по результатам тестирования на staging сервере на который заливаются все изменения на develop ветке. Другими словами, разработчику нужно свою задачу предварительно отправить на тестовый сервер и если всё ок, то эта задача пойдет в прод.
А если делать ветки от master, то как потом будет работать деплой на тестовый сервер? Нужно же куда то эту ветку слить чтобы эта ветка ушла на тестовый сервер
Сергей Воробьев, мне таки вопрос непонятен :) Попробую развернуть.
Вот смотрите. Вот прямо сейчас, допустим, вы закрыли все текущие таски.
Если я правильно понимаю, в вашем текущем устройстве репозитория это будет означать, что develop эквивалентен master, так ведь?
Дальше нужно создать фича-ветку, назову её "фича-1". Возьмите её от мастера (так как они равны, разницы никакой).
Делаете фичу, вливаете её в develop, смотрите, тестируете.
Если нужно внести правки - вносите их в фича-ветку и потом снова мерджите её в develop.
Саму фича-ветку до момента завершения тестирования и финального аппрува не трогаете, она есть и служит индикатором того, что задача в работе.
Другие разработчики точно также ветвятся от master и делают свои фичи в изоляции от параллельных фич.
Положим, есть одна параллельная задача и она идёт в ветке "фича-2".
При таком подходе мастер у вас - это всегда чистый предыдущий релиз. В описанной выше ситуации у вас есть две фичи, они обе живут в своих ветках от master, обе влиты в develop.
Тут решается, что фичу-1 надо выкатывать, а фичу-2 - пока не успеваем и надо погодить.
Ветку фича-1 мерджим в мастер и релизим - с этим проблем никаких, ни конфликтов, ни лишнего чего там не будет, так как ветка - прямой потомок, сделанный в изоляции.
После мерджа в master нужно провести манипуляцию - в ветку "фича-2" нужно влить новый актуальный мастер (или лучше заребейзить, если она только локально живёт).
Можно и пропустить этот шаг, но обычно лучше заранее проверить обновившийся мастер - мало ли там какие сайд-эффекты появились, да и конфликты, если появились, разруливать чем раньше, тем проще.
Таким образом в незавершённых фича-ветках по-прежнему будет сохраняться код, актуальный только для продакшена (так как они почкуются и сверяются только с мастером), в них не будет содержаться частично сделанных изменений других фич (так как друг друга и develop они не воспринимают как источник коммитов), и в develop будут жить одномоментно все фичи, нужные для тестирования.
Сергей Воробьев, у этого подхода есть, по сути, только один явный недостаток - это долгоживущие объёмные ветки, которые могут жить только в develop годами (ладно, слегка утрирую) без мерджа в мастер, или те, про которые в принципе могут забыть (хотел бы я шутить).
Про них уже не помнит никто, но так как они объёмные, они создают дополнительные конфликты на этапе мерджа в develop. Если у вас нет таких - вам повезло :)
Решение в любом случае административное - или допинывать до релиза, либо делать напрямую в develop реверт коммитов из фича-ветки, но это прям такое... оно обычно выливается в кучу проблем, когда про ветку таки вспоминают.
Но, в принципе, долгоживущие объёмные ветки в любой модели ветвления будут проблемой, вопрос лишь в том, на каком этапе :)
> Максим Морев, Про них уже не помнит никто, но так как они объёмные, они создают дополнительные конфликты на этапе мерджа в develop. Если у вас нет таких - вам повезло :)
Для этого разработчик может сделать ребейз в своей фичаветке перед тем как делать пулл реквест на мердж
