Короткая демонстрация использования GitLab CI с целью показать, что настройка CI – это просто.

(5 мин текста, 10 мин демо)

Сегодня уже никого не удивить темой CI. Да и трудоемкая, тонкая, хрупкая настройка какого-нибудь выделенного CI сервера под конкретный проект уже тоже отходит в прошлое, когда “поднять CI” было прям “подвигом” каким-то. Про само понятие Continuous Integration мы говорить сейчас не будем, если кто еще не знаком с этим, то ожидайте отдельной статьи. Давайте лучше бегло пройдемся по одному из вариантов простейшей настройки CI на проекте, ради эффекта “лучше один раз увидеть”, даже если останется куча вопросов :). Ну, и сразу стоит раскрыть главный секрет этой простоты – это замечательный программный комплекс GitLab. Это open source проект, который интегрирует в себя очень много элементов разработки ПО: code repository, issue tracking, task planning, time tracking, project wiki, etc. GitLab поставляется в двух вариантах: CE (Community Edition) и EE (Enterprise Edition). EE вариант содержит закрытые расширения к CE и, соответственно, является платным решением. GitLab можно развернуть у себя в корпоративной среде (on-premise) или можно воспользоваться SaaS решением по аналогии с GitHub. Ладно, хватит про GitLab, ну, или самое уж последнее… он содержит встроенное CI решение! Мы в нашей компании активно используем GitLab и его CI, ибо это сильно упрощает многие моменты в разработке ПО. Установка и настройка GitLab CI – это отдельная тема, давайте вернемся к обещанному примеру…

Давайте создадим минимальный проект и включим техническую сторону CI для него.

Итак, для сборки быстренько подключим Gradle:

Теперь подключим GitLab repository:

Создаем простейшее веб приложение с использованием микрофреймворка Ratpack:

Надо бы какие-то тесты добавить, и для этого вынесем логику в отдельный юнит:

Хорошо, проект собирается, тесты проходят. Давайте-ка запускать весь этот процесс на нашем GitLab CI. Для этого достаточно добавить один файл, “.gitlab-ci.yml”. У нас есть shared GitLab CI runner, который настроен для запуска сборки в Docker контейнере (docker executor), т.е. в нашем случае мы возьмем за основу openjdk image:

Вот и все! Мы больше времени потратили на создание самого проекта, чем на настройку CI.

Этого примера должно быть достаточно, чтобы показать насколько простой может оказаться настройка CI. Ну, а дальше уже все зависит от вашей команды, т.е. будете ли вы следовать практике Continuous Integration или нет 😉

В следующей части мы продолжим тему CI/CD, в частности затронем топик так называемой докеризации (dockerization) приложения. Stay tuned!

Исходный код примера: https://gitlab.in6k.com/ihoro/example/tree/part1