Анатомия пайплайна

Pipeline, stages, jobs

Эти три слова образуют базовый словарь, одинаковый почти во всех CI-системах (названия чуть отличаются, смысл тот же).

• Pipeline — весь прогон целиком на одно изменение.
• Stage (стадия) — этап пайплайна: build, test, deploy. По умолчанию стадии идут последовательно: пока не прошла предыдущая, следующая не стартует. Этот порядок можно обойти, см. ниже про needs:.
• Job (задача) — конкретная работа внутри стадии. Jobs одной стадии обычно бегут параллельно.

stage: build      stage: test                stage: deploy
  [build job]  ->  [unit] [lint] [types]  ->  [deploy job]
                   (параллельно)

Логика: собрали один раз, потом параллельно прогнали разные проверки, а если все зелёные, выкатили.

Когда стадии мешают

Последовательные стадии просты, но иногда заставляют ждать зря. Job линтинга не зависит от сборки, а всё равно стоит в очереди за ней.

Ключ needs: разрывает эту цепочку: job стартует, как только отработали перечисленные в нём job, независимо от стадии.

deploy:prod:
  stage: deploy
  needs: ["build"]        # ждём только build, а не всю стадию test
  script:
    - ./deploy.sh

Пайплайн из строгой лестницы превращается в граф зависимостей (DAG, directed acyclic graph). На больших пайплайнах это экономит минуты: независимые ветки идут параллельно вместо того, чтобы упираться в самый медленный job чужой стадии.

Ещё needs: умеет тянуть артефакты выборочно. Без него job получает артефакты всех предыдущих стадий; с ним берёт только от указанных job.

Runner: кто выполняет работу

Сами по себе jobs — это просто описание. Выполняет их runner - машина (или контейнер), которая берёт задачу, гоняет команды и рапортует результат.

• В GitLab это GitLab Runner, в GitHub Actions просто runner, в Jenkins agent или node.
• Runner'ы бывают shared (общие, облачные у провайдера) и self-hosted (свои, в твоей инфраструктуре; нужны, когда требуется доступ во внутреннюю сеть или особое железо).
• Чаще всего job выполняется в чистом Docker-контейнере из указанного образа: каждый прогон с нуля, без мусора от прошлого. Отсюда воспроизводимость.

Артефакты

Артефакт — файл(ы), которые job произвёл и которые нужны дальше: собранный бинарник, Docker-образ, директория dist/, отчёт о тестах.

CI умеет передавать артефакты между стадиями: build собрал dist/, deploy его забрал. Без этого каждая job стартует с пустого места и не видит результат предыдущей.

Не путать с кешем: кеш — это ускорение (сохранённые node_modules/зависимости между прогонами), его потеря не критична. Артефакт — это результат, он нужен по делу.

Переменные и секреты

Pipeline почти всегда нужны секреты: пароль к registry, SSH-ключ к серверу, токен API. Их нельзя хранить в репозитории.

CI-системы дают хранилище переменных (GitLab: Settings -> CI/CD -> Variables; GitHub: Secrets). Оттуда секрет подставляется в job как переменная окружения. Признаки правильно настроенного секрета:

• masked — замаскирован в логах (вместо значения [masked]),
• protected — доступен только на защищённых ветках (например, main), чтобы из левой ветки нельзя было его выудить.

Золотое правило: секрет живёт в хранилище CI, а не в .gitlab-ci.yml и не в коде.

Окружения (environments)

Environment — именованная цель деплоя: staging, production. CI-системы трекают, какая версия сейчас в каком окружении, и дают кнопки rollback/redeploy.

Типичная лестница: код едет сначала на staging (полная копия прода для проверки), и только потом в production.

Триггеры и правила

Pipeline запускается по событию: push в ветку, открытие/обновление merge request, по расписанию (cron, ночные сборки), вручную кнопкой, или по тегу (релиз).

Какие jobs на каком событии запускать, решает ключ rules: с условиями if. Типично: тесты гоняем на каждый MR, а деплой в прод запускаем только на push в main.

В старых конфигах и туториалах встречается only:/except:. Это legacy: GitLab не развивает эти ключи с версии 12.3, новые возможности появляются только в rules. Смешивать их в одном job нельзя, GitLab отвергнет конфиг. В новом коде пиши rules, старый переводи на него по мере правок.

Что важно запомнить

Pipeline -> stages (последовательно) -> jobs (внутри стадии параллельно). needs: ломает последовательность и превращает пайплайн в граф зависимостей: job стартует, как только готовы его зависимости.

Условия запуска пишут через rules. only/except — legacy, не развивается с 12.3.

Runner — машина/контейнер, которая реально выполняет job; обычно с нуля в чистом контейнере.

Артефакт — результат (бинарник, образ), передаётся между стадиями. Кеш - лишь ускорение.

Секреты живут в хранилище CI (masked + protected), никогда в репозитории.

Environment — цель деплоя (staging/production) с историей версий и откатом.

В следующем уроке разберём ландшафт инструментов: GitLab CI, GitHub Actions, Jenkins, Argo CD и в чём разница.