GitLab CI/CD

Стадии дают простой линейный порядок: все job-ы одной стадии должны завершиться, прежде чем начнётся следующая. Это легко читать, но медленно, когда один job в стадии намного дольше остальных, — все ждут его. needs: объявляет прямые зависимости между job-ами, так что job стартует, как только завершились нужные ему job-ы, даже если другие job-ы ранних стадий ещё идут. Пайплайн становится направленным ациклическим графом. needs также управляет тем, какие артефакты скачивает job. Я начинаю со стадий для наглядности и добавляю needs там, где критический путь длинный, например позволяю deploy-docs стартовать сразу после build-docs.

Артефакты — это результаты job-ов, которые GitLab хранит и передаёт следующим job-ам того же пайплайна и которые можно скачать из UI: папки сборки, отчёты тестов, coverage. Они надёжны: следующий job, которому они нужны, их получит. Кэш — это ускорение по принципу best-effort для того, что можно сгенерировать заново, например node_modules или каталог загрузок пакетного менеджера; он разделяется между пайплайнами и хранится на раннере или в object storage. Job обязан корректно работать с пустым кэшем. Используйте cache:key:files с lockfile, чтобы кэш менялся при изменении зависимостей. Если корректность job-а зависит от файла — нужен артефакт.

Храните их как CI/CD-переменные с пометками protected и masked, чтобы они подставлялись только в пайплайны защищённых веток или тегов и скрывались в логах. Защитите ветку main, чтобы пушить и мержить могли только maintainer-ы. Сделайте production защищённым environment с deployment approvals, чтобы deploy-job-ы могли запускать только указанные люди или группы. Запускайте deploy-job-ы на выделенном раннере с тегом в production-сети, а не на shared-раннерах. По возможности вообще избегайте статических credentials: используйте id_tokens, чтобы выдать job-у короткоживущий OIDC-токен, который облачный провайдер или Vault обменяет на временные credentials, ограниченные этим проектом и веткой.

Executor — это способ, которым раннер реально выполняет job. Shell запускает команды прямо на хосте раннера: быстрее всего настроить, но изоляции между job-ами нет, поэтому я использую его только на очень доверенных машинах одного назначения. Docker запускает каждый job в свежем контейнере из его image: хорошая изоляция, воспроизводимость, обычный выбор по умолчанию. Kubernetes создаёт под на каждый job — подходит командам, у которых уже есть кластер и нужно автомасштабирование. Docker-autoscaler или instance executor-ы поднимают облачные VM по запросу для сильной изоляции каждого job-а. Большинству команд я бы выбрал Docker executor на паре VM, а потом переходил на Kubernetes или автомасштабирование, когда время в очереди станет проблемой.

GitLab предлагает несколько уровней. Внутри одного файла extends: и YAML-якоря переиспользуют определения job-ов, а скрытые job-ы (имена с точкой в начале) работают как шаблоны. Между проектами include: подтягивает YAML из другого проекта, по удалённому URL или из шаблонов самого GitLab. Современный вариант — CI/CD components: версионированные переиспользуемые части пайплайна, опубликованные в CI/CD Catalog, со spec: inputs, которые типизированы и проверяются при создании пайплайна. Сервис пишет пару строк, чтобы подключить компонент нужной версии и передать inputs. Фиксируйте версии, чтобы изменение общего компонента не сломало все проекты разом.

Я бы дал небольшой каталог CI/CD components (build, test, scan, deploy), который поддерживает платформенная команда, с версиями по семантическим тегам и документацией. Критичные для compliance job-ы — SAST, dependency scanning и secret detection — навязывались бы централизованно через pipeline execution policies или compliance frameworks, чтобы проекты не могли их убрать. Парки раннеров разделены по доверию: автомасштабируемые shared-раннеры для сборок, protected-раннеры для деплоев, изолированные раннеры внутри production-сетей. Секреты приходят из Vault или облака через OIDC id_tokens, с claims, привязанными к пути проекта и защищённым ref-ам. Environments защищены аппрувами. Компромисс — автономия: команды должны иметь возможность расширять стандартный пайплайн своими job-ами, иначе они его форкнут, и платформа потеряет контроль.

Push-подход означает, что CI-job держит credentials кластера и запускает kubectl или helm. Это просто, даёт немедленную обратную связь в пайплайне и работает как для серверов, так и для кластеров. Минусы: CI нужны мощные credentials, а расхождение (drift) между Git и кластером остаётся незамеченным. Pull-based GitOps запускает агента внутри кластера, который следит за репозиторием конфигурации и применяет изменения. Credentials кластера никогда его не покидают, drift обнаруживается и исправляется, а история Git служит аудит-логом. Цена — ещё одна система в эксплуатации и непрямая обратная связь: CI только обновляет тег образа в Git. Для Kubernetes на масштабе я склоняюсь к GitOps, где CI собирает и тестирует образы; для нескольких VM push-деплой с protected-раннера вполне разумен.

Скорость — это делать меньше и параллельно: графы needs:, rules: changes:, чтобы пропускать незатронутую работу, шардирование тестов через parallel:, кэш зависимостей и слоёв Docker, заранее собранные CI-образы с готовым тулчейном. Надёжность — это детерминизм: зафиксированные версии образов, lockfile, отсутствие зависимости от внешних сервисов в unit-тестах и повторы только для известных временных ошибок инфраструктуры через retry: when:, но никогда для падающих тестов. Нестабильные тесты отслеживаются и помещаются в карантин с назначенным владельцем. Измеряйте через pipeline analytics и метрики раннеров и задайте бюджет, например медиана пайплайнов merge request-ов меньше десяти минут. Компромисс — поддержка: агрессивный пропуск может прозевать поломки между сервисами, поэтому дополняйте его полными пайплайнами по расписанию на ветке по умолчанию.