Как развернуть одновременно несколько критических ошибок в процессе Gitflow? - PullRequest
Новая
       21

Как развернуть одновременно несколько критических ошибок в процессе Gitflow?

0 голосов
/ 17 апреля 2019

Поэтому мы используем процесс Gitflow для безопасного и надежного CID (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)

Но что-то не так.

Допустим, у нас есть 10 критических ошибок в продуктах - они должны быть исправлены как можно скорее. Таким образом, 10 ошибок назначены 10 разработчикам. Dev 1 создает исправление 0.0.1, фиксирует в нем исправление, исправление загружается в промежуточный env и передается в QA для проверки. В это время dev 2 хочет создать исправление 0.0.2 для своей ошибки, но он не может, поскольку Gitflow запрещает создание нового исправления, если оно уже существует. Поэтому он должен либо дождаться закрытия hotfix / 0.0.1, либо зафиксировать то же самое исправление. Конечно, нормальный выбор - зафиксировать это исправление / 0.0.1, потому что его ошибка критична и не может дождаться исправления ошибки 1.

То же самое делают каждые 10 разработчиков с 10 критическими ошибками.

QA проверяет ошибку 1 и подтверждает развертывание. Но исправление не может быть закрыто и развернуто, потому что остальные 9 ошибок не проверены или просто не работают

Итак, чтобы быть закрытым, каждая ошибка в этом исправлении должна работать и подтверждаться. В нашем случае это занимает время, много времени - 1,2 недели, к счастью, - так как все больше и больше вещей должно быть исправлено как можно скорее на производстве. Таким образом, разработчики все больше и больше фиксируют эту ветвь, еще больше задерживая первые ошибки.

Так что, в конце концов, после того, как все эти ошибки исправлены и подтверждены, пришло время, наконец, закрыть исправление и развернуть эти критические ошибки на prod ... с довольно большой задержкой. Но есть и еще одна большая проблема - THE MERGE с веткой dev, где другие разработчики делают свою работу (например, небольшие исправления ошибок в следующем выпуске). Ужасное, продолжающееся несколько часов слияние.

Итак, мы, очевидно, делаем что-то не так - что может быть решением для этого? Чтобы наши исправления были вовремя и не имели страшных слияний с dev.

Одним из решений, о котором мы думали, является установка в исправлении ограничения на количество ошибок, которые оно должно содержать - например, максимум 5 ошибок, другие ошибки должны ждать, пока они не будут исправлены. Это, однако, означает, что только lead-dev должен фиксировать исправление, так как он должен обеспечивать ограничение (иначе сложно контролировать). Но в этом случае ошибки все еще удерживаются, а быстрое развертывание не достигается.

Какая была бы нормальная процедура? Пожалуйста, поделитесь своими идеями.

1 Ответ

0 голосов
/ 17 апреля 2019

Если вы тратите несколько часов на слияние, то вы, вероятно, делаете это неправильно.Одним из подходов является привлечение эксперта по контролю версий на один день для обучения вашей команды.Это относительно небольшая стоимость по сравнению с зарплатой.Я должен подумать, что вы могли бы найти очень хорошего человека за 500 фунтов (600 долларов США) в день, и он может понадобиться вам только на день или два.

Интересно также, проводите ли вы тестирование (с командой QA)слишком ручной.Могут ли исправления ошибок сопровождаться юнит-тестами, чтобы доказать, что они являются улучшением?Если это так, разработчик должен иметь возможность объединить мастер в свою ветку исправления ошибок, запустить новый экземпляр для некоторой простой проверки качества, заставить QA проверить систему, получить команду, ведущую для PR исправления и модульных тестов, а затем объединить прямо вОсвойте и заново разверните.

Кроме того, убедитесь, что ваше развертывание в режиме реального времени полностью автоматизировано.Делать несколько живых (маленьких) выпусков в день - это хорошая цель.

Обновления

Вышеприведенный совет остается в силе, но, как вы уже сказали, это старый проект:

  • Получите некоторые автоматизированные тесты на месте.Попробуйте настроить функциональные / браузерные тесты для большей части проекта, чтобы вы могли быть уверены в изменениях.
  • Не отклоняйте модульные тесты из-под контроля.Возможно, они могут быть только для нового кода или новых изменений, по крайней мере, для начала?Да, проект старый, но не позволяйте себе легко сорваться с крючка.Модульные тесты принесут дивиденды в долгосрочной перспективе.Если у вас нет внедрения зависимостей в проекте, добавьте это, даже если оно не используется сразу для всех экземпляров.
  • Повторяется сверху: уменьшите ваши релизы.
...