В настоящее время мы команда из 12 разработчиков в двух местах.В последние 3 квартала (3 выпуска) у нас всегда была перегрузка исправления ошибок непосредственно перед выпуском:
- утечки памяти
- функциональность, которая работала, а затем не длянет явных причин
- сбоев в продукте или двоичных файлах, которые мы интегрировали из других команд, которые заблокировали команду тестирования
Наш менеджер предложил объединить блокирующие тесты дыма в каждой сборке, как в другой (подробнеезрелая команда).Что означает блокирование, так это то, что после запроса на извлечение, который объединяется с разработкой (ветвью разработки), выполняется сборка, а затем запускается дымовая проверка (на 6 виртуальных машинах с разными версиями ОС).Если дым проходит, слияние остается в сборке, поэтому сборка проходит.
Некоторые предварительные условия:
- проверка дыма выполняется за 56 минут + - 10 минут.
- дымовой тест выполняется параллельно на 6 различных версиях ОС
- сборка занимает ~ 30 минут
- модель ветвления: рабочий процесс git
То, о чем мы думали до сих пор:
W: Блокировка дыма при каждой сборке:
Шаги, которые может предпринять разработчик:
- функция исправления ошибок / финиша, тем временем делая n коммитов на его ветке.запрос на удаление → объединить в мастер
- ручная сборка + автоматическая блокировка дымового теста
- две возможности (на самом деле 4, но мы проигнорируем здесь, если сборка не удалась на нашей стороне):
- а) счастливый путь: дым зеленый
- б) не такой счастливый: есть проблемы в дыме
- мы смотрим на б):
- если естьПри возникновении любых проблем нам нужно отменить слияние / диапазон коммитов в ветви разработки
- . Это можно сделать вручную или автоматически.
- . Если это ручной процесс, нам нужен еще один запрос на получение спо крайней мере, два утверждения (этого следует избегать, и все должно быть сделано автоматически)
- после возврата мы не должны запускать дым снова (поскольку состояние ветви точно такое, как было до отказа дыма)
- на данный момент разработчик не имеет изменений в ветви разработки, только в своей ветви (на самом деле они есть, но код отменен)
- Затем он должен выяснить, почему дымСбой и исправление его кода и / или автоматических тестов
- делает другой запрос на получение
- запрос на получение одобрен и объединен для разработки.
- промыть и повторить вышеописанный процесс.
X: Блокировка дыма на ветках перед слиянием для разработки
Шаги, которые должен предпринять разработчик:
- исправить ошибку/ Завершить функцию на своей ветке
- Сборка ветки на бамбуке
- Очередь последовательных блокировок на бамбуке, каждый разработчик будет ждать завершения других сборок на машине сборки.
- после успешной сборки ветки дым запускается на 6 виртуальных машинах параллельно.ETA 1 ч.
- Очевидно, у каждого разработчика должен быть клон из 6 виртуальных машин для запуска дыма.так что мы говорим о 6х машинах, где х = количество разработчиков
- это следует учитывать, когда речь идет о памяти, объеме памяти, вычислительной мощности в виртуальном центре (нашем собственном облаке)
- изздесь мы можем повторить описанные выше шаги, от «счастливого пути» до окончательного «запроса на удаление, чтобы устранить дым», просто чтобы не было необходимости в слияниях / возвратах, поскольку мы работаем над веткой.
Y: Блокировка ночного дыма
Шаги, которые может предпринять разработчик:
- То же, что и выше, с дымом после каждой сборки, но без блокировки в течение дня.
- , даже если дым красный, восстановление после слияния не выполняется (только в особых критических случаях).
- исправления для дыма будут постепенно выполняться при разработке через запросы на извлечение и вавтоматическое тестирование репо при необходимости
- здесь у нас есть проблема: если дым не зафиксирован при разработке, другие сборки с изменениями других разработчиков не могут быть проверены этим дымом
- полночный дым блокирует, что означает следующий день вутром все разработчики все руки на палубе, чтобы исправить это, затем продолжить как обычно
Z: Блокировка дыма при выпуске
так же, как блокировка дыма на каждомсборка, но это делается только после того, как мы добавим в нее ветку master и исправим вишню.
Небольшой анализ влияния на вышеприведенные подходы:
Риск:
- Виртуальные машины недоступны - нам нужно как минимум два администраторав нашей команде, чтобы отменить тест дыма в бамбуке
- , чем больше движущихся частей, тем больше риск, поэтому: X гораздо более рискованно, чем W или Y или Z
Время:
Я попытаюсь оценить, какой из приведенных выше вариантов быстрее, учитывая итерацию / выпуск и в каком порядке
- W против X: X быстрее, потому что разработчики работают в параллельном режиме, и тамнет синхронных блоков, как в W.
- X против Y: Y быстрее, потому что разработчики не будут ждать сборки на каждой ветви, будет> 2 слияния / сборка.
- (W или X или Y) против Z: довольно сложно сравнивать, потому что, да, Z быстрее, но мы должны учитывать время, необходимое для стабилизации сборки, потому что до этого момента нет блокирующего дыма - отсюда и поискошибки остаются в конце.
До сих пор у нас есть Y как тЛучше всего подходить ко времени.
Сложность:
чем больше шагов, тем больше движущихся частей, тем сложнее подход
Ресурсы:
1148 * Хсамый ресурсоемкий, потому что нам нужны 6x виртуальных машин для дыма (х) (число разработчиков)
Какой из вышеперечисленных подходов вы используете, пожалуйста, поделитесь любыми улучшениями / новыми идеями о том, как лучше всего представитьфаза курения в нашем процессе сборки.