Практика непрерывной интеграции

Непрерывная интеграция (continuous integration) в разработке ПО означает процесс непрерывного применения контроля качества. Целью является повышение качества ПО и уменьшение времени на реализацию процедур по повышения качества.

В основе своей содержит понятие сборки и регулярную проверку различных метрик кода.
Я использую (в порядке внедрения в проект) в проектах на java:
* Компилируемость кода. Весь код должен компилироваться. Всегда. Избавляет от вопросов "Сейчас в svn неработающий код, что мне делать?" и заявлений "Я не хочу обновляться, так как наверняка там код неработающий"
* Отсутствие замечаний Findbugs. Тут случай, когда машина работает за человека и отлавливает множество глупых ошибок по невнимательности. Классическая и самая у нас часто встречаемая: появление неиспользуемых переменных. Обычно означает, что написали часть кода, вычислили значение и забыли его использовать. У Findbugs бывают ложные срабатывания, но их не так много если использовать только определенные проверки
* Прохождение junit тестов. Наличие тестов позволяет разработчикам быстрее принимать решение по внесению изменений. Они их просто делают и смотрят, не сломались ли тесты. Практика показывает, что нереально выполнять все тесты на машине разработчика. Лучше иметь единое место, где гарантированно выполняться все тесты. Также количество тестов должно расти.
* Процент покрытия кода тестами. Плюс в том, что можно вести 1 число, и его сможет отслеживать кто угодно, даже не разработчик. Минус в том, что обосновать это число (у нас 75%) невозможно, и отдача наступает через долгие месяцы. Но наступает.
* Отсутствие комментариев TODO. Придерживаюсь правила, что в норме в коде не должно быть TODO. Нормально, если они появляются во время итерации, но затем должны быть безжалостно изведены под 0, либо фактическим исправлением, либо фиксацией issue в багтрекере либо в честном признании, что его никогда не исправят и его удалении. Видел проект с тысячами TODO, уже с неприличными комментариями к ним, которые никто не исправлял, они только расстраивают разработчиков.

Также в процессе непрерывной интеграции получаются ряд метрик и артефактов проекта
* Версия модулей. Из этих модулей можно собирать тестовые стенды. Экономится куча времени.
* Количество строк кода. Видно, как меняется проект. Но трактовать количество строк кода надо очень осторожно
* Время сборки. С ростом сложности проекта периодически приходиться наращивать мощь сервера непрерывной интеграции.


Преимущества
* Раннее обнаружение ошибок. Многие разработчики мне часто говорят "Я не помню, что делал вчера, мне надо посмотреть историю изменений". В в проектах с внедренной непрерывной интеграции применительно к ошибкам сборки они этого не говорят, так как время обнаружения от 3 минут до 1 часа. Никто не хочет сознаваться, что не помнит, что делал 5 минут назад
* Если настройка проекта сложная, то не надо запускать и настраивать среду разработки под проект. Прямо в системе непрерывной интеграции можно смотреть изменения, так как они маленькие, то просто догадаться, что надо исправить и кому следует исправить.
* Эталонная работающая система сборки. Если вы принимаете решение выкатывать релиз заказчику вы не потратите неделю на то, чтобы систему собрать. Для нас актуально, так как система сборки для разработчиков и для деплоя различается.
* Возможность тестирования в различных окружениях и конфигурациях. У разработчика настроена 1 конфигурация, на сервере непрерывной интеграции их несколько.
* Можно автоматически создавать техническую документацию по проекту (javadoc, отчет по используемым библиотекам, по покрытию тестами, по замечаниям Findbugs и т.д.)
* Метрики подключаются достаточно быстро, бывают достаточно 5 минут (например столько ушло на включение в проект проверки на количества TODO)

Недостатки
* Надо потратить время на внедрение системы непрерывной интеграции, подбор инструментария. Практика показала, что на первое внедрение могут быть затрачены недели, на следующее всего пара дней.
* Нужен человек, которому надо, чтобы система непрерывной интеграции работало. Все соглашаются, что неработающий код - это плохо, но ничего не делают. На практике люди самостоятельно начинают исправлять замечания через порядка 1 год использования системы
* Нужен выделенный сервер. Из хорошего - это может быть дохлая машина с 1-2 Гб памяти.

Инструменты (в порядке внедрения)
* скрипты на bash, python + ant
* Hudson + ant
* Hudson + maven

Примерные сроки и затраты на внедрение
* Проверка компилируемости. Скрипт + cron + email. Примерно неделя. С удивлением обнаружил, что часть модулей не компилируется, какие-то починены, какие-то отправлены в архив. Несколько месяцев на внедрение в сознание разработчиков мысли, что код должен компилироваться всегда, а не только в момент сборки для клиента
* Проверка findbugs. В проекте было порядка 3000 замечаний. Примерно неделя ушло на встраивание ant задачи проверки и неделя на зачистку замечаний. После этого год жили с проверкой компилируемости и замечаний findbugs, реализовано на скриптах
* Hudson. Неделя на настройку. Дал историю сборок, хранение логов сборки и доступ через http. Позволил не запускать GUI оболочку Findbugs для нахождения места с замечанием.
* Junit. Примерно календарный месяц ушел на изучение литературы по шаблонам тестирования xUnit, на написание первых десятков тестов, на встраивание вызова тестов на стенд и визуализацию результатов в Hudson. При этом потрачено порядка 2 недель времени.
* Покрытие кода тестами с помощью Cobertura. Ушло календарных 2 недели. Одна сборка c участием Cobertura занимала десятки минут, отладка настройки шла ужасно долго. Потрачено реально пара дней. Позволила искать места, не покрытые тестами.
* Использование maven. За несколько дней был настроен maven проект со все необходимым. Попутно получили возможность создания документации по проекту, оставили лишь нужные отчеты.
* По моей экспертной оценке в начале внедрения надо тратить порядка 0.5-1 ч в день ведущему разработчику, чтобы устранять замечания или искать виноватого. Попутно он лучше узнает код других. В дальнейшем ошибок становиться меньше и люди исправляют замечания самостоятельно.