Непрерывная интеграция (continuous integration) — это очень, очень хорошо. Вы настраиваете ее один раз, и ваши волосы моментально становятся гладкими и шелковистыми. В этой заметке будет показано, как просто происходит установка и настройка системы непрерывной интеграции Jenkins.
Некоторые плюсы использования Jenkins:
- Когда кто-то ломает билд, вы узнаете об этом сразу, что позволяет быстро устранить проблему;
- Вы можете автоматизировать прогон тестов , деплой приложения на тестовый сервер, проверку code style и тому подобные вещи;
- Также в Jenkins можно хранить собранные deb-пакеты, отчеты о прогоне тестов, и документацию на Javadoc или Doxygen ;
Допустим, у нас есть сервер под управлением Ubuntu Linux. Говорим:
Поздравляю, Jenkins установлен, можно ломимся на порт 8080:
Давайте попробуем настроить автоматическую сборки библиотеки task_queue . Для этого на сервере нам также понадобятся Git , Rebar и Erlang :
Жмем «Manage Jenkins» → «Manage Plugins» → «Available». Количество доступных плагинов впечатляет, да? Нам понадобится Git Plugin из раздела Source Code Management. Отмечаем его галочкой и жмем «Install without restart». Ждем завершения установки плагина и его зависимостей.
Далее жмем «New Job». В поле «Job Name» вводим «task_queue», выбираем пункт «Build a free-style software project», жмем «OK». В блоке «Source Code Management» выбираем «Git», в качестве URL репозитория вводим:
В качестве имени бранча для сборки вводим «master». В блоке «Build Triggers» выбираем «Poll SCM». В появившимся поле «Schedule» вводим:
Этим мы говорим Jenkins забирать ветку master из репозитория каждые пять минут и, если в ней что-то изменилось, пытаться собрать билд.
В блоке «Build» нажимаем «Add build step» → «Execute shell». В поле «Command» вводим команды, необходимые для сборки проекта. В нашем случае это будет просто команда make
.
В блоке «Post-build Actions» жмем «Add post-build action» → «E-Mail notification». В появившимся текстовом поле вводим свой e-mail. На него будут приходить уведомления в случае, если не удастся собрать билд.
Наконец, нажимаем «Save». Ждем пять минут, пока Jenkins не соберет проект самостоятельно, или нажимаем «Build Now». В моем случае сборка не удалась. Обычно выяснить причину провалившейся сборки можно в «Console Output».
Заходим на сервер, где был поднят Jenkins, и от имени юзера jenkins говорим:
git config —global user.email jenkins @ example.ru
dialyzer —build_plt —apps erts kernel stdlib mnesia
Теперь билд должен успешно собраться, что будет обозначено синим кружочком напротив имени проекта вместо красного. Открыв Workspace проекта, можно посмотреть автоматически сгенерированный отчет о прогоне тестов в файле logs/index.html. С тем же успехом можно генерировать документацию к коду и тп.
Я подозреваю, что вам захочется настроить еще некоторые вещи. Например, посылка e-mail уведомлений скорее всего так просто не будет работать. Вам придется указать SMTP-сервер и параметры подключения к нему в «Jenkins» → «Manage Jenkins» → «Configure System» → «E-mail Notification». Наверняка вам захочется ограничить доступ к Jenkins, так как через него можно выполнять любые команды в системе от имени пользователя jenkins. Возможно, вас бесят синие кружочки и вместо них вам хотелось бы использовать зеленые — для этого есть плагин. Но эти и другие вопросы (автоматический деплой проекта, слейв-ноды, построение графиков с количеством warning’ов при компиляции кода) уже выходят за рамки заметки.
А вы с коллегами используете Jenkins?
Дополнение: Непрерывная интеграция с GitHub Actions