Automatyzacja wdrożeń z Claude Code

Automatyzacja wdrożeń z Claude Code polega na tym, że agent pisze i uruchamia powtarzalne części wydania: bramki przed wdrożeniem, przeglądy bezpieczeństwa migracji, sparowane skrypty deploy i rollback oraz release notes. Poświadczenia produkcyjne zostają w CI albo u człowieka. Poprawność każdego wyniku potwierdzają kody wyjścia, wdrożenie na staging, smoke test i przećwiczony rollback, a nie czytanie kodu linijka po linijce.

Ten przewodnik jest dla programistów i tech leadów, którzy odpowiadają za wydania serwisu. Masz 47 commitów do wypuszczenia, trzy z nich zmieniają schemat bazy, produkcja potrzebuje innego tagu obrazu i trzech zmiennych środowiskowych, których nikt nie pamięta, a ostatnio migracja wykonała się już po starcie nowego kodu, więc użytkownicy oglądali błędy 500, dopóki ktoś ręcznie nie wycofał zmian. Poniższe kroki zamieniają tę checklistę w skrypty, które pisze Claude Code, a egzekwuje twój pipeline. Zakładają, że uruchamiasz już claude -p w skryptach; jeśli nie, zacznij od strony skrypty z Claude Code: uruchomienia headless, potoki, cron i hooki git.

Co zyskasz z tego przewodnika

• Standard wdrożeniowy w CLAUDE.md i blok uprawnień, który trzyma produkcję poza zasięgiem agenta
• Bramkę deploy-check.sh, która deterministyczne kontrole uruchamia w shellu, a claude -p pyta tylko o kwestie wymagające osądu i kończy się maszynowo czytelnym GO albo NO-GO
• Prompty do skopiowania: przegląd bezpieczeństwa migracji, para skryptów deploy i rollback, przełączenie blue-green z rollbackiem sterowanym metryką oraz plan wycofania w trakcie incydentu
• Skill /release-notes, który zamienia historię gita we wpis do changeloga i który może uruchomić każdy w zespole
• Procedurę weryfikacji (dry run, staging, smoke test, próba rollbacku), która mówi ci, że skrypty działają, bez czytania każdej linijki

Gdzie Claude Code pasuje do wydania, a gdzie się zatrzymuje?

Claude Code jest mocny w tych częściach wydania, które są tekstem: skryptach, przeglądach diffa i opisach historii zmian. Nie powinien jednak trzymać poświadczeń produkcyjnych ani naciskać przycisku. Wdrożenie należy do pipeline’u CI, który uruchamia napisane przez Claude’a skrypty po zatwierdzeniu przez człowieka.

Krok wydania	Co tworzy Claude Code	Jak to udowodnić bez czytania każdej linijki	Kto zatwierdza
Bramka przed wdrożeniem	deploy-check.sh i werdykt GO/NO-GO dla diffa	Kody wyjścia sprawdzania typów, lintera, testów i builda; plik z werdyktem dołączony do wydania	Programista przygotowujący wydanie
Przegląd migracji	Raport zgodności dla każdej migracji	up, down, up na kopii danych produkcyjnych na stagingu	Autor migracji plus jeden recenzent
Skrypty deploy i rollback	deploy.sh i rollback.sh jako para	shellcheck, przebieg z DRY_RUN=1, wdrożenie na staging, przećwiczony rollback	Tech lead, przy każdej zmianie skryptu
Rollout	Przełączenie blue-green lub canary z progiem metryki	Celowo zepsuty obraz na stagingu, który uruchamia automatyczny powrót	Tech lead zatwierdza środowisko produkcyjne w CI
Release notes	Wpis do changeloga i notatki wydania	Każda linia wskazuje commit albo numer PR	Właściciel wydania
Rollback w incydencie	Plan wycofania i dokładne komendy	Powrót do normy widoczny na dashboardach wskazanych w planie	Inżynier dyżurny uruchamia komendy

