Automatyzacja wdrożeń z Codex: kontenery, skrypty wdrożeniowe i rollback

Codex automatyzuje wdrożenia, pisząc i testując całą maszynerię wokół wydania: Dockerfile, test dymny obrazu w CI, skrypty wdrożenia i rollbacku, migracje expand/contract oraz notatkę o ryzyku dla zatwierdzającego. Samo wdrożenie uruchamia pipeline CI za chronionym środowiskiem. Codex nigdy nie dostaje produkcyjnych poświadczeń, a o wydaniu decydują dowody z CI, nie podsumowanie agenta.

Twój proces wdrożenia to strona w wiki z 23 ręcznymi krokami, w tym „zaloguj się przez SSH na serwer i uruchom te cztery polecenia”. Gdy ostatnio ktoś pominął krok 14, produkcja leżała 20 minut, a jedyna osoba, która wiedziała dlaczego, była na urlopie. Ta strona jest dla dewelopera, który odpowiada za ścieżkę wydań swojej usługi, i dla tech leada, który zatwierdza zmiany na produkcji. Zakładamy, że używasz Codex CLI albo aplikacji desktopowej i masz już GitHub Actions; jeśli nie, zacznij od uruchamiania Codex w CI/CD.

Co dostajesz

Podział obowiązków: co pisze Codex, która bramka to potwierdza i kto podpisuje.
Trzy prompty do skopiowania: konfiguracja kontenerów, skrypty wdrożenia i rollbacku, migracja bezpieczna dla rollbacku.
Job CI z testem dymnym, który dowodzi, że obraz się buduje, startuje zdrowy, działa jako nie-root, mieści się w budżecie rozmiaru i czysto się zamyka.
Workflow produkcyjny, w którym Codex pisze notatkę o ryzyku w trybie tylko do odczytu, a wdrożenie zatwierdza konkretna osoba.
Prompt cotygodniowej automatyzacji, która wyłapie psujący się pipeline przed dniem wydania.

Kto co robi, gdy Codex automatyzuje wdrożenie?

Zasada, która utrzymuje to w ryzach: Codex wytwarza artefakty i dowody, a uruchamia je pipeline. Każdy wiersz ma kontrolę, która działa bez czytania wygenerowanego kodu linijka po linijce.

Krok	Co robi Codex	Bramka, która to potwierdza	Kto podpisuje
Konfiguracja kontenerów	Pisze `Dockerfile`, `compose.yaml`, `compose.override.yaml`	Job CI z testem dymnym obrazu (krok 3)	Recenzent PR
Skrypty wdrożenia i rollbacku	Pisze `scripts/deploy.sh`, `scripts/rollback.sh`	`shellcheck`, `--dry-run` w CI, próba rollbacku na stagingu	Właściciel usługi
Migracje	Pisze migracje expand/contract	Testy poprzedniego wydania przechodzą na nowym schemacie	Recenzent PR
Notatki do wydania	Tworzy szkic z `git log`	Człowiek publikuje szkic	Release manager
Wdrożenie produkcyjne	Pisze notatkę o ryzyku tylko do odczytu, nic więcej	Środowisko GitHub z wymaganymi recenzentami	Wskazana osoba zatwierdzająca
Po wdrożeniu	Nic w czasie działania	Test dymny w `deploy.sh`, automatyczny rollback przy błędzie	Dyżurny inżynier

Notatki do wydania mają już utwardzony workflow na stronie o Codex w CI/CD; tutaj go nie powtarzamy.

Jak krok po kroku zautomatyzować wdrożenie z Codex?

Zapisz zasady wdrożeń w AGENTS.md. Codex czyta AGENTS.md, zanim zacznie pracę, więc poniższe ograniczenia trafiają do każdego wątku, zadania w chmurze i uruchomienia w CI. Traktuj je jako wskazówki dla agenta. Zamkami są środowisko i poświadczenia z kroku 6.

## Deployment
- Production deploys run only from `.github/workflows/deploy.yml`. Never run
  `scripts/deploy.sh` without `--dry-run`.
