Сравнительный анализ того, когда проводить тест на дым (и должен ли он блокировать сборку)

Question

В настоящее время мы команда из 12 разработчиков в двух местах. В последние 3 квартала (3 выпуска) у нас всегда была перегрузка исправления ошибок перед выпуском:

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

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

Некоторые предпосылки:

• тест дыма длится 56 минут +- 10 минут.
• Тест дыма работает на 6 разных версиях ОС параллельно
• сборка занимает ~30 минут
• модель ветвления: рабочий процесс git

О чем мы думали до сих пор:

W: Блокировка дыма при каждой сборке:

Шаги, которые предпримет разработчик:

• функция исправления ошибок / финиша, тем временем делая n коммитов на его ветке. тянуть запрос → объединить в мастер
• ручная сборка + автоматическая блокировка дымовых испытаний
• две возможности (на самом деле 4, но мы проигнорируем здесь, если сборка не удалась с нашей стороны):
• а) счастливый путь: дым зеленый
• б) не так счастлив: есть проблемы в дыму
• мы смотрим на б):
• если есть какие-либо проблемы, нам нужно отменить слияние / диапазон коммитов в ветке разработки
• это можно сделать вручную или автоматически
• если это ручной процесс, нам нужен еще один запрос по запросу, по крайней мере, с двумя утверждениями (этого следует избегать, и все должно выполняться автоматически)
• после возврата мы не должны снова запускать дым (потому что состояние ветви точно такое, как было до неудачного дыма)
• в данный момент разработчик не имеет изменений в ветви разработки, только в своей ветви (на самом деле они есть, но код отменен)
• Затем он должен выяснить, почему дым не удалось, и исправить свой код и / или автоматизированные тесты.
• делает еще один запрос на включение
• Запрос на получение одобряется и объединяется для разработки.
• промойте и повторите описанный выше процесс.

X: блокирование дыма на ветвях перед слиянием, чтобы развиваться

Шаги, которые предпримет разработчик:

• исправить ошибку / закончить функцию в своей ветке
• ветка строится на бамбуке
• Серийная блокировка очереди на бамбуке, каждый разработчик будет ждать завершения других сборок на сборочной машине.
• после успешной сборки ветки дым запускается на 6 виртуальных машинах параллельно. ЭТА 1ч.
• Очевидно, у каждого разработчика должен быть клон из 6 виртуальных машин для запуска дыма. так что мы говорим о 6х машинах, где х = количество разработчиков
• это следует учитывать при разговоре о памяти, объеме памяти, вычислительной мощности в виртуальном центре (собственном облаке)
• отсюда мы можем повторить вышеописанные шаги, от "счастливого пути" до окончательного "запроса тяги для устранения дыма", просто чтобы не было необходимости в слияниях / возвратах, поскольку мы работаем над веткой.

Y: блокирует ночной дым

Шаги, которые предпримет разработчик:

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

Z: блокировка дыма при выпуске

То же самое, что и блокировка дыма на каждой сборке, но это делается только после того, как мы добавили в него ветки мастера и исправления вишни.

Небольшое влияние анализа на вышеуказанные подходы:

Риск:

• виртуальные машины должны быть недоступны - нам нужно по крайней мере два администратора в нашей команде, чтобы отменить тест дыма в бамбуке
• чем больше движущихся частей, тем больше рисков, поэтому: X гораздо более рискованно, чем W или Y или Z

Время:

Я попытаюсь оценить, какой из вышеупомянутых вариантов быстрее, учитывая итерацию / выпуск и в каком порядке

• W против X: X быстрее, потому что разработчики работают в параллельном режиме, и нет синхронных блоков, как в W.
• X против Y: Y быстрее, потому что разработчики не будут ждать сборки в каждой ветке, будет>2 слияния / сборка.
• (W или X или Y) против Z: довольно сложно сравнивать, потому что, да, Z быстрее, но мы должны учитывать время, необходимое для стабилизации сборки, потому что до этого момента нет блокирующего дыма - следовательно, поиск ошибок осталось ближе к концу.

До сих пор у нас есть Y как лучший подход времени.

Сложность:

чем больше шагов, тем больше движущихся частей, тем сложнее подход

• Z

Ресурсы:

X является наиболее ресурсоемким, потому что нам нужно 6x виртуальных машин для дыма (х) ( x = количество разработчиков)

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