Dwa sąsiednie zadania mają własne strony. Generowanie i utwardzanie samego pipeline’u opisuje konfiguracja pipeline’ów z Claude Code. Dockerfile’e i manifesty Kubernetes opisuje konfiguracja Dockera i Kubernetesa z CLI. Używasz Codexa? Zobacz automatyzację wdrożeń z Codexem. Wersję niezależną od narzędzia opisuje etap wdrożenia w metodzie.

Najpierw zapisz zasady wdrożeń w CLAUDE.md

Każdy prompt wdrożeniowy z tej strony staje się krótszy i bezpieczniejszy, kiedy zasady żyją w CLAUDE.md projektu. Claude Code wczytuje ten plik na początku każdej sesji, więc nowy inżynier, który prosi o „skrypt deploy dla serwisu płatności”, dostaje te same ograniczenia co autor zasad.

## Deployment rules

- Deploys run only from CI (.github/workflows/deploy.yml). Never run a deploy or rollback against production from a local session.
- Every deploy script has a matching rollback script, and deploy.sh records the running image tag before it changes anything.
- Scripts start with `set -euo pipefail` and support DRY_RUN=1, which prints every command instead of running it.
- Image tags are the git SHA. Never deploy `latest` to production.
- Migrations are expand/contract: add columns and tables in one release, remove them in a later one. The migration runs before the new code starts.
- Every new environment variable is added to .env.example in the same commit.
- Secrets come from the environment or the secret store, never from a file in the repository.

Wzmocnij zasady regułami deny w .claude/settings.json, żeby agent został zatrzymany nawet wtedy, gdy prompt prosi o zakazany krok:

{
  "permissions": {
    "deny": [
      "Bash(./scripts/deploy.sh prod*)",
      "Bash(./scripts/rollback.sh prod*)",
      "Bash(kubectl *)",
      "Bash(terraform apply *)",
      "Read(./.env.production)"
    ]
  }
}

Uwaga

Reguła deny dopasowuje tekst komendy, więc sh -c './scripts/deploy.sh prod' to inny zapis, którego pierwsza reguła nie widzi. Traktuj reguły jako filtr na uczciwe pomyłki. Kontrola, która naprawdę działa, to brak poświadczeń produkcyjnych w środowisku agenta: żadnego produkcyjnego kubeconfigu, profilu chmury ani tokenu wdrożeniowego na maszynie, na której pracuje Claude Code. Ustawienia sandboksa, które to egzekwują, opisuje strona uprawnienia, sandboksy i tryby zatwierdzania.

Uruchom bramkę przed wdrożeniem przez claude -p

Typowy błąd to prośba do Claude’a, żeby „uruchomił testy i zgłosił PASS albo FAIL”. Wtedy jedynym dowodem jest raport modelu, a model potrafi podsumować czerwony przebieg jako zielony. Podziel pracę. Shell uruchamia deterministyczne bramki i o wyniku decyduje kod wyjścia. Claude odpowiada tylko na pytania wymagające osądu, na przykład czy migracja jest bezpieczna przy rolling update.

Skrypt do skopiowania: bramka przed wdrożeniem

#!/usr/bin/env bash
# scripts/deploy-check.sh: run from the repository root before tagging a release
set -euo pipefail

BASE="$(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)"
# Write the verdict outside the working tree, so a rerun still passes the clean-tree check
OUT="${RUNNER_TEMP:-/tmp}/deploy-check.txt"

# 1. Deterministic gates: the exit codes decide, not the model
# fail fast on uncommitted changes, before the build writes anything
test -z "$(git status --porcelain)" || { echo "Uncommitted changes"; exit 1; }
npx tsc --noEmit
npm run lint
npm test
npm run build