- Images are tagged with the full git SHA. Never deploy or push `:latest`.
- Migrations follow expand/contract: a release may add tables and nullable
  columns; dropping or renaming waits for the release after next.
- Before you call deployment work done, run `shellcheck scripts/*.sh`,
  `scripts/deploy.sh --dry-run "$(git rev-parse HEAD)"` and the test suite,
  and paste the exit codes.
- Test database: `postgres://localhost:5432/app_test` (the `postgres` service
  in `compose.yaml`).

Wygeneruj konfigurację kontenerów. Rozpocznij wątek w Codex CLI albo w aplikacji desktopowej (w worktree, jeśli masz inną pracę w toku) i wklej poniższy prompt. Nazywa ograniczenia, które liczą się na produkcji, więc dostajesz działającą konfigurację, a nie przykład z podręcznika.

Generate production container configuration for this Node.js/TypeScript service.

Dockerfile:
- Multi-stage: deps, build, runtime. Use the Node major version from .node-version
  (or package.json "engines") on an alpine base, pinned to that major.
- Runtime stage: production dependencies only, NODE_ENV=production, non-root user.
- HEALTHCHECK that calls GET /health on port 3000 without installing curl.
- Start node directly (no npm start) so SIGTERM reaches the process; handle SIGTERM
  by closing the HTTP server and DB pool, then exit 0 within 8 seconds.
- Add a .dockerignore that excludes .git, node_modules, tests and .env*.

compose.yaml (production-like, used by CI):
- app: build: . and image: ${APP_IMAGE:-app:local}, a healthcheck, depends_on
  postgres and redis with condition: service_healthy.
- postgres:16 and redis:7, each with a healthcheck. No source volume mounts.

compose.override.yaml (local development only, loaded automatically by Compose):
- Mount src/ for hot reload and run the dev script from package.json.

/health must return 200 only when PostgreSQL and Redis answer, and 503 before that.
Read package.json for the build and start scripts. Do not add a registry push.
When you finish, list every file you created and run `docker compose config` to
show the merged configuration parses.

Udowodnij działanie obrazu w CI, nie w czacie. Podsumowanie wątku „kontener startuje poprawnie” to deklaracja. Dowodem jest poniższy job, uruchamiany przy każdym pull requeście, który dotyka kontenera. Zmienna COMPOSE_FILE trzyma override deweloperski z dala od CI.

name: Image smoke test
on:
  pull_request:
    paths: ['Dockerfile', 'compose*.yaml', 'package*.json', 'src/**']
permissions:
  contents: read
jobs:
  smoke:
    runs-on: ubuntu-latest
    env:
      COMPOSE_FILE: compose.yaml
      APP_IMAGE: app:ci
      MAX_IMAGE_MB: 250
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Build and start the stack
        run: docker compose up --build --wait --wait-timeout 90
      - name: Health endpoint answers
        run: curl -fsS http://localhost:3000/health
      - name: App does not run as root
        run: test "$(docker compose exec -T app id -u)" != "0"
      - name: Image fits the size budget
        run: |
          size_mb=$(( $(docker image inspect "$APP_IMAGE" --format '{{.Size}}') / 1000000 ))
          echo "Image size: ${size_mb} MB"
          test "$size_mb" -le "$MAX_IMAGE_MB"
      - name: Shuts down cleanly on SIGTERM
        run: |
          docker compose stop --timeout 10 app
          code=$(docker inspect --format '{{.State.ExitCode}}' "$(docker compose ps -aq app)")
          echo "Exit code: $code"
          test "$code" = "0"
      - name: Logs on failure
        if: failure()
        run: docker compose logs --no-color

Każdy kod wyjścia inny niż 0 oznacza, że obsługa SIGTERM zawiodła; 137 oznacza konkretnie, że po upływie limitu czasu Docker musiał wysłać SIGKILL. Gdy job się wywróci, wklej jego log do wątku Codex i poproś o poprawkę; kolejny push uruchomi te same kontrole.

Zastąp wiki skryptami wdrożenia i rollbacku. Prompt wymaga trybu dry-run, niezmiennych tagów SHA i automatycznego rollbacku, bo to te trzy cechy pozwalają przetestować skrypt, zanim dotknie produkcji.

