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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дивий заголовок, незрозумілі висновки. 25% коду написаного програмістами йде в смітник, в деяких 40% і то не факт , час зборки коду напевне залежить від розмаху проекту.

Считаю, что анализ должен быть плацебо-контролируемым. Где данные по Hello, world!

Интересній анализ, а еще бы интересно отценивать уровень квалификации команды в зависимости процента красных билдов, а так же зависимость конкретных технологий и процента красных билдов)

Очевидно же, что на go было бы меньше всего поломанных билдов.

на жаль Дженкінс такої інфи не надає.
Проте можно взяти дані про використані мови программування

було б цікаво глянути, що там на комерційних проектах .. і порівняти.

В нас так само, коливається від 20% до 30%, blog.collaborator.com.ua/?p=417

Подписаться на комментарии