Как настроить пайплайн с разделением на стадии в GitLab CI

В GitLab CI пайплайны выполняют основную роль в автоматизации процессов CI/CD. Они позволяют разбить весь процесс сборки, тестирования и деплоя на отдельные, логически связанные задачи — или "джобы". Эти джобы структурируются в стадии, каждая из которых представляет собой определенный этап работы, например, сборка, тестирование или развертывание. Такое разделение позволяет ускорить разработку и минимизировать ошибки при доставке кода на продакшн.

В этой статье рассмотрим, как настроить пайплайн с разделением на стадии в GitLab CI.

Настройка пайплайна

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

Каждый файл .gitlab-ci.yml начинается с определения стадий, затем определяются джобы, которые будут выполнены на этих стадиях. Минимальный пример:

stages:
  - build
  - test
  - deploy

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

После того как стадии определены, нужно привязать к ним задачи. Каждая задача выполняет набор команд:

build-job:
  stage: build
  script:
    - echo "Building the project..."
    - make build

test-job:
  stage: test
  script:
    - echo "Running tests..."
    - make test

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - make deploy

В этом примере у нас три джобы: одна для каждой стадии. Каждая джоба выполняет свою команду на этапе, к которому она привязана. Каждая джоба выполняется независимо и может иметь свои переменные окружения, зависимости и условия запуска.

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

Пример более сложной конфигурации пайплайна:

stages:
  - build
  - test
  - deploy
  - cleanup

# Джоба для сборки
build-job:
  stage: build
  script:
    - echo "Building project..."
    - make build
  artifacts:
    paths:
      - build/

# Джоба для тестирования
test-job:
  stage: test
  script:
    - echo "Running tests..."
    - make test
  dependencies:
    - build-job
  artifacts:
    paths:
      - test-results/

# Джоба для деплоя
deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - make deploy
  when: manual
  environment: production

# Джоба для очистки временных файлов
cleanup-job:
  stage: cleanup
  script:
    - echo "Cleaning up..."
    - rm -rf build/ test-results/
  only:
    - master

Этот пайплайн уже сложнее и интереснее. Вот что в нем важно:

1. Артефакты: сохраняем артефакты сборки и тестов для последующих стадий. Это делает пайплайн независимым от повторного выполнения предыдущих этапов.

2. Зависимости: указывая зависимости dependencies, мы гарантируем, что задача test-job использует результаты сборки.

3. Manual deploy: деплой настроен на ручной запуск when: manual.

4. Очистка: последняя стадия — это очистка временных файлов. Она выполняется только для ветки master, чтобы не захламлять репозиторий временными артефактами.

Представим, что нужно собрать Docker-контейнер, протестировать его, а затем задеплоить на продакшн. Как это может выглядеть:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: docker:stable
  services:
    - docker:dind
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker save myapp:$CI_COMMIT_SHA | gzip > myapp.tar.gz
  artifacts:
    paths:
      - myapp.tar.gz

test-job:
  stage: test
  script:
    - docker load -i myapp.tar.gz
    - docker run myapp:$CI_COMMIT_SHA ./run-tests.sh
  dependencies:
    - build-job

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - docker load -i myapp.tar.gz
    - docker tag myapp:$CI_COMMIT_SHA myrepo/myapp:latest
    - docker push myrepo/myapp:latest
  when: manual
  environment: production

Этот пайплайн выполняет следующие шаги:

• Сборка Docker-образа на стадии build.

• Тестирование образа на стадии test.

• Деплой на продакшн при ручном запуске на стадии deploy.

Параллельное выполнение стадий

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

Пример конфигурации с использованием директивы needs:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - make build

test-job:
  stage: test
  needs: ["build-job"]
  script:
    - make test

deploy-job:
  stage: deploy
  needs: ["test-job"]
  script:
    - make deploy

Здесь задачи test-job и deploy-job начнут выполняться сразу после успешного завершения своих зависимостей, что ускоряет выполнение по сравнению с классическим последовательным запуском стадий.

В GitLab CI также доступна директива dependencies, которая контролирует, какие артефакты могут быть переданы между задачами на разных стадиях. Это мастхев, когда одна задача нуждается в результатах другой.

Пример:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - make build
  artifacts:
    paths:
      - build/

test-job:
  stage: test
  script:
    - make test
  dependencies:
    - build-job

deploy-job:
  stage: deploy
  script:
    - make deploy
  dependencies:
    - test-job

Здесь артефакты, созданные на стадии build, передаются в задачу test-job, а затем в deploy-job.

Один из эффективных методов ускорения пайплайнов – кэширование. GitLab позволяет кешировать зависимости, такие как библиотеки и пакеты, чтобы не загружать их заново при каждом запуске пайплайна. Например:

build-job:
  stage: build
  cache:
    paths:
      - node_modules/
  script:
    - npm install
    - npm run build

Здесь кэшируются node_modules, что позволяет не устанавливать их заново на каждом шаге сборки.

Директива parallel позволяет запускать несколько экземпляров одной и той же задачи параллельно.

Пример параллельного тестирования с разными версиями Python:

test-job:
  stage: test
  image: python:$VERSION
  script:
    - pytest
  parallel:
    matrix:
      - VERSION: ['3.8', '3.9', '3.10', '3.12']

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

В завершение напомню про открытый урок по использованию gitlab-ci для работы с ansible, который пройдет 18 сентября.

На этом занятии вы узнаете, как применять GitLab CI для автоматизации процессов с помощью Ansible. Познакомитесь с основами работы с GitLab CI и Ansible, а также научитесь создавать пайплайны для тестирования плейбуков и управления инфраструктурой.

Записаться на урок бесплатно можно на странице курса «CI/CD на основе GitLab».