Capstone: чтение реального deploy.yml как кейс-стади по release engineering

Workflow на ревью

Вот форма пайплайна, сжатая до несущих частей:

name: build-deploy
on:
  push:
    branches: [main]

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true        # новый push отменяет деплой в полёте

permissions:
  contents: read

jobs:
  build-deploy:                    # один джоб: plan → build → lint → deploy
    runs-on: ubuntu-latest
    timeout-minutes: 90
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4      # state живёт здесь, не в артефактах
        with:
          key: build-${{ hashFiles('content-hash') }}
          path: dist/
      - run: bun install --frozen-lockfile
      - run: bun run build          # полный рендер ~12 мин (инкрементальный короче)
      - run: cat dist/lint-report.json   # build-time linter-гейт
      - run: ./deploy.sh dist/       # upload статики на CDN/Pages-хост

Что он делает хорошо, в словаре этого юнита:

• concurrency с cancel-in-progress: true, ключеванный по ref, означает, что новый push в main отменяет более старый, ещё бегущий деплой той же ветки. Ты никогда не получаешь два деплоя, гоняющихся за публикацию, и никогда не тратишь 12-минутную сборку на коммит, что уже вытеснен. Это верный дефолт для деплоя статики на единую цель, где важно лишь последнее состояние.
• Единственный artifact-free джоб — рубцовая ткань из Hook: plan, build, lint и deploy бегут в одном джобе и передают state через actions/cache (отдельная от артефактов квота), поэтому нет передачи 420 МБ, что заклинит. Держание всего пайплайна в одном джобе также означает, что нет меж-джобного артефакта, что истечёт или повредится — цена в том, что шаги не могут масштабироваться вширь, что для ~12-минутной сборки приемлемый размен.
• permissions: contents: read — least privilege: токен джоба может читать репо и ничего больше, поэтому скомпрометированный шаг не может пушить коммиты или публиковать пакеты.
• Build-time linter (lint-report.json) — релиз-гейт внутри сборки: контент, нарушающий правила, валит ран до того, как что-либо отгрузится.

Оцени против планки release engineering

Читая любой пайплайн, попробуй разделить два вопроса: «это корректно деплоит?» и «это управляет релизом?» Большинство пайплайнов отвечают да на первый и нет на второй. Workflow операционно крепок, но прочитай его против четырёх столпов этого юнита, и дыры ясны — и поучительны, потому что они разница между «деплоит статику» и «управляет релизом».

• Версионирование и теги: этот пайплайн деплоит на каждый push в main без версии, без тега и без неизменяемого ref. Для статики, что публикует latest-wins, это защитимый выбор — но он означает, что нет именованного релиза, на который указать, а «откатить на последнюю хорошую версию» нечего именовать. Митигация, что подходит этому дизайну — собственная неизменяемая история деплоев хоста (каждый upload — отдельный, адресуемый деплой, что можно мгновенно пере-промоутить), которая заменяет git-тег как якорь обратимости.
• Changelog и релизная запись: нет генерируемого changelog и нет релизного объекта, поэтому «что изменилось в этом деплое» отвечаемо лишь чтением коммита, что его триггернул. Приемлемо для внутреннего сайта; дыра в момент, когда внешним потребителям или аудиторам нужна запись на релиз.
• Окружения и гейты: деплой бежит прямо в production на push без окружения, без required reviewer и без wait-таймера. Каждый смерженный коммит отгружается мгновенно без человека на момент релиза и без выдержки. Это самая большая дыра против юнита: для чего угодно сверх низко-ставочной статики ты бы поставил деплой за окружение production с required reviewer и коротким wait-таймером, и вероятно разделил build (на push) и deploy (гейтированный).
• Обратимость: нет явного пути отката в workflow. Восстановление целиком зависит от способности хоста деплоя пере-промоутить предыдущий деплой. Это работает для статического CDN-хоста, но это неявно — senior сделал бы «передеплой предыдущий известно-хороший деплой» явным, протестированным, одно-командным путём, а не свойством, что он предполагает у платформы.