# 2. Judgment checks: Claude reads the diff since the last release, read-only
claude -p "Check whether the changes since ${BASE} are safe to deploy with a rolling update.
Run git log ${BASE}..HEAD and git diff ${BASE}..HEAD.
Answer each question with PASS or FAIL and one line of evidence as file:line.
1. Every new migration is backward-compatible: the code that is running now keeps working against the new schema.
2. Every environment variable the new code reads is listed in .env.example.
3. No API response field that existing clients read is removed or renamed.
4. Nothing assumes that all instances run the same version at the same moment.
If any answer is FAIL, name the deployment strategy it needs: expand/contract migration, feature flag, or maintenance window.
End with exactly one plain-text line and nothing after it: VERDICT: GO or VERDICT: NO-GO" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Grep" "Glob" "Bash(git log *)" "Bash(git diff *)" \
  --max-budget-usd 2 \
  --output-format text | tee "$OUT"

grep -qx 'VERDICT: GO' "$OUT"

Cztery szczegóły sprawiają, że tej bramce można ufać:

• Błąd oznacza blokadę. Jeśli skończy się budżet, model inaczej sformatuje werdykt albo przebieg zakończy się błędem, grep -qx nie znajdzie dokładnej linii VERDICT: GO i skrypt zwróci niezerowy kod. Brak werdyktu oznacza NO-GO.
• Agent niczego nie zmieni. --permission-mode dontAsk odrzuca każde narzędzie, którego nie zatwierdza z góry lista --allowedTools, a ta lista jest tylko do odczytu.
• Koszt ma limit. --max-budget-usd zatrzymuje przebieg, który wymknął się spod kontroli. --max-turns nie figuruje już w claude --help (2.1.283), choć CLI nadal go przyjmuje; limituj koszt przez --max-budget-usd zamiast polegać na nieudokumentowanej fladze.
• Dowód zostaje przy wydaniu. Dołącz plik z werdyktem ($RUNNER_TEMP/deploy-check.txt w GitHub Actions, /tmp/deploy-check.txt lokalnie) do pull requesta z wydaniem, obok przebiegu CI, jako część pakietu dowodów, który recenzent sprawdza zamiast diffa.

Jak uruchomić tę samą bramkę w GitHub Actions, opisuje strona Claude Code w CI/CD z GitHub Actions i trybem headless. Znajdziesz tam uprawnienia tokenów i zasady dotyczące niezaufanych refów, których potrzebuje zadanie CI.

Przejrzyj migracje bazy danych przed wydaniem

Migracja to zmiana, której rollback często nie cofnie, bo stary kod może nie działać na nowym schemacie. Poproś Claude Code o ustrukturyzowany przegląd każdej oczekującej migracji, a potem udowodnij odpowiedź na danych.

Prompt do skopiowania: przegląd bezpieczeństwa migracji

Review every migration in db/migrations/ that is newer than the last release tag.
For each migration, answer:
1. Backward compatibility: can the code that is running in production now work against the schema after this migration? Quote the queries that would break.
2. Rollback: is there a down migration, and does it restore the data, or only the schema?
3. Locking: will it rewrite or lock a large table? Name the table and the statement.
4. Data risk: can a data transformation fail on existing rows (NULLs, duplicates, oversized values)?
5. Re-runs: what happens if it is applied twice?
Then propose an expand/contract split for any migration that fails question 1, as two separate releases.
Do not edit any file. Output a table with one row per migration and a final list of migrations that need a maintenance window.

Przegląd to trop, a nie dowód. Dowodem jest uruchomienie migracji na stagingu na świeżej, zanonimizowanej kopii danych produkcyjnych, w kolejności up, down, up, z pomiarem czasu. Migracja, która na prawdziwych danych blokuje tabelę na kilka minut, na pustej bazie deweloperskiej wygląda niewinnie.

Generuj skrypty deploy i rollback jako parę

Poproś o oba skrypty w jednym prompcie. Kiedy Claude pisze rollback w tym samym momencie, zapisuje stan potrzebny do wycofania, zanim deploy go zmieni.

Prompt do skopiowania: para deploy i rollback

Write scripts/deploy.sh and scripts/rollback.sh for our service. Follow the deployment rules in CLAUDE.md.

