Capstone: спроектируй полный CI/CD-пайплайн от и до

Весь пайплайн — одна цепь, а цепь прочна настолько, насколько прочно её пропущенное звено

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

Каждый прошлый урок трека был одним звеном: пайплайны, тестирование в CI, стратегии доставки, окружения и аппрувы, автоматизация релизов, supply-chain provenance, масштабирование. Capstone-пайплайн — это те звенья, сваренные по порядку, и интегративный режим отказа всегда один: любое пропущенное звено молча ломает гарантию, которую цепь должна была дать целиком. Пересобираешь на каждой стадии — твоё обещание «протестированного артефакта» ложь. Деплоишь без пути отката — твой canary это просто медленный аутаж. Отгружаешь непроверенный артефакт — твои SBOM и тесты описывают не тот бинарник, что работает. Дисциплина сеньорского пайплайна не в добавлении стадий — в том, чтобы ни одна стадия тихо не подменяла гарантию на более слабую.

Есть три несущих инварианта. (1) PR-проверки — это гейт merge’а — быстрая обратная связь первой, required status checks блокируют merge, поэтому main всегда релизопригодна. (2) Сборка один раз — на merge или теге артефакт собирается ровно один раз, давая один неизменяемый digest, и с этого момента ничто не пересобирается; он только продвигается. (3) Продвигай тот же digest — staging, canary и production деплоят идентичный image@sha256:…, поэтому единственная переменная между окружениями — конфигурация, никогда не бинарник. Держи эти три — и большинство сюрпризов дня релиза становятся невозможны по построению.

Стадия 1 — PR-проверки: падай быстро, потом доказывай, потом блокируй merge

У PR-гейта есть форма: самые дешёвые, самые вероятные на падение проверки первыми. Lint и typecheck бегут за секунды и ловят большинство ошибок, поэтому идут первыми и закорачивают дорогую работу. Дальше affected-only сборка и тесты — в монорепо ты тестируешь то, что трогает diff, а не весь мир (тут окупается урок про масштабирование). Настрой их как required status checks на ветке, чтобы красная проверка физически блокировала кнопку merge; проверка, которая только репортит, — это совет, не гейт. PR-стадия никогда не деплоит и не подписывает — её единственная задача держать main в режиме «merge-пригодна значит релизопригодна».

name: ci
on:
  pull_request:
permissions:
  contents: read          # least privilege: PR-проверкам больше ничего не нужно
jobs:
  fast-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29  # v4 запинено по SHA
      - uses: actions/setup-node@1d0ff469b7ec7b3cb9d8673fde0c81c44821de2a  # v4 запинено по SHA
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm run lint && npm run typecheck   # секунды; fail fast
      - run: npx nx affected -t build test       # affected-only, не весь мир

Стадия 2 — Сборка один раз: один digest, SBOM, подписанная provenance

Это разворотная точка всего пайплайна. На merge в main (или на релизном теге) ты собираешь образ один раз и пушишь его по digest. В том же ране ты генерируешь SBOM (что внутри), производишь build-provenance-аттестацию (как, где и из какого коммита он собран) и подписываешь их keyless-cosign через Sigstore — OIDC-токен GitHub является подписывающей личностью, поэтому нет долгоживущего ключа, который можно утечь. Это ровно та цепочка, что зарабатывает SLSA (Supply-chain Levels for Software Artifacts — фреймворк уровней доверия к цепочке поставок) Build L2 (а L3 — с изолированным эфемерным билдером на reusable workflow): хостовый, закалённый билдер автоматически генерирует и подписывает provenance. Два пункта без компромиссов для сеньорского workflow: пинни сторонние actions по полному SHA коммита (сдвинутый тег — это supply-chain-бэкдор) и выдавай least-privilege permissions: на каждый джоб, добавляя id-token: write только тому джобу, которому реально нужен OIDC, и attestations: write только там, где аттестуешь.

  build-once:
    needs: fast-gate
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write        # push в GHCR
      id-token: write         # OIDC для keyless-подписи
      attestations: write     # provenance-аттестация
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    steps:
      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29  # v4
      - uses: docker/build-push-action@4f58ea79222b3b9dc2c8bbdd6debcd730a4f6c4f  # v6
        id: push
        with:
          push: true
          tags: ghcr.io/acme/api:${{ github.sha }}
      - uses: actions/attest-build-provenance@e8998f949152b193b063cb0ec769d69d929409be  # v1
        with:
          subject-name: ghcr.io/acme/api
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true
      - uses: anchore/sbom-action@d94f46e13c6c62f59525ac9a1e147a99dc0b9bf5  # SPDX SBOM
        with: { image: ghcr.io/acme/api@${{ steps.push.outputs.digest }} }

Стадии 3–4 — Релиз, затем продвижение того же digest с гейтами и откатом

Релиз — это бухгалтерия поверх проверенного артефакта: выводи версию из conventional commits (semver), тегай и публикуй подписанный образ в реестр. Дальше деплой — это чистое продвижение одного digest. Staging авто-деплоит api@${{ digest }} и гоняет smoke-тесты. Production — отдельное GitHub-окружение с правилами защиты: required reviewers и настройка «без само-аппрува» превращают деплой в осознанный, аудируемый человеческий гейт. За гейтом ты не переключаешь 100% трафика; ты делаешь canary: маршрутизируешь маленький срез, даёшь автоматическому анализу несколько минут следить за error rate и латентностью против базовой линии, и расширяешь только если метрический гейт прошёл. Если срабатывает нарушение SLO (Service Level Objective — целевой показатель уровня сервиса, например p99-латентность ≤ 200 мс), раскатка останавливается и автоматически откатывается к предыдущему digest — то самое звено, которого не хватало в пайплайне из истории. Тот же неизменяемый digest течёт через каждую стадию; меняется только конфиг.

  deploy:
    needs: build-once
    uses: ./.github/workflows/promote.yml
    with:
      digest: ${{ needs.build-once.outputs.digest }}   # продвигаем, не пересобираем
  staging:
    needs: build-once
    environment: staging                                # авто-деплой
    runs-on: ubuntu-latest
    steps:
      - run: deploy ghcr.io/acme/api@${{ needs.build-once.outputs.digest }}
      - run: ./smoke-tests.sh
  production:
    needs: staging
    environment: production    # правило защиты: required reviewers, без само-аппрува
    runs-on: ubuntu-latest
    steps:
      - run: deploy-canary ghcr.io/acme/api@${{ needs.build-once.outputs.digest }} --weight 5
      - run: analyze-slo --window 5m || { rollback; exit 1; }   # метрический гейт → авто-откат
      - run: promote-to-full --weight 100