GitLab CI/CD Pipelines: как настроить непрерывную интеграцию и доставку кода

Что такое CI/CD простыми словами

За аббревиатурой скрываются две отдельные вещи.

CI — Continuous Integration, непрерывная интеграция: автоматическая сборка и тестирование кода при каждом его изменении.

CD — Continuous Deployment, непрерывная доставка: автоматический деплой на нужную среду. Сред может быть несколько — тестовая, stage, production.

Общий цикл выстраивается так: идёт процесс разработки → код закоммичен в репозиторий → срабатывает событие (например, принят merge request) → по заданному алгоритму запускается конвейер этапов, который выполняет сборку, тесты и доставку.

Зачем это компании-разработчику

Четыре аргумента, которые стоит проговорить до начала внедрения.

1. Уменьшается количество ручных ошибок.Всё, что делалось руками на окружении, делает автоматика.
2. Ускоряется выпуск релизов.
3. Повышается стабильность продукта— как минимум за счёт автоматического тестирования внутри пайплайна.
4. Появляется единый процесс работы для всех.Разработчик, тестировщик и DevOps работают по одному и тому же сценарию, а не каждый по-своему.

Какой риск закрывается в первую очередь

Главный — ошибка, доехавшая до продакшена.

Раньше схема выглядела так: зайти на окружение, руками залить изменения, проверить, поступили ли они. Если на этом этапе вылетала критическая ошибка, продукт падал — и, как это обычно бывает, падал сразу на продакшене. Дальше по цепочке: клиент недоволен, у бизнеса теряется доверие к подрядчику, компания несёт репутационный ущерб. Хорошо, если только репутационный, — простой продукта нередко оборачивается ещё и финансовыми потерями.

Экономика: где именно теряются часы

Считать удобно на конкретном сценарии. Допустим, команда выпускает 5–6 коммитов с фиксами в течение двух часов. Без автоматизации на каждый из них тестировщику нужно зайти и проверить, а разработчику — зайти и триггернуть деплой.

Суммарно на такой ручной обвязке уходит порядка полутора часов рабочего времени. И это повторяется каждый раз. При этом настраивается конвейер единожды: путь создан — дальше всё идёт на потоке, и к вопросу больше не возвращаются.

Для подрядчика есть и прямой денежный эффект: не приходится возвращать неоплачиваемые часы за собственные промахи в релизе.

Что получает бизнес

• быстрый time-to-market;
• минимизацию рисков по ошибкам в релизе;
• непрерывный выпуск фич;
• интеграции и уведомления — если бизнесу важно знать, когда именно случился релиз;
• работу по расписанию: пайплайн можно повесить на планировщик и выпускать релиз, например, каждый вторник, забирая всё, что готово в нужной ветке;
• независимость от человеческого фактора — болезнь разработчика или лида больше не останавливает поставку.

Чем настраивать: обзор инструментов

GitLab — не единственный вариант. На рынке есть Jenkins, GitHub Actions, Bitbucket Pipelines, Bamboo, CircleCI, а при работе с зарубежной облачной инфраструктурой — Amazon Pipelines. У каждого свои плюсы и минусы.

Пример с Jenkins.Инструмент позволяет гибко кастомизировать всю доставку, а в репозитории плагинов их более двух тысяч. Но всё это нужно настраивать, и настройка выливается в отдельную штатную единицу — DevOps-инженера, который «вроде и нужен, а вроде и нет», в зависимости от проекта и его бюджета.

Отдельная головная боль Jenkins — обновления. За ветками безопасности приходится следить постоянно: критические патчи выходят чуть ли не раз в две-три недели. Доходит до того, что хостинг сам присылает письма о том, что ваш Jenkins небезопасен и его стоит либо обновить, либо убрать. У GitLab этой проблемы нет.

Откуда взялся GitLab

История короткая: был GitHub, один разработчик из Украины сделал для своих целей собственный репозиторий, понял, что получилась хорошая штука, и выложил её в open source. Позже, когда появился тот же Jenkins, команда решила интегрировать CI/CD внутрь своей системы — и получилась единая платформа, где репозиторий и конвейер живут вместе.

SaaS или коробка

GitLab существует в двух видах: как SaaS-сервис и как коробочное open-source решение, которое разворачивается на своих мощностях.

Второй вариант в текущих условиях особенно актуален: из-за санкционных ограничений на open-source и коробочные решения для работы с кодом перешли многие крупные российские компании, включая коммерческие банки.

Порог входа ниже, чем принято думать. При покупке VPS у некоторых хостингов можно выбрать предустановленный GitLab — он разворачивается буквально за несколько минут. Дальше нужно настроить права и ограничить доступность сервиса доменным именем. По оценке из эфира, рабочая конфигурация с хорошими мощностями обходится примерно в 50 рублей в день.

Пайплайн: из чего он состоит

Pipeline— это набор инструкций и этапов, которые выполняются при интеграции и деплое кода. Выполняются они в определённом порядке: сначала билд, затем тестирование, затем деплой.

При этом порядок не обязан быть строго линейным. Если есть зависимость — например, в рамках тестирования или сборки, — можно сначала выполнить её, потом вернуться к общему тесту и уже затем деплоить. Шаг вперёд, шаг назад, снова вперёд.

Сам пайплайн формируется конфигурационным файлом —.gitlab-ci.yml, написанным на YAML. Его ключевые элементы:

