{"id":13590,"url":"\/distributions\/13590\/click?bit=1&hash=03c45bd9f120d2c4307c8a83d2e290e4193e2d7cfbf2807f3e8cf799cc81b1a0","title":"\u0421\u0434\u0435\u043b\u0430\u0442\u044c \u0431\u043b\u0430\u0433\u043e\u0442\u0432\u043e\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430 \u0434\u0435\u043d\u044c\u0433\u0438 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438","buttonText":"\u041a\u0430\u043a?","imageUuid":"629d35eb-0db2-5643-b6f7-bd3a6714a6eb","isPaidAndBannersEnabled":false}
Southbridge Company

Эффективная стратегия ветвления Git, о которой должен знать каждый разработчик

Где должна жить стабильная версия кода? Откуда надо делать релиз?

Для тех, кто хочет научиться эффективно работать в команде и применять Git, в Слёрме подготовили практический курс и перевод интересного материала о стратегии ветвления.

Photo from  ITNEXT

Какой должна быть основная ветка: master, develop или что-то еще? Давайте взглянем на стратегию ветвления Git, с которой вы можете быть еще не знакомы.

На какие вопросы должна отвечать стратегия ветвления?

  • На какой ветке надо создавать feature ветку?
  • После завершения кода в какой ветке стоит создавать MR (Merge Request)/PR (Pull Request) для проверки и тестирования кода?
  • С какой веткой сливать эту feature ветку после завершения тестирования и анализа?

Важные вещи, которые должна решать стратегия ветвления

  • Ветка, на которой вы создаете функциональную ветку, должна быть стабильна в продакшне.
  • Нельзя сливать код с ошибками или непротестированный код с продакшн веткой (ветка, откуда вы делаете деплой).
  • В процессе слияния вашего кода с продакшн-веткой вы должны столкнуться с минимальным количеством конфликтов слияния.

Цель стратегии ветвления в том, чтобы повысить стабильность кода и продуктивность разработчиков и избежать лишних конфликтов.

Я не буду затрагивать все типы стратегий ветвления, но я назову лучшую, которая применяется чаще всего.

В ней используются ветви master, develop и feature.

master

  • Мы называем ее продакшн веткой. В ней находится хорошо протестированный стабильный код.
  • Из этой ветки должен был произойти предыдущий релиз, и следующий также должен быть из нее.
  • У нас могут быть пайплайны для релиза из этой ветки (т.е. каждый раз, когда происходит очередное слияние в эту ветку, автоматически запускается пайплайн, который делает сборку и деплой ПО на наши рабочие серверы).
  • Она должна принимать слияния только с веткой develop.

develop

  • Ветка на нижнем по отношению к master уровне.
  • Разработчик, начинающий работать над какой-то функцией, создаёт новую ветку из этой ветки.
  • После завершения разработки/тестирования/анализа кода разработчик создаёт MR/PR на ту же самую ветку, так как именно из этой ветки мы будем собирать следующий релиз.
  • Для того, чтобы зарелизить состояние проекта в этой ветке, мы делаем мерж в ветку master.

feature

  • Ветка, создаваемая из develop для работы над запланированной на следующий выпуск функцией.
  • Обычно в этой ветке работает один разработчик.

Разделение на эти три типа ветки помогает избегать ненужных конфликтов и повышает продуктивность команды.

Тестирование QA

Однако мы пропустили одну вещь: тестирование QA.

На какой ветке его делать? Другими словами, какую ветку следует развернуть в среде QA?

Самый простой подход: иметь среду QA на ветке разработки (т. е. серверы QA будут развернуты со сборкой, выпускаемой из ветки develop). А после завершения тестирования и контроля качества создается MR/PR в ветку master.

Стратегия с 2 ветками

Плюсы

  • Каждое изменение может быть протестировано до релиза через единую сборку/развертывание (т.е. тестирование отдельных функций может быть проведено за один раз для всех функций).
  • После тестирования функций эта ветка более всего подходит для регрессионного тестирования, поскольку для следующего выпуска на ней уже запланированы изменения.

Минусы

  • Если в изменениях в одной из feature веток есть баг, то тестирование и QA будет заблокировано и создаст простой для команды.

Варианты решения

Первое решение

Подождать, пока автор feature-ветки исправит проблему. Слить ее с веткой develop, снова развернуть ее в среде QA и возобновить тестирование. Но это нецелесообразный вариант, поскольку мы не знаем, сколько времени понадобится на исправление того или иного бага.Кроме того:

  • это простой для команды QA.
  • блокировка релизов в случае, если релиз может пройти даже без этой функции.
  • топтание на месте в ветке develop, если QA выявляет баги в нескольких функциях.

Второе решение

Отменить изменения этой функции и продолжить тестирование. Такой подход эффективнее с точки зрения продуктивности команды, однако для автора feature-ветки он может быть болезненным. Отмена изменений приведет к созданию нового коммита, что вызовет отмену всех изменений от этих разработчиков в данной ветке. А если они попытаются после исправления багов слить ее обратно, Git будет использовать для слияния с develop только новые коммиты исправлений, так как более старые коммиты уже находятся в истории коммитов develop.

Чтобы решить эту проблему, разработчику нужно отменить коммит отмены.

Третье решение

Третьим и самым простым решением будет принудительно запушить master в develop, заново слить остальные ветки feature и заново запустить QA.

Для продуктивности команды я бы порекомендовал второй путь.

Лучший подход

Всю эту проблему можно решить следующим образом: создать еще одну веку QA для тестирования. В идеале QA должна обновляться вместе с develop .

Таким образом появится дополнительный шаг, и весь функциональный цикл будет выглядеть следующим образом:

  • Начинаете новую ветку из develop.
  • После разработки и тестирования создаёте PR/MR на QA для анализа кода.
  • После анализа кода сливаете ее с веткой QA.
  • QA проводит тестирование функции, и после теста вы создаёте MR/PR на develop.
  • Проводите второй раунд анализа (для спокойствия) и сливаете вашу ветку напрямую в develop, поскольку она уже проанализирована и протестирована.
  • Как только develop готова к релизу (то есть все feature ветки слиты), QA запускает сборку для проведения регрессионного тестирования. Этот билд можно запустить в уже созданной среде QA.
Стратегия с 3 ветвями

Преимущества этого подхода

Несмотря на то, что этот подход внешне очень похож на предыдущий и, на первый взгляд, у добавления еще одной ветви нет особых преимуществ, он поможет увеличить продуктивность следующим образом:

  • Вы можете проводить тестирование функций на ветке QA, регрессионное тестирование на стабильной ветке develop после слияния всех функций, которые запланированы в текущем выпуске.
  • Ветка develop всегда будет стабильна, а любой разработчик сможет пустить от нее свою ветку feature в любое время.
  • Вы не будете засорять историю коммитов в ветке develop.
  • Если у QA появятся проблемы с любой веткой feature, вы сможете их решить и провести без отмены изменений, если эта функция независима от других.
  • Патч (hotfix): в случае любой проблемы с продуктом начните ветку из master, исправьте проблему, и зарелизьте.
0
Комментарии
Читать все 0 комментариев
null