Где должен жить готовый код? Откуда нам освободиться?

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

Что такое ветвящаяся стратегия?

  • Из какой ветви вы должны вырезать свою функциональную ветку?
  • После завершения кода, в какой ветви вы должны поднять MR (запрос на слияние) / PR (запрос на вытягивание) для проверки и тестирования кода?
  • После завершения тестирования и обзора, в какую ветку следует объединить эту функциональную ветку?

Почему это имеет значение?

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

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

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

Будут использоваться ветви master, develop и feature.

мастер

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

развивать

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

характерная черта

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

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

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

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

В какой ветке нужно проводить QA-тестирование? Другими словами, какую ветку следует развернуть в среде контроля качества?

Самый простой подход - иметь среду QA из ветки разработки ( то есть серверы QA будут развернуты с запуском сборки из ветки develop). И после подписания QA MR / PR может быть повышен до главной ветви.

Плюсы

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

Минусы

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

Решения

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

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

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

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

Отмените изменения этой функции и возобновите тестирование. Такой подход лучше для общей производительности команды, но может быть болезненным для владельца функции. Если они отменит изменения, он создаст новую фиксацию, отменив все свои изменения в этой ветке. И если они попытаются объединить его обратно после исправления, git будет считать, что только новые фиксации исправления будут объединены с develop, поскольку более старые фиксации уже присутствуют в истории фиксации develop.

Чтобы решить эту проблему, разработчику необходимо отменить возвратную фиксацию.

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

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

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

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

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

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

  • Отрежьте ветку от develop.
  • Пост-разработка и тестирование разработчиков, поднимите PR / MR до QA для проверки кода.
  • Обзор посткода, объедините его с веткой QA.
  • QA проводит тестирование функций, и после подписания вы поднимаете MR / PR для разработки.
  • Проведите второй раунд проверки (ради здравого смысла) или объедините свою ветку с develop напрямую, поскольку она уже проверена и протестирована.
  • Когда develop готов к выпуску (т. Е. Все ветви функций объединены), QA запускает сборку для проведения регрессионного тестирования. Эту сборку можно запустить в уже настроенной среде контроля качества.

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

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

  • У вас может быть тестирование функций из ветки QA и регрессия из стабильной develop ветки после слияния всех функций, которые запланированы в текущем выпуске.
  • develop всегда будет стабильным, и любой разработчик может отрезать свою feature ветку в любой момент.
  • Вы не будете спамить историю коммитов ветки develop.
  • Если QA сталкивается с проблемами в какой-либо ветке feature, вы можете исправить это и нажать без возврата, если эта функция не зависит от других.
  • Исправление: в случае возникновения каких-либо проблем с продуктом вырежьте ветку из master, исправьте и отпустите.

Заключение

Спасибо, Джашан Прит Сингх, за ваш вклад в эту статью.
Спасибо за чтение. Удачного кодирования!