Automatyzacja wdrożeń z Claude Code

Twój zespół właśnie zmergował dużego feature brancha. Deploy na staging poszedł gładko, ale produkcja wymaga innego tagu Docker, trzech zmiennych środowiskowych, których nigdy nie pamiętasz, migracji bazy danych, która musi się wykonać przed startem nowego kodu, i powiadomienia na Slacku po zakończeniu. Ostatnim razem ktoś pomylił tag obrazu i wdrożył build z ubiegłego wtorku. Poprzednim razem migracja uruchomiła się po deployu i użytkownicy widzieli błędy 500 przez jedenaście minut. Wdrożenia nie powinny wymagać listy kontrolnej przyklejonej do monitora.

Czego się nauczysz

• Powtarzalny workflow promptów do generowania skryptów deploy, Dockerfile’ów i pipeline’ów GitHub Actions z Claude Code
• Prompty do skopiowania generujące konfiguracje specyficzne dla środowisk, kroki wdrożenia blue-green i automatyczne wyzwalacze wycofania
• Standard wdrożeniowy sterowany przez CLAUDE.md, którego Claude Code przestrzega za każdym razem, aby nowi inżynierowie otrzymywali taką samą jakość od pierwszego dnia

Generowanie produkcyjnego Dockerfile

Większość Dockerfile’ów dla Node.js zaczyna się jako kopiuj-wklej ze Stack Overflow i nigdy się nie poprawia. Claude Code potrafi wygenerować zoptymalizowany, wieloetapowy build bezpośrednio z twojego package.json i struktury źródłowej.

Wskazówka

Prompt do skopiowania — produkcyjny Dockerfile:

Look at my package.json, tsconfig, and source directory structure. Generate a production Dockerfile with a multi-stage build: stage 1 installs and compiles, stage 2 copies only the compiled output and production node_modules. Use node:20-alpine, create a non-root user, add a HEALTHCHECK on /health, and use tini as the entrypoint for proper signal handling. Put a .dockerignore next to the Dockerfile.

Claude Code czyta pliki twojego projektu, wykrywa czy używasz npm, yarn czy pnpm na podstawie obecnego lockfile’a i tworzy Dockerfile dostosowany do twojego faktycznego stacku — nie generyczny szablon. Jeśli masz katalog prisma/, doda krok Prisma generate; jeśli masz folder public/, skopiuje statyczne zasoby we właściwe miejsce.

Po wygenerowaniu pliku przez Claude, zweryfikuj go lokalnie:

docker build -t myapp:test . && docker run --rm -p 3000:3000 myapp:test

Następnie poproś Claude Code o iterację:

The image is 340 MB. Reduce the size by switching the runtime stage to distroless or alpine with only the minimal packages needed.

Ta pętla — generuj, buduj, mierz, poprawiaj — to moment, w którym Claude Code naprawdę błyszczy. Każda iteracja trwa sekundy, ponieważ Claude ma już pełny kontekst.

Skryptowanie wdrożeń w wielu środowiskach

Rzeczywiste projekty mają co najmniej trzy środowiska: development, staging, produkcja. Różnice konfiguracyjne między nimi są stałym źródłem błędów.

Wskazówka

Prompt do skopiowania — skrypt deploy z macierzą środowisk:

Generate a deploy.sh script that accepts an environment argument (dev, staging, prod). For each environment, it should: 1) source the correct .env file from deploy/envs/, 2) build and push the Docker image tagged with the git SHA and environment name, 3) run database migrations against the environment's DATABASE_URL, 4) deploy to the correct Kubernetes namespace using kubectl set image, 5) wait for the rollout to complete, 6) run a smoke test against the health endpoint. If any step fails, print a clear error and exit 1 without continuing. Use our existing ECR registry at 123456789.dkr.ecr.us-east-1.amazonaws.com.

Claude Code tworzy skrypt shellowy obsługujący cały cykl życia. Co kluczowe, kończy działanie wcześniej w przypadku błędu zamiast kontynuować i tworzyć stan połowicznego wdrożenia. Możesz przekierować wyjście tego skryptu na Slacka lub do logu CI.

Dla zespołów używających infrastructure-as-code, poproś Claude Code o wygenerowanie odpowiednika w Terraform lub Pulumi:

Convert this deploy.sh approach into a Pulumi TypeScript program that manages the same three environments as stacks. Use the aws and kubernetes providers.

Pipeline GitHub Actions od zera

Claude Code ma dogłębną wiedzę o składni GitHub Actions, włącznie z reużywalnymi workflow, regułami ochrony środowisk i kontrolą współbieżności. Zamiast kopiować plik YAML z innego repozytorium i liczyć, że zadziała, opisz czego potrzebujesz.

Wskazówka

Prompt do skopiowania — pełny pipeline CI/CD:

Create a GitHub Actions workflow at .github/workflows/deploy.yml. On pull request to main, run lint, type-check, and test jobs in parallel. On push to main (after merge), build a Docker image, push to GHCR, deploy to staging automatically, wait 5 minutes, run integration tests against staging, then require a manual approval step before deploying to production. Use OIDC for AWS authentication instead of static keys. Tag the Docker image with both the git SHA and 'latest'. Add a concurrency group so only one deploy runs at a time.

