Пару лет назад, когда я только начинал проектировать систему автоматического тестирования программного обеспечения, которое производит мой работодатель, я еще не знал такого понятия как "непрерывная интеграция" (wiki). Теперь, оценивая сделанное, я прихожу к выводу, что во многом (но не во всем) этой самой "непрерывной интеграции" удалось достичь. Далее я вкратце попытаюсь рассказать какими именно средствами это было реализовано...
Для сборки проекта используется кроссплатформенная система сборки CMake (взамен устаревших и более сложных в использовании Autotools), а также две другие утилиты из CMake-семейства: CTest и CDash.
CTest используется для прогона модульных и комплексных автотестов.
CDash для обработки, хранения и отображения результатов автоматических сборок (результатов работы CTest-а).
Для проведения автосборок и сеансов автоматического тестирования выделен отдельный сервер.
cron-настроен на проведение автоматических ночных сборок.
Результаты каждого ночного сеанса тестирования автоматически экспортируются в CDash(в xml-формате) для обработки , архивирования и возможности отображения и анализа в любой момент времени.
Так "система" работает сейчас. Но, как говорится, всегда есть к чему стремиться. Проведение ночных сборок хоть и повышает скорость реакции на "поломки" в коде, но иногда и такая скорость недостаточна.
Сейчас есть желание и потребность прогона сборки после каждого коммита в репозиторий. Проблема в том, что коммиты могут быть многочисленны в течение одного дня и прогонять весь набор тестов (модульных и комплексных) после каждого изменения может стать трудновыполнимой задачей. В связи с этим вижу 2 варианта решения проблемы:
1. После каждого коммита прогонять лишь модульные тесты, а полноценный сеанс автоматического тестирования запускать только по ночам.
2. Разделить критичные коммиты от некритичных (например с помощью тегов в комментариях к коммитам) и прогонять сборку только после критичных коммитов.
Реагирование на появление изменений в репозитории - не проблема. Можно использовать готовые и навороченные решения, либо обойтись собственными скриптами.
В общем, в ближайшее время задуманное будет реализовано.
Комментарии, вопросы, отзывы - милости прошу )
CI как раз предполагает запуск тестов на каждый коммит, конечно, такие тест должны идти не дольше 5 минут - всё, что дольше - в ночные запуски.
ОтветитьУдалитьВ этом и смысл CI - не пропускать в репозиторий коммитов, которые всё ломают.