Replace docs/deploy-wiki.md with two scripts, scripts/deploy.sh and scripts/rollback.sh.

Both scripts:
- bash with `set -euo pipefail`, shellcheck-clean, a usage message, and a --dry-run
  flag that prints every command instead of running it.
- Read credentials only from environment variables (DEPLOY_TOKEN, DATABASE_URL).
  Fail with a clear message if one is missing. Never echo them.

deploy.sh <git-sha>:
1. Pre-flight: the image registry.example.com/app:<git-sha> exists; the working
   tree is clean; the SHA is on origin/main. Any failure stops a real run; with
   --dry-run, print it as a warning and continue.
2. Record the currently deployed SHA in .deploy/previous-sha before changing anything.
3. Run pending migrations. They are expand-only (see AGENTS.md), so the running
   release keeps working. Stop on any migration error.
4. Roll out the new image with a rolling restart and wait up to 120 seconds for
   /health to return 200 on every instance.
5. Smoke test: GET /health and GET /api/version, which must return <git-sha>.
6. If step 4 or 5 fails, call rollback.sh automatically and exit non-zero.
7. Append one JSON line to .deploy/log.jsonl: timestamp, sha, previous sha, result.

rollback.sh [git-sha]: redeploy the given SHA, or the one in .deploy/previous-sha.
It never runs down-migrations; it relies on expand/contract instead.

Then run `shellcheck scripts/*.sh` and `scripts/deploy.sh --dry-run "$(git rev-parse HEAD)"`
and show me the output and exit codes.

Polecenie restartu kroczącego zależy od platformy. Podaj je w prompcie (kubectl rollout, fly deploy, API load balancera), żeby Codex nie zgadywał. Przed pierwszym uruchomieniem na produkcji przećwicz rollback.sh na stagingu i zapisz wynik w docs/runbooks/rollback-rehearsals.md (data, SHA, rezultat); kontrakt przećwiczonego rollbacku opisuje, co musi oznaczać „przećwiczony”.

Zadbaj, by migracje dało się wycofać. Skrypt rollbacku uruchamiający migracje w dół może zniszczyć dane zapisane przez nowe wydanie. Bezpieczniejszy jest wzorzec expand/contract: wydanie, które dodaje kolumnę, nigdy żadnej nie usuwa, więc poprzedni obraz dalej działa na nowym schemacie, a rollback sprowadza się do podmiany obrazu.

I need to rename users.fullname to users.display_name without downtime.
Split it into expand/contract steps across releases:
- Release N: add display_name (nullable), write both columns, backfill in batches
  of 1,000 rows, keep reading fullname.
- Release N+1: read display_name, still write both.
- Release N+2: drop fullname.
Write only the Release N migration and code now. For every index you add, say
whether it locks the table on PostgreSQL 16 and use CREATE INDEX CONCURRENTLY
where it would.

Then add a CI job, .github/workflows/schema-compat.yml, that checks out the latest
release tag into a second directory, applies this branch's migrations to a fresh
postgres:16 service container, and runs that release's test suite against it.
The job fails if the previous release's tests fail on the new schema.

Job schema-compat dowodzi, że rollback nadal działa: uruchamia kod, do którego byś wracał, na schemacie, który właśnie tworzysz. Więcej przepisów expand/contract znajdziesz w wzorcach migracji baz danych.

Postaw bramkę produkcji poza modelem. Utwórz w GitHubie środowisko production z wymaganymi recenzentami i trzymaj DEPLOY_TOKEN oraz DATABASE_URL wyłącznie jako sekrety tego środowiska. Codex działa w osobnym jobie tylko do odczytu i zapisuje notatkę o ryzyku w podsumowaniu uruchomienia, więc zatwierdzający czyta jeden ekran zamiast całego diffa. Job wdrożeniowy nigdy nie uruchamia Codex.

name: Deploy
on:
  push:
    branches: [main]
permissions:
  contents: read
concurrency:
  group: production
  cancel-in-progress: false
