Заметка рассчитана на тех, кто уже знает, что такое 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.
Большой список есть в Википедии.
Если в обзор не попали еще какие-то важные и полезные фичи CI — пишите в комментариях.
Удачного выбора!
Автор: liruoko
