Gitflow и тестирование/развертывание

С точки зрения процесса вам нужен только еще один необязательный шаг по сравнению со «стандартным процессом»: если вы обнаружите ошибку (или, возможно, критическую ошибку), вы отмените все изменения (т.е. слияния, которые содержат ошибку).

Вот как это работает:

• создайте тестируемую ветку или сокращенно НО из ветки разработки

• ветки функций объединяются в тестовую ветку, а не непосредственно в ветку разработки

• у вас есть НО, которое прямо сейчас либо идентично последнему выпуску, либо хорошо проверено на последней итерации этого процесса.

• Теперь вы объединяете все ветки функций / исправлений в той ветке, которая у вас есть.

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

• если тестовая итерация завершена успешно (т. е. без серьезных ошибок), вы объединяете ее с разработкой.

Давайте проверим, насколько это соответствует вашим требованиям:

Мы можем развернуть без введения бюрократии (например, выпуск в последнюю пятницу каждого месяца).

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

Если кто-то фиксирует код, содержащий ошибку, это не влияет на кого-то еще, кто зафиксировал код без ошибок. Другими словами, если кодер А пытается исправить ошибку, вводя новую ошибку, а кодер Б исправил свою ошибку, то код кодера Б продвинется дальше в конвейер, в то время как кодер А останется допоздна, исправляя ошибку.

Проверять

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

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

Тестировщики точно знают, без сомнения, что они одобряют для запуска в производство.

Вы можете очень легко определить с помощью стандартных команд git, является ли ветвь функции частью истории НО, что вам и нужно.

Недостаток / Вещи, которые вам нужны

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

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

• запускать автоматические тесты ветки фич перед слиянием с НО
• запустить автоматические тесты фиче-ветки после слияния с НО
• иметь много ХОРОШИХ автоматических тестов.
• проверки кода
• парное программирование
• автоматизировать развертывание в вашей тестовой среде

В основном все, что уменьшает объем работы тестировщиков и ускоряет остальные, очень помогает.

Вы сказали, что у вас не может быть много тестовых сред. Подумайте, можете ли вы иметь частичные тестовые среды, которые не требуют всех ресурсов, но все же хороши для некоторых тестов.