Сборка ломается в пятницу вечером, и никто не знает, чей коммит виноват. Знакомая картина для команд, которые собирают релиз вручную раз в месяц. Непрерывная интеграция убирает эту неопределённость: каждый коммит уходит в общий ствол, сервер тут же собирает проект и прогоняет тесты. Сломанную сборку находят за минуты, а не за недели. Jenkins (бывший Hudson) – самый практичный инструмент для этого на середину 2012 года: открытый код, сотни плагинов, живое сообщество и низкий порог входа.

Что делает Jenkins на практике

Jenkins следит за репозиторием – Subversion, Git, Mercurial и реагирует на изменения. Можно опрашивать SCM по расписанию (H/5 * * * *) или повесить post-commit hook, чтобы сборка стартовала сразу после коммита. Дальше сервер выполняет шаги задания: достаёт исходники, вызывает Maven, Ant или обычный shell-скрипт, собирает артефакт и публикует результаты.

Ценность не в самой сборке, а в обратной связи. Jenkins показывает тренд по тестам, сохраняет историю сборок, рассылает уведомления по почте и Jabber тем, кто сломал ствол. Плагин Cobertura или Emma строит отчёт по покрытию, Checkstyle и FindBugs ловят типовые дефекты статическим анализом. Команда видит состояние проекта на одном дашборде, без ручных опросов «у всех собирается?».

Для крупных проектов один сервер быстро упирается в потолок. Архитектура master/slave разносит сборки по нескольким машинам: мастер раздаёт задания, агенты выполняют. Так мы параллелим прогон тестов и держим отдельные узлы под разные платформы – например, отдельный slave под Windows-сборку.

Конвейер без боли: дисциплина важнее тулинга

Сам по себе Jenkins проблему не решит. Работают несколько простых правил.

  • Быстрая сборка. Основное задание должно укладываться в 10 минут, иначе разработчики перестанут ждать результат. Долгие интеграционные и нагрузочные тесты выносите в отдельное ночное задание.
  • Зелёный ствол – приоритет. Сломанную сборку чинят прежде новых задач. Это вопрос дисциплины, а не плагина.
  • Один артефакт на все среды. Собрали один раз – тот же .war или .jar уезжает на тест, в предпрод и в продакшн. Пересборка под каждую среду плодит расхождения.
  • Воспроизводимое окружение. Версии JDK, библиотек и зависимостей фиксируйте явно. Maven-репозиторий вроде Nexus спасает от «а у меня собиралось».

Непрерывная интеграция – фундамент для следующего шага: автоматизации развёртывания. Когда сборка стабильна и даёт проверенный артефакт, тот же конвейер доводит его до боевых серверов одним кликом. А чтобы агенты разворачивались быстро и предсказуемо, виртуализацию и сеть стоит готовить заранее – здесь помогают подходы из области программно-конфигурируемых сетей.

Что это даёт бизнесу и госсектору

Для заказной разработки CI – это снижение риска. Дефекты находятся на дне внесения, а не на приёмочных испытаниях. Релизный цикл становится предсказуемым, что критично при работе по госконтракту с жёсткими сроками сдачи этапов. Аудит сборок и история артефактов закрывают требования к прослеживаемости: видно, какой коммит попал в какую поставку.

Такой конвейер выстраивается в ходе разработки бизнес-систем под госконтракт и корпоративные задачи: от настройки Jenkins и репозитория зависимостей до интеграции с системой отслеживания задач. Подход универсален: он одинаково дисциплинирует и сборку веб-приложений, и более тяжёлые системы – например, инфраструктуру потокового видео.

Начните с малого: один проект, одно задание, зелёный ствол как правило команды. Через месяц вы перестанете бояться пятничных релизов.