deploy.sh <env> where env is dev, staging or prod:
1. Load deploy/envs/<env>.env and fail if any variable listed in .env.example is unset.
2. Record the image tag that is running now in deploy/state/<env>.last-deploy.
3. Build and push the image to $ECR_REGISTRY, tagged with the git SHA.
4. Run database migrations against that environment's DATABASE_URL before the new code starts.
5. Update the Kubernetes deployment in namespace <env> with kubectl set image and wait for kubectl rollout status.
6. Smoke test: curl the /health endpoint and one read-only API route, and fail on any non-200 response.
7. Post the result to Slack through $SLACK_WEBHOOK_URL.

rollback.sh <env> redeploys the tag in deploy/state/<env>.last-deploy, waits for the rollout, runs the same smoke test, and prints (but does not run) the down migration command if migrations ran since that tag.

Both scripts: set -euo pipefail, support DRY_RUN=1 to print every command instead of running it, and exit 1 with a clear message on the first failure. Then run shellcheck on both and fix every warning.

Zweryfikuj parę, zanim uruchomi ją jakikolwiek pipeline:

1. Uruchom shellcheck scripts/deploy.sh scripts/rollback.sh oraz bash -n na obu plikach. Oba muszą przejść bez uwag.

2. Uruchom DRY_RUN=1 ./scripts/deploy.sh staging i porównaj wypisane komendy ze swoim runbookiem. Sprawdź kolejność: migracje przed kubectl set image, zapis stanu przed jakąkolwiek zmianą.

3. Wypisz każdą zmienną środowiskową, której używają skrypty, i potwierdź, że każda istnieje w docelowym środowisku:

   grep -ohE '\$\{?[A-Z_][A-Z0-9_]*\}?' scripts/deploy.sh scripts/rollback.sh | tr -d '${}' | sort -u

4. Wdróż na staging z CI, potem uruchom ./scripts/rollback.sh staging i potwierdź, że działa poprzedni tag, a smoke test przechodzi. Rollback, którego nigdy nie uruchomiłeś, to tylko hipoteza.

Zautomatyzuj przełączenie blue-green z rollbackiem sterowanym metryką

Przełączenie ruchu bez sygnału o zdrowiu serwisu tylko przesuwa ryzyko. O skuteczności tego promptu decydują endpoint monitoringu i próg: dzięki nim skrypt decyduje na podstawie prawdziwego odsetka błędów, zamiast liczyć na szczęście.

Prompt do skopiowania: blue-green z automatycznym rollbackiem

We run two Kubernetes deployments, myapp-blue and myapp-green, behind the Service myapp.
Write scripts/blue-green.sh that:
1. Reads the Service selector to find which colour is live.
2. Deploys the new image (argument 1) to the idle colour and waits until every pod passes its readiness probe.
3. Switches the Service selector to the idle colour and logs the time of the switch.
4. For 5 minutes, queries Prometheus at $PROMETHEUS_URL every 15 seconds for the 5xx ratio of the myapp job.
5. If the ratio is above 1% in two consecutive samples, switches the selector back, logs both values, and exits 1.
6. Leaves the old colour running until a separate cleanup step, so a manual switch back stays instant.
Support DRY_RUN=1. Exit 1 on any error before the switch, without touching the Service.

Udowodnij, że automatyczny rollback zadziała, zanim zaczniesz na nim polegać. Na stagingu wdróż obraz, którego /health przechodzi, ale trasy API zwracają 500, i potwierdź, że skrypt przełącza ruch z powrotem w oknie monitorowania i kończy się kodem 1. Próg i okno wybierz na podstawie swojego SLO, a nie tego przykładu. Canary, feature flagi i budżet zasięgu awarii dla każdej klasy ryzyka opisuje progressive delivery dla zmian pisanych przez agentów.

Generuj changelog i release notes z historii gita

Pisanie changeloga to miejsce, w którym Claude Code oszczędza najwięcej nudnej pracy przy najmniejszym ryzyku, bo każdą linię da się sprawdzić z commitem. Przekaż log na wejście i określ format.

# Terminal: draft a CHANGELOG entry from the commits since the last tag
git log --no-merges --format='%h %s' "$(git describe --tags --abbrev=0)..HEAD" | \
  claude -p "Draft a CHANGELOG.md entry from these commits, dated $(date +%F).
