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

На что стоит обратить внимание при выборе Continuous Integration для своего проекта

18 Aug 2014


Недавно на Хабрахабре была опубликована моя заметка “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, что там сложного, сейчас сами скриптик наваяем” – мне встречались достаточно часто, так что хочу на примере показать, чего скорее всего будет не хватать в простом “наколеночном” варианте.

MicroCI

Итак, пишем “свой маленький скриптик”. У меня получилось уложиться в 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, Jenkins, TeamCity, Travis CI.

Большой список есть в Википедии.

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

Удачного выбора!