Зачем здесь Docker

Чтобы собрать билд, нужна среда, в которой всё соберётся: на фронтенде это npm, в PHP — Composer, в Ruby и Python — свои менеджеры пакетов. Docker даёт эту среду.

Работать можно двумя способами: подтягивать готовые образы (через docker-compose) или описывать свои через Dockerfile. В базовом сценарии в конфигурационном файле просто указывается нужный образ — Node определённой версии, PHP 8.2 или облегчённый Linux вроде Alpine.

Кто отвечает за конфигурационные файлы

На одном из проектов между бэкенд-разработчиком и DevOps-инженером заказчика возник спор ровно об этом: чья это зона ответственности.

Позиция, прозвучавшая в эфире, двухслойная.

С одной стороны, любой разработчик должен иметь хотя бы минимальные объективные знания, чтобы оформить конфигурацию для CI/CD. Задача упаковать требования к собственному коду — довольно тривиальная, и по матрице скиллов её вполне можно спускать ниже уровня лида. Это прямой способ сокращать издержки на повседневную работу.

С другой — если говорить о выстроенных процессах и координации внутри команды, такие вещи лучше делегировать на уровень лида. Причина не в сложности, а в ответственности: спрос за конвейер доставки выше, и требовать его с рядового разработчика — значит требовать за пределами его зоны ответственности.

GitLab Runner: рабочий на конвейере

Конфигурационный файл описывает, что делать. Runner — то, что это выполняет.

Метафора из эфира точная: на конвейере, даже полностью автоматизированном, должен быть хотя бы один рабочий, который контролирует процесс. GitLab Runner отвечает за выполнение задач, описанных в пайплайне.

Зачем он нужен:

• Автоматизация и автозапуск.Пайплайн стартует сам по событию.
• Масштабируемость.Несколько раннеров обрабатывают большое количество задач параллельно и на разных проектах. Масштаб бывает впечатляющим: у компаний уровня Netflix и Google количество деплоев за день доходит до полутора тысяч.
• Изоляция.Задания запускаются в изолированной среде — на отдельном сервере, в Docker-контейнере или виртуальной машине, — чтобы не возникало конфликтов.
• Гибкость.Раннер работает и с локальными, и с облачными серверами, и с контейнерами, адаптируясь под разные задачи.

Регистрируется раннер просто: в общих настройках генерируется новый, дальше конфигурация зависит от среды выполнения — это может быть shell, а может быть Docker-образ. Вариант с образом удобен тем, что постоянно активный раннер обеспечивает непрерывную доставку кода на проект без ручного вмешательства.

Отдельный плюс GitLab, отмеченный в эфире, — обширная и понятная документация. С оговоркой, которая стоит того, чтобы её привести: спросить у нейросети быстрее, но понимания это не даёт. Разобраться, как всё работает на самом деле, получается только через практику.

Переменные и безопасность

Хранить доступы к продакшену прямо в конфигурационном файле — плохая практика. Для этого в GitLab есть переменные: их можно задавать на уровне проекта и разделять для защищённых и незащищённых веток.

Это тот случай, когда правильная настройка занимает пять минут, а её отсутствие однажды стоит очень дорого.

Сколько это стоит по времени

Вопрос, из-за которого внедрение чаще всего откладывают.

• Если человек уже разбирается— GitLab CI/CD настраивается за пару часов.
• Если разбираться с нуля, изучая документацию— порядка 5–6 часов.

Инвестиция разовая. Инфраструктура переиспользуется: один сервер под репозиторий, другой под пайплайны — и дальше запускается любой продукт из репозитория. Меняется от проекта к проекту в основном конфигурационный файл внутри самого проекта, потому что у каждого проекта свой инструментарий. Общая последовательность этапов остаётся плюс-минус одинаковой.

Что происходит на рынке

Конкуренция в инфраструктурных решениях заметно растёт. МТС выпустила контейнерную платформу для управления Kubernetes-кластерами с автоматизацией ключевых процессов CI/CD, обновления, масштабирования и контроля — по их данным, загруженность команд снизилась на 40%. Похожие направления развивают Selectel и другие хостинг-провайдеры, анонсируя кластеризацию. Yandex Cloud давно присутствует на рынке и, по опыту команды, показывает себя стабильно.

Итог

Соберём рецепт целиком:

1. Берём платформу для репозитория.GitLab удобен наличием коробочной версии, которую можно развернуть self-hosted за считанные минуты на предустановленном решении хостинга.
2. Поднимаем отдельный VPS под пайплайны, которые будут выполнять доставку.
3. Описываем конфигурационный файл в проекте: Docker, версии и зависимости приложения, порядок запуска команд, джобы.
4. Регистрируем и запускаем Runner, отслеживая его активность.

Дальше экосистема работает как единое целое. Подрядчик получает качественный сервис и предсказуемую поставку с минимальными рисками и издержками; бизнес — быстрый time-to-market, прозрачное информирование о стадии релиза и непрерывный выпуск фич.

Нет ни одного инструмента, который можно взять и использовать сразу без настройки, — какое-то время на интеграцию уйдёт. Но выигрыш в стабильности и экономии ресурсов кратно превышает эти затраты.

Материал подготовлен по видео We Wizards «Как создавать и работать с GitLab CI/CD Pipelines».