Group under Added, Changed, Fixed and Removed. One line per user-visible change, in past tense.
Keep the PR number, for example (#412), when the subject has one. Skip version bumps and CI-only commits.
After the entry, list every commit hash you left out and why." \
  --output-format text > "${TMPDIR:-/tmp}/changelog-draft.md"

Ostatnia instrukcja to punkt zaczepienia dla weryfikacji: lista pominiętych commitów pozwala sprawdzić pokrycie w kilka sekund, zamiast ponownie czytać cały log.

Procedurę, którą uruchamia cały zespół, zapisz jako skill projektu. Skill zastępuje starszy plik w .claude/commands/; oba tworzą komendę slash, a różnice opisuje strona własne komendy i skille.

Skill do skopiowania: /release-notes

Zapisz jako .claude/skills/release-notes/SKILL.md, a potem uruchom w sesji /release-notes 2.5.0.

---
name: release-notes
description: Drafts release notes for a version from the commits since the last tag. Use when cutting a release.
disable-model-invocation: true
allowed-tools: Bash(git log *) Bash(git describe *)
---

## Last release tag

Last release tag: !`git describe --tags --abbrev=0`

## Instructions

Write release notes for version $ARGUMENTS. First run git log --no-merges --format='%h %an %s' <tag>..HEAD, with the tag above, to list the commits since the last release.

1. Group changes under Features, Fixes, Performance and Breaking changes.
2. Rewrite commit subjects as user-facing sentences. Where a subject is too vague to explain the change, read that commit's diff with git log -p -1 <hash>.
3. For every breaking change, add the migration step a user must take.
4. End with a Contributors line listing the commit authors.
5. After the notes, list every commit you left out and why.

Output GitHub release Markdown only. Do not create a tag or publish anything.

disable-model-invocation: true sprawia, że skill uruchamia się tylko wtedy, gdy wpiszesz go sam. To właściwe ustawienie dla wszystkiego, co trafia do wydania.

Diagnozuj nieudane wdrożenie przez MCP i skille platform

Kiedy wdrożenie pada w CI, wklejanie fragmentów logów do sesji gubi kontekst. Zamiast tego daj Claude Code połączenie z pipeline’em tylko do odczytu. Serwer GitHub MCP udostępnia zestaw narzędzi Actions w trybie tylko do odczytu pod osobnym adresem URL:

# Terminal: GITHUB_PAT is a fine-grained token with read access to Actions
claude mcp add --transport http github-actions \
  https://api.githubcopilot.com/mcp/x/actions/readonly \
  -H "Authorization: Bearer $GITHUB_PAT"

Przy wdrożeniu na konkretną platformę skill zawiera jej komendy i konwencje, więc nie musisz ich tłumaczyć od nowa w każdej sesji. Oficjalne skille i plugin Cloudflare instalujesz na przykład z repozytorium cloudflare/skills:

/plugin marketplace add cloudflare/skills
/plugin install cloudflare@cloudflare

Praktyczna reguła: skill najlepiej sprawdza się jako wiedza o tym, jak wykonać jedno zadanie, na przykład wdrożyć na jedną platformę. Serwer MCP jest lepszy, gdy Claude potrzebuje przez całą sesję żywego połączenia z systemem, takim jak przebiegi CI czy zasoby chmurowe. Zestawy narzędzi i tryb lockdown opisuje przewodnik po serwerze GitHub MCP, a integrację z Cloudflare — strona serwery MCP Cloudflare.

Prompt do skopiowania: plan wycofania w incydencie

The deploy of commit abc1234 to production is returning 500 errors on /api/orders since 14:05 UTC.
Using the GitHub Actions runs and the git history, build a rollback plan. Do not run any deploy, rollback or migration command.
1. Identify the last known good release: the tag or SHA that production ran before, with the evidence.
2. List every migration between that release and abc1234, and say whether the old code runs against the new schema.
3. If it does, give the exact rollback command using scripts/rollback.sh. If it does not, give the options: forward fix, down migration, or feature flag, with the risk of each.
4. Name the metrics and log queries that will show recovery, and the values that mean "recovered".

Komendy uruchamia inżynier dyżurny, a metryki powrotu do normy z punktu 4 są zatwierdzeniem. Szerszy proces obsługi incydentów opisuje strona reagowanie na incydenty z AI.

Co się psuje, gdy Claude Code automatyzuje twoje wdrożenia?

Model zgłasza bramkę jako zaliczoną, choć jej nie uruchomił. Podsumowanie to nie kod wyjścia. Naprawa: trzymaj deterministyczne kontrole w shellu z set -e, tak jak w deploy-check.sh, a model zostaw do pytań wymagających osądu, w których odpowiedź cytuje file:line.

Linia werdyktu nigdy się nie dopasowuje. Model owija werdykt w pogrubienie Markdown albo dopisuje po nim zdanie, a bramka zgłasza NO-GO przy czystym wydaniu. To bezpieczny kierunek błędu. Naprawa: zostaw w prompcie „exactly one plain-text line and nothing after it” i przeczytaj plik z werdyktem spod $OUT przed ponownym uruchomieniem. Skrypt zapisuje go poza repozytorium, więc ponowny przebieg nie zablokuje się na własnym sprawdzeniu czystego drzewa.

Bramka w CI sprawdza zły zakres. Płytki checkout nie ma tagów, więc git describe cofa się do płytkiego korzenia i Claude przegląda niewłaściwy diff, a polecenie changelogu od razu kończy się błędem. Naprawa: ustaw fetch-depth: 0 w actions/checkout. Samo fetch-tags: true nie wystarczy, bo git describe potrzebuje też historii między tagiem a HEAD.

Dockerfile działa lokalnie, ale pada w CI. Runner ma zwykle inną architekturę procesora. Naprawa: buduj przez docker buildx build --platform linux/amd64 albo poproś Claude’a o build wieloplatformowy; resztę opisuje strona o konteneryzacji.

Wdrożenie się udaje, a aplikacja pada przy starcie. Claude Code nie widzi zachowania w runtime na środowisku, do którego nie ma dostępu. Naprawa: smoke test w deploy.sh musi trafiać w prawdziwą trasę, nie tylko w /health, a każda zmiana skryptu przechodzi najpierw przez staging.

Na produkcji brakuje zmiennej. Wygenerowane skrypty odwołują się do zmiennych, których nikt nie ustawił. Naprawa: kontrola .env.example w bramce oraz grep z kroków weryfikacji powyżej.

Changelog jest bezużyteczny. Tematy commitów w stylu „fix stuff” dają wpisy w stylu „Fixed stuff”. Naprawa: każ Claude’owi czytać diff przy niejasnych commitach, tak jak robi to skill, i egzekwuj opisowe tematy w code review.

Rollback pada, bo migracja była jednokierunkowa. Wiele ORM-ów domyślnie nie generuje migracji w dół. Naprawa: zrób z expand/contract regułę w CLAUDE.md i uruchamiaj up, down, up na stagingu dla każdej migracji.

Agent i tak dociera do produkcji. Regułę deny ominięto innym zapisem komendy albo produkcyjne poświadczenie leżało w środowisku shella. Naprawa: usuń poświadczenia produkcyjne z maszyn deweloperskich i pozwól trzymać je wyłącznie zadaniu wdrożeniowemu w CI.

Co dalej z automatyzacją wdrożeń

Konfiguracja pipeline'ów z Claude Code Wygeneruj i utwardź pipeline GitHub Actions lub GitLab CI, który uruchamia te skrypty

Claude Code w CI/CD z GitHub Actions Uruchom bramkę przed wdrożeniem w trybie headless w CI z tokenami o minimalnych uprawnieniach

Progressive delivery dla zmian pisanych przez agentów Canary, feature flagi i rollback wyzwalany przez SLO jako siatka pod zmianami, których nie czytałeś

Konfiguracja obserwowalności z CLI Podłącz alerty i dashboardy, które powiedzą ci, czy wdrożenie się udało