GitLab CI/CD за один день: от основ до автоматизированного пайплайна

Непрерывная интеграция и доставка (CI/CD) стали неотъемлемой частью современной DevOps-культуры, а GitLab предлагает мощное встроенное решение, которое позволяет автоматизировать весь путь кода от коммита до продакшена. Освоить основы GitLab CI и создать свой первый рабочий пайплайн можно всего за один день. Эта статья проведет вас через ключевые концепции и практические шаги, чтобы к вечеру у вас была работающая автоматизация.

В основе GitLab CI лежит файл `.gitlab-ci.yml`, который вы размещаете в корне репозитория. Этот файл на языке YAML описывает весь процесс сборки, тестирования и развертывания — пайплайн. GitLab автоматически обнаруживает этот файл и начинает выполнение заданных jobs при каждом пуше в репозиторий. Первым делом создайте новый проект в GitLab или используйте существующий. В корневой директории создайте файл с именем `.gitlab-ci.yml`.

Давайте разберем базовую структуру этого файла. Пайплайн состоит из стадий (stages), которые выполняются по порядку. Типичные стадии: `build`, `test`, `deploy`. Внутри каждой стадии определяются задания (jobs). Каждое задание — это независимый набор инструкций, которые выполняются в среде runner (исполнитель). Runner — это агент, который берет задания из очереди GitLab и выполняет их. Это может быть shared runner, предоставляемый GitLab.com, или ваш собственный, установленный на вашем сервере.

Начнем с простейшего пайплайна для Node.js приложения. Откройте `.gitlab-ci.yml` и добавьте:

stages:
 - test

unit-tests:
 stage: test
 image: node:16-alpine
 before_script:
 - npm install
 script:
 - npm test

Разберем каждую часть. Мы определили одну стадию `test`. Затем задание с именем `unit-tests`, которое принадлежит этой стадии. Ключ `image` указывает Docker-образ, который будет использован для создания среды выполнения (в данном случае, легковесный образ Node.js). `before_script` — команды, выполняемые перед основным скриптом (установка зависимостей). `script` — основные команды, которые выполняют работу (запуск тестов). Запушьте этот файл в репозиторий. Перейдите в раздел CI/CD > Pipelines вашего проекта в GitLab. Вы увидите, что пайплайн запустился, а задание `unit-tests` либо прошло, либо упало. Поздравляем, вы автоматизировали запуск тестов!

Теперь расширим пайплайн. Добавим стадию сборки и артефакты. Артефакты — это файлы, которые создаются в ходе задания и могут быть переданы на следующие стадии. Добавим в файл:

stages:
 - build
 - test

build-job:
 stage: build
 image: node:16-alpine
 script:
 - npm install
 - npm run build
 artifacts:
 paths:
 - dist/
 expire_in: 1 week

unit-tests:
 stage: test
 image: node:16-alpine
 dependencies:
 - build-job
 script:
 - npm test

Обратите внимание: мы добавили стадию `build` и задание `build-job`, которое собирает проект. Ключ `artifacts` указывает, что папка `dist/` должна быть сохранена как артефакт. В задании `unit-tests` появился ключ `dependencies`, который указывает, что для выполнения тестов нужны артефакты от `build-job`. GitLab автоматически загрузит папку `dist/` в среду выполнения тестов.

Одна из мощнейших возможностей — использование переменных (variables) и секретов. Никогда не храните пароли или токены прямо в YAML-файле. В настройках проекта (Settings > CI/CD > Variables) вы можете добавить переменные, например, `DEPLOY_TOKEN`. Они будут доступны в пайплайне как environment variables. Например, для деплоя на сервер можно добавить стадию:

deploy-to-staging:
 stage: deploy
 image: alpine
 script:
 - apk add --no-cache rsync openssh
 - rsync -avz -e "ssh -o StrictHostKeyChecking=no" ./dist/ user@staging-server:/var/www/app/
 only:
 - main

Ключевое слово `only` указывает, что это задание должно выполняться только для коммитов в ветку `main`. Для защиты используйте переменную `$SSH_PRIVATE_KEY`, сохраненную в настройках проекта, для аутентификации.

Кэширование — важный аспект для скорости. Установка зависимостей (npm install) может занимать много времени. Вы можете закэшировать папку `node_modules`:

cache:
 key: ${CI_COMMIT_REF_SLUG}
 paths:
 - node_modules/

Этот блок, размещенный на глобальном уровне, указывает GitLab CI кэшировать указанные пути. Ключ кэша использует переменную окружения, чтобы для каждой ветки был свой кэш.

В течение дня поэкспериментируйте с другими возможностями: условное выполнение заданий (`rules` или `only/except`), ручные задания (`when: manual`), которые требуют клика для запуска, и матричное выполнение (`parallel: matrix`) для тестирования на разных версиях языка. Изучите встроенные шаблоны (Templates), которые GitLab предлагает для различных языков и фреймворков.

К концу дня вы должны иметь четкое понимание структуры `.gitlab-ci.yml`, принципов работы runner'ов, управления артефактами, переменными и кэшем. Вы создадите пайплайн, который автоматически собирает, тестирует и условно деплоит ваше приложение. GitLab CI — это гибкий и мощный инструмент, и его грамотная настройка становится краеугольным камнем эффективной и надежной DevOps-практики в любой команде.