Блог

Наша текущая настройка CI является типичной: для каждого PR, сделанного в нашем основном репозитории Git, у нас есть Jenkins, на котором выполняется build test, и после прохождения этих и code reviews мы объединяемся. Это занимает около часа на PR.

Я пытаюсь найти разумный способ автоматизировать этап процесса тестирования, который мы запускаем после нашего CI (тестирование производительности), и в настоящее время мы запускаем по требованию, вручную. Это длительные тесты, выполнение которых должно занять около 20 часов, поэтому их выполнение для каждого PR замедлит нас.

Это означает, что мы можем захотеть запускать их отдельно от нашего текущего CI, возможно, один раз в день. Однако это также не кажется хорошим решением, поскольку его будет сложно поддерживать. Скажите PRs A B и C объединитесь после прохождения CI, но B содержит изменение, которое приведет к снижению производительности. Мы узнаем об этом через 24 часа, а затем должны выяснить, какой коммит из 3 вызвал проблему. Итак, предположим, что это займет не менее одного дня, и найдите исправление для, B* . Но к тому времени были объединены еще 2 PR D E . Итак, у нас есть A - B - C - D - E - B* , который в идеале должен запускаться и устранять исходную проблему, вызванную B .

Но что, если D введено еще одно замедление производительности? Как бы мы определили B* , сработало ли это? Теперь у нас есть еще большая группа PR, которую нам нужно просмотреть для решения проблемы! Похоже, что объединение PR до того, как он пройдет эти тесты, не является хорошей идеей. Но это возвращает нас к первой идее, которая слишком медленная.

Как люди обычно автоматизируют длительные тесты как часть своего рабочего процесса?