CI / CD — это просто.

///

чать 1

Сегодня уже никого не удивить темой 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

Дополнительно почитать:

https://habr.com/ru/company/otus/blog/515078/

Previous Story

SSL certbot Let’s Encrypt

Next Story

Prometheus

Latest from Blog

Port Knocking в Linux

Безопасность — это всегда компромисс между многими показателями, включающими, в том числе, удобство пользования. Современные реалии

BGP Mikrotik

Настройка интерфейса BGP Разберемся как настроить BGP на маршрутизаторах Микротик, допустим нам нужно анонсировать сеть 212.45.0.0/24, наша

VLAN switching на устройствах Mikrotik

Многие устройства Mikrotik имеют чипы коммутации, которые позволяют выполнять VLAN коммутацию на аппаратном уровне. Поэтому, для

HotSpot на Mikrotik c маркетингом

Если смотреть на реалии сегодняшнего дня, то почти у каждого посетителя имеется мобильный гаджет, который подключаются

0 £0.00