Как Git Flow работать с QA-тестированием как выпуска, так и новой функции?

Мы используем Git Flow в нашем последнем проекте iOS, и я пытаюсь разработать способ работы с QA, чтобы они могли протестировать последнюю версию, а также проверить новую функцию, не беспокоясь о которые были исправлены в какой ветке.

В настоящее время они тестируются на ветке release/v1.0.1, у которой исправлено несколько ошибок из оригинала release/v1.0. Одновременно я работаю над новой функцией, которая была запланирована для версии v1.1, но была разветвлена ​​от ветки develop одновременно с release/v1.0.1 и поэтому не имеет никаких исправлений ошибок в ней.

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

Итак, что является лучшим способом заставить их проверить это? Я мог бы объединить release/v1.0.1 в свою ветвь функции, но тогда я должен убедиться, что я не объединился в develop до того, как release/v1.0.1 был выпущен... И я догадываюсь, что это в некоторой степени нарушает поток Git методология. Я мог бы создать совершенно новую ветку только для тестирования QA, которая объединяет мою функцию с release/v1.0.1, но тогда что мне делать с любыми ошибками, которые они находят в этой ветке? Где я могу объединить его обратно после раунда QA?

В дополнение ко всему этому, я должен рассмотреть номера сборки и номера версий, чтобы они имели смысл. В настоящее время номера версий - это те, которые используются для выпуска, а номера сборки увеличиваются с каждой новой строкой для QA. Однако, если они получают сборку из двух отдельных ветвей, я мог бы столкнуться с битами числа сборки, которые могут вызвать путаницу.

Каким будет лучший способ справиться с этими проблемами?

Ответы

Ответ 1

Я буду ссылаться на части первой диаграммы из nvie.com Git Страница потока в течение всего моего ответа; для завершения, я добавил снимок экрана ниже.

enter image description here

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

Итак, что является лучшим способом заставить их проверить это? Я мог бы объединить release/v1.0.1 в свою ветвь feature, но тогда я должен убедиться, что я не объединюся в разработке до того, как релиз /v 1.0.1 был выпущен `...

Нет; вам не следует объединять ветвь релиза непосредственно в ветки функции. В соответствии с моделью Git Flow вы должны (постоянно)

  • объединить release/v.1.0.1 в ветвь develop,
  • объединить develop в вашу ветвь (ы),

чтобы внести стабилизирующие изменения из release/v.1.0.1 в вашу ветвь (ы).

enter image description here

(К сожалению, приведенное выше изображение не показывает непрерывные слияния develop в feature, а то, что вы должны делать.)

Я мог бы создать совершенно новую ветку только для тестирования QA, которая объединяет мою функцию с release/v1.0.1 [...]

Там есть какая-то двусмысленность. Вы предлагаете слить feature в release/v1.0.1 или слить release/v1.0.1 в feature? Вы не должны делать первое, потому что слишком поздно для новых функций перейти в release/v.1.0.1; они должны будут отправиться с будущим выпуском, т.е. после v1.0.1. Прочтите пузырь слева:

enter image description here

И вы тоже не должны делать последнего; по крайней мере, не напрямую. Как объяснялось выше, чтобы внести изменения с release/v1.0.1 в feature, вы должны сначала объединить release/v1.0.1 в develop, а затем объединить develop в feature; это может/должно произойти несколько раз, прежде чем feature будет готова к объединению обратно в develop.

Добавление

Если вы следуете модели потока Git для письма,

  • у вас не должно быть двух или более сосуществующих ветвей освобождения, а
  • QA должен только проверять выпуск (a.k.a. стабилизирующие) ветки.

Поэтому, если другие функции должны войти в v1.1, вы не можете просить QA еще раз просмотреть ваши новые функции; вам нужно подождать, пока не будут выполнены другие функции. После того, как все функции для v1.1 были завершены и интегрированы в develop, создайте ветвь release/v1.1 (которая вытекает из главы develop); затем попросите QA начать тестирование/стабилизацию этой ветки.

Если, с другой стороны, вы действительно не можете дождаться завершения других функций до того, как попросите QA проверить свои собственные новые функции, вы должны создать промежуточную ветвь релиза (называемую v1.0.2, я думаю) от develop и сообщить QA для проверки release/v1.0.2. Как только он будет стабилизирован до удовлетворительной степени, объедините его в master (и в develop).