jobs:
  risk-brief:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          permission-profile: ":read-only"
          prompt: |
            You are writing a deploy risk brief for a human approver.
            Compare ${{ github.event.before }}..${{ github.sha }} with git log and git diff.
            Output Markdown, at most 25 lines:
            1. Risk: low, medium or high, with one sentence why.
            2. Migrations in this range: file names, and whether each is expand-only.
            3. Changed config, environment variables or feature flags.
            4. What the approver should check in staging before approving.
            Do not speculate beyond what the diff shows.
      - name: Publish the brief to the run summary
        env:
          BRIEF: ${{ steps.codex.outputs.final-message }}
        run: printf '%s\n' "$BRIEF" >> "$GITHUB_STEP_SUMMARY"

  deploy:
    needs: risk-brief
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      # Obraz dla tego SHA zbudował i wypchnął Twój workflow budujący.
      - name: Deploy
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
        run: scripts/deploy.sh "$GITHUB_SHA"

Jeśli github.event.before to same zera (pierwszy push gałęzi) albo commit nieosiągalny po force-pushu, zakres jest nieprawidłowy; wskaż wtedy w prompcie git log -1 albo poprzedni tag wydania.

Grupa concurrency nie pozwala dwóm pushom wdrażać jednocześnie, bo wtedy wygrywa ten upload, który wyląduje ostatni. Profil uprawnień :read-only (beta; sprawdzone z codex-action v1.12 i Codex CLI 0.157.1, 2026-09-26) to wejście, które openai/codex-action zaleca zamiast przestarzałego sandbox; domyślna strategia bezpieczeństwa akcji, drop-sudo, pozostaje włączona. Pozostałe opcje utwardzania akcji opisuje strona o Codex w CI/CD.

Zaplanuj cotygodniową kontrolę gotowości wdrożeniowej. Narzędzia wdrożeniowe psują się między wydaniami: przesuwa się obraz bazowy, skrypt przestaje przechodzić shellcheck, migracja nie nakłada się już na pustą bazę. Utwórz automatyzację Codex w aplikacji desktopowej na worktree według przewodnika po automatyzacjach Codex i wklej ten prompt bez zmian, gdy raz uruchomisz go ręcznie.

Weekly deployment readiness check. Do not modify tracked files and do not deploy.

