Continuous Integration в 10 строках кода или зачем нужны BuildBot, Jenkins, TeamCity и подобные

Заметка рассчитана на тех, кто уже знает, что такое Continuous Integration, но еще не выбрал, какую именно систему внедрить у себя.

Почитать, что такое CI и зачем его использовать, можно в Википедии и здесь же на Хабре: статья 1, статья 2, тег CI.

А я расскажу, на что стоит обратить внимание при выборе CI для своего проекта, почему стоит использовать готовую стороннюю систему и не стоит ввязываться в написание собственного «велосипеда».


Началось с того, что в одной IT-компании случился такой разговор между коллегами из соседних отделов:

K1: У вас continuous integration есть?
K2: Есть, запускаются тесты на каждый коммит в транке.
К1: На чем работают?
К2: Собственный скрипт. Сейчас переходим на Buildbot.
К1: Может я чего-то не понимаю, но что там сложного? Апнуться, запустить тесты, отправить результат, зачем какой-то Buildbot, проще же самим написать?

Подобные рассуждения — «да зачем какое-то сторонее continuous integration, что там сложного, сейчас сами скриптик наваяем» — мне встречались достаточно часто, так что хочу на примере показать, чего скорее всего будет не хватать в простом «наколеночном» варианте.

Итак, пишем «свой маленький скриптик». У меня получилось уложиться в 10 строк, включая shebang, задание в кронтабе и настройку отправки писем.

Скрипт micro_ci.sh, не забыть сделать файл исполняемым:

#!/bin/sh
cd /tmp/micro_ci/wc && mkdir /tmp/micro_ci/lock || exit 2
rev=`svn info |grep 'Last Changed Rev' |sed 's/.*: *//'`
svn up
if test `svn info |grep 'Last Changed Rev' |sed 's/.*: *//'` = $rev ; then rmdir /tmp/micro_ci/lock ; exit 0 ; fi
make test || status=$?
rmdir /tmp/micro_ci/lock
exit $status


Создать каталог /tmp/micro_ci, в /tmp/micro_ci/wc зачекаутить проект.

Файл /etc/cron.d/micro-ci:
MAILTO=project-tests@company.ru
*/10 * * * * tests /path/to/micro_ci.sh


Готово! Несмотря на игрушечный размер, эта «MicroCI» может работать и приносить пользу.

И естественно, ей очень многого не хватает в сравнении с «взрослыми» системами. Посмотрим поподробнее.

Разные сборки

Поведение MicroCI (строка 6 в скрипте): ровно один вид «сборки» — make test (или иное, что захардкожено в скрипте).

Желательное поведение: возможность настроить разные виды билдов, которые запускались бы независимо или последовательно друг за другом (смоук-тесты, юнит-тесты, сборка артефактов для выкладки и т.д.)

Работа с репозиториями

Поведение MicroCI (строки 3-5 в скрипте): работа ровно с одним svn-репозиторием — тем, из которого зачекаучена рабочая копия /tmp/micro_ci/wc.

Желательное поведение: возможность легко настроить билды для нескольких репозиториев, в том числе в разных VCS (svn, git, mercurial и т.д.)

Работа с ветками (бранчами)

Поведение MicroCI (строка 4 в скрипте): работа ровно с одной веткой — той, что зачекучена в рабочую копию /tmp/micro_ci/wc.

Желательное поведение: возможность запускать тесты и сборки на некоторых или всех бранчах в репозитории.

Расписание сборок

Поведение MicroCI (строка 2 в кронтабе): запускается раз в 10 минут и пытается получить обновления из репозитория.

Желательное поведение — разнообразные варианты расписаний, в том числе разные для разных билдов:
  • на каждую ревизию;
  • по таймеру;
  • еженочно;
  • при изменении определенных «интересных» файлов;
  • и т.п.


Распределенная работа

Поведение MicroCI (строка 2 в скрипте): запускается ровно на одной машине, в одной и той же рабочей копии, никакой параллельной работы не предусмотрено.

Желательное поведение: возможность параллельных сборок в разных воркерах-билдерах, запуск воркеров на разных серверах (для распределения нагрузки и для проверки работы на разных архитектурах/ОС).

Метод доставки уведомлений

Поведение MicroCI (строка 1 в кронтабе): результаты всех запусков отправляются по электонной почте на один адрес.

Желательное поведение: доставка уведомлений на разные email-адреса, а также через jabber, irc, sms, rss — все, что удобно.

Формат уведомлений

Поведение MicroCI (строка 1 в кронтабе): в письма попадает весь вывод сборки, и ничего больше.

Желательное поведение: адаптивные уведомления (разные для успешных и неуспешных сборок) с комментарием о самой системе запуска тестов и ссылками на веб-интерфейс.

Условия отправки уведомлений

Поведение MicroCI (строка 1 в кронтабе, строка 6 скрипта): письма отправляются после каждого прогона тестов.

Желательное поведение — возможность гибко настраивать условия отправки уведомлений:
  • при каждом запуске;
  • при неуспехе;
  • при доле проваленных тестов выше определенного порога;
  • при смене состояния сборки: при первом неуспехе после череды успехов и при первом успехе после полосы провалов;
  • об успехе отсылать уведомление только на общую рассылку, о неуспехе — дополнительно автору проблемного коммита.


Очистка рабочей копии между запусками

В MicroCI отсутствует.

Если сборка порождает новые файлы в рабочей копии, они должны автоматически удаляться перед следующим запуском.

