Оценка доли поломанных билдов open-source проектов, использующих CI

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

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

Успешные и поломанные сборки

Назовем успешными сборками такие сборки, при которых проект был успешно собран и не было выявлено ошибок авто-тестами. Поломанными сборками назовем такие сборки, при которых были выявлены ошибки компиляции или авто-тестов. Для разных организаций и прикладных задач проценты успешных и поломанных сборок могут существенно отличаться, и общепринятых усредненных значений мне найти не удалось.

Я решил оценить процент успешных сборок, которые могли бы использоваться как ориентир. Для этого в качестве сервиса CI я выбрал проект Jenkins как наиболее популярный. Затем отобрал широко известные проекты с открытым кодом и с доступной CI Jenkins статистикой.

Для эксперимента разработал программу анализа статистики сборок, исходный код которой доступен на GitHub, после чего проанализировал полученные данные.

Результаты исследования

Усредненные (по сборкам) метрики

Усредненный процент поломанных сборок:

Усредненный процент успешных сборок:

Количество проанализированных сборок

Усредненный коэффициент вариации времени сборок

Выводы

— Уровень в 25% дефектных сборок является средним значением;
— 40% дефектных сборок встречается у большого числа проектов с открытым кодом;
— Можно предположить, что в более 10% случаев сборка занимает в 2 раза больше времени, чем в среднем.