Claude Code generuje kompletny plik workflow. Kilka rzeczy do zweryfikowania po wygenerowaniu:

1. Sprawdź, czy blok permissions zawiera id-token: write dla OIDC i packages: write dla GHCR.
2. Potwierdź, że blok environment: production jest obecny w jobie wdrażania produkcyjnego — to właśnie włącza bramkę zatwierdzenia ręcznego w GitHub.
3. Zweryfikuj, że grupa współbieżności używa ${{ github.workflow }}-${{ github.ref }}, aby deploye PR i deploye main nie blokowały się nawzajem.

Wdrożenia blue-green

Wdrażanie bez przestoju brzmi świetnie, dopóki nie musisz sam zaimplementować przełączenia ruchu. Claude Code potrafi wygenerować pełny skrypt orkiestracji blue-green włącznie z walidacją kondycji.

We run two Kubernetes deployments: myapp-blue and myapp-green. Write a blue-green deploy script that determines which deployment is currently receiving traffic from the myapp Service, deploys the new image to the inactive deployment, waits for all pods to pass readiness checks, switches the Service selector to the new deployment, then monitors error rates for 2 minutes via our Prometheus endpoint. If the error rate exceeds 1%, switch traffic back to the old deployment and exit 1.

Kluczowa kwestia to poinformowanie Claude Code o twoim endpoincie monitoringu. Bez tego skrypt po prostu przełączyłby ruch i liczył na najlepsze. Z nim dostajesz automatyczne wycofanie oparte na rzeczywistych danych.

Procedury wycofania

Każdy skrypt deploy powinien mieć odpowiadający mu rollback. Claude Code potrafi wygenerować oba jednocześnie.

Wskazówka

Prompt do skopiowania — para deploy + rollback:

Generate two scripts: deploy.sh and rollback.sh. deploy.sh should record the current image tag in a .last-deploy file before deploying the new version. rollback.sh should read .last-deploy and redeploy that image, then run the reverse database migration if one exists. Both scripts should send a notification to our #deploys Slack channel using the SLACK_WEBHOOK_URL environment variable.

Ten wzorzec — zapisywanie stanu przed jego zmianą — to coś, co doświadczeni inżynierowie budują instynktownie, ale juniorzy często pomijają. Claude Code uwzględnia to, gdy prosisz o parę rollback, ponieważ styl w twoim CLAUDE.md (lub sam prompt) jawnie definiuje to wymaganie.

Kodowanie standardów w CLAUDE.md

Prawdziwa siła Claude Code w kontekście wdrożeń to spójność. Dodaj standardy wdrożeniowe do CLAUDE.md swojego projektu:

## Deployment Standards

- All Docker images must use multi-stage builds with a non-root user
- Production deploys require a health check validation step
- Every deploy script must have a corresponding rollback script
- Database migrations run BEFORE the new code is deployed
- All deploy scripts exit on first error (set -euo pipefail)
- Image tags use git SHA, never 'latest' in production
- Secrets come from environment variables, never hardcoded

Z tymi regułami na miejscu, każdy prompt do Claude Code dotyczący wdrożenia automatycznie dziedziczy te ograniczenia. Nowy inżynier pytający “create a deploy script for the payments service” otrzymuje taką samą jakość wyników, jaką napisałby senior.

Gdy coś idzie nie tak

Claude generuje Dockerfile, który działa lokalnie, ale nie w CI. Zazwyczaj dzieje się tak, ponieważ runner CI ma inną architekturę (ARM vs x86). Dodaj --platform linux/amd64 do kroku budowania lub poproś Claude Code o dodanie wieloplatformowego builda docker buildx.

Skrypt deploy kończy się sukcesem, ale aplikacja crashuje na starcie. Claude Code nie widzi zachowania runtime. Po wygenerowaniu skryptu deploy zawsze uruchom go w środowisku nieprodukcyjnym. Dodaj krok smoke testu (curl na health endpoint, sprawdź kod wyjścia) i poproś Claude o dodanie go, jeśli tego nie zrobił.

Workflow GitHub Actions spala zbyt wiele minut. Claude Code jest dokładny, co czasami oznacza uruchamianie testów sekwencyjnie, gdy mogłyby być równoległe. Powiedz Claude o swoim ograniczeniu: “Our GitHub Actions budget is limited, so use a matrix strategy and run lint/type-check/test as separate jobs that start simultaneously.”

Brakuje zmiennych środowiskowych na produkcji. Claude Code generuje odwołania do zmiennych środowiskowych, ale nie może zweryfikować, czy istnieją w twoim celu wdrożeniowym. Po wygenerowaniu skryptu deploy uruchom grep -oP 'DOLLAR_SIGN{?\K[A-Z_]+' deploy.sh (zastępując DOLLAR_SIGN rzeczywistym znakiem), aby wylistować wszystkie używane zmienne i potwierdzić, że każda jest ustawiona.

Co dalej

Konfiguracja pipeline CI/CD Głębokie zanurzenie w projektowanie pipeline z Claude Code, włącznie z równoległym uruchamianiem testów i cache'owaniem

Konteneryzacja z Docker i Kubernetes Od Dockerfile do Helm chart -- pełny workflow kontenerowy z Claude Code

Monitoring i obserwowalność Skonfiguruj alerty i dashboardy, które powiedzą ci, czy deploy faktycznie zadziałał