Run each check and record the command, exit code and the first error line:
1. shellcheck scripts/*.sh
2. scripts/deploy.sh --dry-run "$(git rev-parse origin/main)"
3. The Node major in the Dockerfile matches .node-version.
4. Migrations apply from an empty database (use the test database from AGENTS.md).
5. The newest entry in docs/runbooks/rollback-rehearsals.md is under 30 days old.
6. The last three runs of the "Image smoke test" workflow on main passed
   (gh run list --workflow image-smoke.yml --branch main --limit 3).

Output a table: check | PASS or FAIL | evidence. Then, for each FAIL only,
a one-paragraph suggested fix. If everything passes, say so in one line.

Jeśli sandbox automatyzacji nie sięga do demona Dockera albo do sieci, zostaw kontrole obrazu jobowi z testem dymnym w CI; ten prompt odczytuje jego wyniki przez gh zamiast budować obraz od nowa.

Skąd wiesz, że wydanie jest bezpieczne, bez czytania każdej linijki?

Nikt w zespole nie musi czytać wygenerowanego Dockerfile’a ani deploy.sh linijka po linijce. Wydanie jest bezpieczne, gdy spełnione są poniższe warunki, a każdy z nich widać w CI albo w repozytorium:

Zielony test dymny obrazu: obraz się buduje, /health odpowiada, użytkownik nie jest rootem, rozmiar mieści się w budżecie, a SIGTERM kończy proces czysto.
Skrypty sprawdzone przed użyciem: shellcheck przechodzi, deploy.sh --dry-run wypisuje plan, a dziennik prób rollbacku ma wpis młodszy niż 30 dni.
Zielona zgodność schematu: testy poprzedniego wydania przechodzą na nowym schemacie, więc rollback to podmiana obrazu.
Wskazana osoba zatwierdzająca: wymagany recenzent środowiska production czyta notatkę o ryzyku, sprawdza staging i zatwierdza. Notatka jest pomocnicza; bramką jest zatwierdzenie.
Dowody po wdrożeniu: deploy.sh porównuje /api/version z SHA i sam wykonuje rollback, a .deploy/log.jsonl zapisuje każdą próbę.

Właściciel usługi podpisuje skrypty i próbę rollbacku; recenzent środowiska podpisuje każde wydanie. Wersję tej bramki dla wszystkich narzędzi opisuje strona o bramkowaniu produkcji na etapie wdrożenia. Kanarki i automatyczny rollback wyzwalany przez SLO opisuje progressive delivery dla zmian pisanych przez agentów.

Co się psuje, gdy Codex automatyzuje wdrożenia?

Codex melduje „wszystkie kontrole przeszły”, a nic nie zostało uruchomione. Podsumowanie to nie dowód. Prompty na tej stronie wymagają poleceń i kodów wyjścia; jeśli wątek nie pokazuje ani jednego, ani drugiego, poproś Codex o ponowne uruchomienie kontroli i wklejenie wyniku. Źródłem prawdy i tak są joby CI.

Polecenia Dockera nie działają wewnątrz openai/codex-action. Na Linuksie domyślna strategia drop-sudo odbiera dostęp do należących do roota gniazd usług w /run, w tym do demona Dockera (README codex-action, odczyt 2026-09-26). Buduj i uruchamiaj obrazy w zwykłym kroku albo jobie, a Codex daj do przeczytania logi. Nie przełączaj się na safety-strategy: unsafe, żeby odzyskać Dockera.

Obraz buduje się lokalnie, ale nie w CI. Lokalna pamięć warstw ukrywa brakujący plik albo Twój laptop ma ARM, a runner x86. Zostaw --build w CI, ustaw platform: linux/amd64 w usłudze app w compose.yaml (albo przekaż --platform linux/amd64 do docker build), gdy serwery produkcyjne to x86, i poproś Codex o wyjaśnienie pierwszej nieudanej warstwy na podstawie logu.

/health jest zielony, ale usługa nie jest gotowa. Endpoint zdrowia, który od razu zwraca 200, przechodzi każdą kontrolę, a potem serwuje błędy. Prompt kontenerowy uzależnia /health od PostgreSQL i Redisa; jeśli odziedziczyłeś płytką kontrolę, poproś Codex o dodanie sprawdzeń gotowości i zwracanie 503, dopóki nie przejdą.

Rollback się nie udaje, bo schemat się zmienił. Nowe wydanie usunęło albo przemianowało kolumnę i stary obraz nie startuje. Napraw to, wdrażając nową wersję z poprawką (roll forward), albo przywróć usuniętą kolumnę nową migracją. Zapobiegaj temu promptem expand/contract i jobem schema-compat.

Agent ma dostęp do produkcji. Ktoś umieścił DEPLOY_TOKEN w środowisku chmurowym Codex albo w jobie, który uruchamia openai/codex-action. Usuń go, zrotuj i trzymaj wyłącznie jako sekret środowiska production, w którym Codex nigdy nie działa. Właśnie dlatego bramka stoi poza modelem. Gdy Financial Times podał (2026-02-20, źródło wtórne: Engadget), że agent Kiro Amazona postanowił „delete and recreate the environment” i spowodował 13-godzinną awarię AWS Cost Explorer, Amazon nazwał to błędem użytkownika, „specifically misconfigured access controls”. Niezależnie od winy to kontrola dostępu decyduje, co agent może zepsuć.

Następne kroki

Codex w CI/CD z GitHub Action Przegląd PR, strukturalna bramka bezpieczeństwa, notatki do wydania i automatyczne poprawki w CI, z ochroną sekretów.

Środowiska chmurowe Codex Skrypty konfiguracyjne, sekrety dostępne tylko podczas konfiguracji środowiska i dostęp agenta do internetu.

Konteneryzacja z agentami AI Utwardzone Dockerfile’e, manifesty Kubernetes oraz serwery MCP Dockera i Kubernetesa, dla wszystkich trzech narzędzi.

Wdrożenia z Claude Code To samo zadanie w Claude Code: Dockerfile’e, wdrożenia na wiele środowisk i rollback.