Параллельные job’ы в CI/CD — ускоряем пайплайны по-взрослому

“Почему мой билд идёт 15 минут, если тесты занимают всего 3” — Каждый разработчик хотя бы раз

Современные пайплайны не обязаны выполняться последовательно. Параллельные job’ы позволяют запускать несколько задач одновременно, значительно ускоряя прохождение этапов CI/CD и повышая эффективность инфраструктуры.

Зачем вообще параллелить

• Скорость — вместо одной длинной задачи можно разбить на 4 и получить результат в 4 раза быстрее
• Изоляция — разные окружения/тесты не мешают друг другу
• Гибкость — можно динамически масштабировать Runner’ы под нагрузку
• Командная разработка — разные фичи билдятся одновременно без блокировок

Базовая схема

GitLab CI позволяет параллелить job’ы двумя способами:

1. Один stage → несколько job’ов Все job’ы внутри одного stage по умолчанию выполняются параллельно, если есть свободные Runner’ы.
2. parallel: ключ Один job можно “размножить” на несколько параллельных экземпляров, например для шардирования тестов.

Пример: Параллельные job’ы по stage

stages:
  - build
  - test

build-frontend:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build

build-backend:
  stage: build
  image: golang:1.22
  script:
    - go build ./...

test-frontend:
  stage: test
  image: node:20
  script:
    - npm test

test-backend:
  stage: test
  image: golang:1.22
  script:
    - go test ./...

Все build-* job’ы запускаются параллельно, а затем все test-*. Если настроены несколько Runner’ов — пайплайн летит

Пример: Parallel matrix для шардирования

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

stages:
  - test

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run test:shard $CI_NODE_INDEX $CI_NODE_TOTAL
  parallel: 4

GitLab создаст 4 параллельных job’а:
- test 1/4
- test 2/4
- test 3/4
- test 4/4

---

Advanced: Parallel Matrix (динамические параметры)

stages:
  - test

e2e-tests:
  stage: test
  image: cypress/included:12.0.0
  parallel:
    matrix:
      - BROWSER: [chrome, firefox]
        REGION: [eu, us]
  script:
    - npm ci
    - npm run e2e -- --browser=$BROWSER --region=$REGION

GitLab создаст 4 job’а:
- chrome + eu
- chrome + us
- firefox + eu
- firefox + us

Практические советы

• Выделяй отдельные Runner’ы для тяжёлых job’ов, чтобы не душили лёгкие.
• ‍Используй теги Runner’ов (tags:) для маршрутизации job’ов по типам задач.
• Если в облаке — не забудь про auto-scaling, чтобы не платить за простаивающие инстансы.
• Логируй артефакты каждой параллельной job’ы отдельно, чтобы можно было дебажить ошибки.
• Следи за лимитами GitLab (в SaaS версиях есть ограничения на кол-во параллельных job’ов).

Когда не стоит параллелить

• Если job’ы жёстко зависят друг от друга (например, миграции БД)
• Когда распараллеливание добавляет больше оверхеда, чем выгоды
• Если Runner один — просто будут ждать в очереди

Итог

Параллельные job’ы — это один из самых простых и мощных способов ускорить пайплайны без изменения логики приложения. Если у тебя CI/CD до сих пор “один длинный job” — начни с разбиения по stage и посмотри на разницу по времени ⏱