Принудительный перезапуск тестов на определенной ревизии

В MicroCI отсутствует.

Желательное поведение: возможность перезапустить тесты на одной из прошлых ревизий — на случай, если кажется, что сборка упала из-за временных особенностей окружения.

Интегрируемость с другими интранет-сервисами

В MicroCI отсутствует.

Желательное поведение — возможность простой интеграции с другими инструментами, используемыми в команде: мониторингом, системой обмена сообщениями, вики, внутренним блогом и т.п.

«Предварительная» сборка

В MicroCI отсутствует.

Желательное поведение: можно до коммита загрузить в систему CI патч, система сама наложит его на код проекта и запустит все необходимые сборки и проверки. Это особенно полезно, если тесты выполняются под разными архитектурами или версиями ОС, и запуск их самим разработчиком затруднен.

У TeamCity этот режим называется Remote Run, у Buildbot-а — trial builds, у Jenkins-а есть Patch Parameter Plugin.

Собственный веб-интерфейс

В MicroCI отсутствует.

Желательное поведение: у системы CI есть свой собственный веб-интерфейс, в котором можно посмотреть историю сборок, статистику и т.п.

Лицензия, opensource

Удобно, когда система CI распространяется под свободной лицензией, и при необходимости в ее код можно внести собственные правки.

Язык, на котором написана CI

MicroCI написан на shell-е, это очень компактно, но очень неудобно для дальнейшего развития программы.

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

Заключение


Конечно, у нашей MicroCI есть и достоинства: она очень, очень простая, «установка» тривиальная, не требуется никакого стороннего ПО. Но если в реальном проекте попытаться использовать ее или подобную самостоятельную разработку, рано или поздно придется реализовать все или практически все перечисленные выше фичи. Готовы ли вы к этому? Если не уверены — берите сторонюю CI и не добавляйте себе работы по развитию нового вспомогательного проекта в дополнение к основному.

Ну и напоследок — некоторые популярные системы CI: Atlassian Bamboo, Buildbot, CruiseControl (вычеркнут как остановившийся в развитии), Jenkins, TeamCity, Travis CI (для публичных репозиториев на github).
Большой список есть в Википедии.

Если в обзор не попали еще какие-то важные и полезные фичи CI — пишите в комментариях.

Удачного выбора!
Поделиться публикацией

Похожие публикации

Комментарии 11
    +4
    Еще артефакты сборки хорошо б отдавать куда-то дальше. так пока это даже не ci, a ct
      +1
      Хм, спасибо. CI — действительно неплохая штука.

      С другой стороны посмотрев по вашим пунктам на когда-то написанный мой «скрипт» — поставил к ему все плюсики. Получается, на Shell/Python получился полноценный CI у меня, согласно вашей классификации. Однако его плюс — заточенность под специфику проекта.

      А вот когда мы его переносили (по сути — «дружили») с Buildbot и Jenkins, внезапно оказалось, что функционала их нам не хватает — и тогда и их пришлось допиливать, но уже, к счастью, на базе готового скрипта — это сократило effort, хотя ещё добавилось время на разборку CI internals. Я это к тому, что помимо плюсов готовых систем — у них есть и минусы — они не универсальны и при сложных вариантах использования их надо пилить напильником, что может потребовать разборок со внутренностями CI.
        +2
        Получается, что в условии "… реализовать все или практически все перечисленные выше фичи. Готовы ли вы к этому?" ваш проект пошел по ветке «да, готовы» ^_^

        Интересно, какие у васт остались впечателения от допиливания Buildbot и Jenkins. Насколько они к этому пригодны? Оба одинаково удобны/неудобны, или есть существенная разница?
          0
          С моей точки зрения Jenkins был более перспективен и нагляден, однако, всё пошло по пути допиливания Buildbot'a, т.к. у меня в команде не было Java'истов, и никто не горел желанием изучать Java, в отличие от Python'а. Плюсов в сторону Buildbot'a стало так же поддержка коммьюнити — его использовали не только мы, и, фактически, мы могли брать чужую инфраструктуру и проекты с наименьшими затратами использовать их у себя.

          Т.е. с моей точки зрения в Jenkins уже входит интеграция с багтрекерами и красивые отчёты. Buildbot более спартанский, но в нашем случае это не сыграло роли, т.к. недостающие куски у нас уже были для экспорта в redmine и экспорт в html\excel. В случае с Jenkins мы должны были бы переписывать недостающий код на Java (отчёты, система внутренних ключей, обновлялок и нотифаеров).

          Увы, до окончательной реализации всех моих желаний и хотелок не дошло — проект свернули — думаю тогда сказал бы более конструктивно.
        0
        Еще один простой CI github.com/cpjolicoeur/cerberus
          0
          CruiseControl — «популярные системы CI»? Там последний апдейт был в 2010 году. Это уже не CI, а история.
          Впрочем, он после смерти переродился в продукт Go — но который ужасен, и я его ни в коем случае не советую.
            0
            Мда, пожалуй, подзаброшенный проект. А вы что записали бы в шорт-лист?
              0
              Travis-CI же! Пусть и только для публичных проектов.
                0
                Пожалуй, так. А то, что это хостинг-сервис, а не коробочный продукт — так это даже разнообразнее получается.
                0
                Т.к. я преимущественно из мира Java и JS, то, имхо, это Jenkins и TeamCity.
                0
                На удивление супер прост и работает, недавно даже подпилил какой то гем и мигрировал на руби2
                Использую для одного проекта на рубях

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое