Недавно на Хабрахабре была опубликована моя заметка “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 есть свой собственный веб-интерфейс, в котором можно посмотреть историю сборок, статистику и т.п.
Удобно, когда система CI распространяется под свободной лицензией, и при необходимости в ее код можно внести собственные правки.
MicroCI написан на shell-е, это очень компактно, но очень неудобно для дальнейшего развития программы.
Если вероятно, что вы будете вносить правки в код CI, писать для нее плагины и модули, то при прочих равных условиях стоит выбирать удобный и мощный язык программирования, в котором у вас уже есть хорошая экспертиза.
Конечно, у нашей MicroCI есть и достоинства: она очень, очень простая, “установка” тривиальная, не требуется никакого стороннего ПО. Но если в реальном проекте попытаться использовать ее или подобную самостоятельную разработку, рано или поздно придется реализовать все или практически все перечисленные выше фичи. Готовы ли вы к этому? Если не уверены – берите сторонюю CI и не добавляйте себе работы по развитию нового вспомогательного проекта в дополнение к основному.
Ну и напоследок – некоторые популярные системы CI: Atlassian Bamboo, Buildbot, Jenkins, TeamCity, Travis CI.
Большой список есть в Википедии.
Если в обзор не попали еще какие-то важные и полезные фичи CI – пишите в комментариях.
Удачного выбора!