Automatyzacja wdrożeń z Codex

Twój proces wdrożenia to strona wiki z 23 ręcznymi krokami, w tym “SSH na serwer i uruchom te cztery polecenia”. Ostatnim razem, gdy ktoś pominął krok 14, produkcja była niedostępna przez 20 minut. Musisz konteneryzować aplikację, zautomatyzować pipeline wdrożeniowy i upewnić się, że każde wydanie jest powtarzalne, testowalne i odwracalne. Codex może wygenerować konfigurację Docker, napisać skrypty wdrożeniowe i zwalidować wszystko w środowisku chmurowym, zanim trafi na produkcję.

Czego się nauczysz

• Prompty do generowania gotowych na produkcję Dockerfile’ów i konfiguracji compose
• Przepływ pracy do walidacji skryptów wdrożeniowych w środowiskach chmurowych Codex
• Techniki używania Codex GitHub Action do automatyzacji przygotowania wydań
• Przepis na automatyzację cotygodniowych kontroli gotowości wdrożeniowej

Przepływ pracy

Krok 1: Wygeneruj konfigurację kontenerów

Zacznij z wątkiem Local w aplikacji Codex. Podaj Codex twoje obecne ograniczenia wdrożeniowe, aby wygenerował praktyczną konfigurację, a nie podręcznikowy przykład.

Wskazówka

Prompt do skopiowania — konfiguracja Docker:

Generate production Docker configuration for this Node.js/TypeScript project:

Dockerfile requirements:
- Multi-stage build: dependencies stage, build stage, production stage
- Use node:20-alpine as the base
- Install only production dependencies in the final stage
- Run as non-root user
- Include health check endpoint (GET /health on port 3000)
- Set NODE_ENV=production
- Handle SIGTERM for graceful shutdown

docker-compose.yml for local development:
- App service with hot reload (mount src/ as volume)
- PostgreSQL 16 with persistent volume
- Redis 7 for session storage
- Proper dependency ordering (app depends on db and redis)

docker-compose.prod.yml (production overrides):
- No volume mounts
- Resource limits (memory, CPU)
- Restart policy: unless-stopped
- Environment variables from .env.production

Read the current package.json for the build and start scripts.

Krok 2: Zwaliduj w chmurze

Zanim zaufasz konfiguracji Docker, zwaliduj ją w środowisku chmurowym Codex. Zadania w chmurze same działają w kontenerach, co czyni je idealnymi do testowania budowania kontenerów.

codex cloud exec --env deployment-test "Build the Docker image using the Dockerfile we generated. Run the container and verify:
1. The health check endpoint responds with 200
2. The application can connect to PostgreSQL (use the compose database)
3. The container starts in under 10 seconds
4. The container shuts down gracefully on SIGTERM (no orphaned connections)
5. The final image size (should be under 200MB for an Alpine-based Node image)

Report the results for each check."

Krok 3: Wygeneruj skrypty wdrożeniowe

Zastąp 23-krokową stronę wiki zautomatyzowanymi skryptami:

Wskazówka

Prompt do skopiowania — generowanie skryptu wdrożeniowego:

Create a deployment script at scripts/deploy.sh that automates our production deployment:

1. Pre-flight checks:
   - Verify the current branch is main
   - Verify all tests pass (npm test)
   - Verify the Docker image builds successfully
   - Verify no uncommitted changes

2. Build and tag:
   - Build the Docker image with the git SHA as the tag
   - Tag as both :latest and :<git-sha>

3. Database migration:
   - Run pending migrations against the production database
   - Verify migrations completed successfully
   - If migration fails, exit with error (do not proceed to deployment)

4. Deploy:
   - Push the new image to the registry
   - Update the running container with zero-downtime (rolling restart)
   - Wait for health check to pass on the new container

5. Post-deployment:
   - Verify the deployed version matches the expected git SHA
   - Run a smoke test (curl the health endpoint and one API endpoint)
   - Log the deployment to a file with timestamp, SHA, and status

Include a rollback script (scripts/rollback.sh) that reverts to the previous image tag.
Make both scripts executable and include error handling at every step.

Krok 4: Automatyzuj przygotowanie wydań z GitHub Action

Użyj Codex GitHub Action do automatycznego przygotowywania wydań, gdy PR jest scalany do main:

name: Release preparation
on:
  push:
    branches: [main]

jobs:
  prepare-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Prepare release with Codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Analyze all commits since the last git tag. Generate:
            1. A changelog entry following Keep a Changelog format
            2. A suggested version bump (major/minor/patch) based on the changes
            3. A release summary suitable for a GitHub Release description

            Output the results in a structured format.
          sandbox: read-only
          safety-strategy: drop-sudo

Krok 5: Zaplanuj kontrole gotowości wdrożeniowej

Skonfiguruj automatyzację w aplikacji Codex, która weryfikuje zdrowie twojego pipeline wdrożeniowego:

Wskazówka

Prompt automatyzacji do skopiowania — gotowość wdrożeniowa:

Weekly deployment readiness check:

1. Verify the Dockerfile builds successfully (docker build .)
2. Verify docker-compose.yml starts all services (docker compose up -d --wait)
3. Run the health check endpoint
4. Run the smoke test script if it exists
5. Check that scripts/deploy.sh and scripts/rollback.sh are executable and have no syntax errors
6. Verify that the database migration can run from a clean state (fresh database)

Report any failures with specific error messages and suggested fixes.
If everything passes, report that deployment infrastructure is healthy.

Kiedy to nie działa

Build Docker działa lokalnie, ale nie w CI. Typowe przyczyny: lokalny cache Docker dostarczający warstwy, których CI nie ma, lub różnice architektur (ARM vs x86). Dodaj --no-cache do kroku budowania w CI i jawnie określ --platform linux/amd64, jeśli twoje CI działa na innej architekturze.

Krok migracji bazy danych trwa zbyt długo na produkcji. Jeśli migracja dodaje indeks na dużej tabeli, może blokować tabelę przez cały czas trwania. Zawsze testuj czas trwania migracji wobec danych o rozmiarze produkcyjnym w środowisku chmurowym przed wdrożeniem. Uwzględnij “estimate migration duration based on table size” w promptach generowania migracji.

Health check przechodzi, ale aplikacja tak naprawdę nie jest gotowa. Podstawowy health check zwracający 200 natychmiast nie weryfikuje, czy połączenia z bazą danych są ustanowione lub cache’e są rozgrzane. Powiedz Codex: “The health check should verify database connectivity, Redis connectivity, and that the application has completed initialization. Return 503 until all dependencies are ready.”

Skrypt rollbacku nie uwzględnia migracji bazy danych. Jeśli wdrożyłeś nową wersję ze zmianą schematu i musisz cofnąć, stary kod może nie działać z nowym schematem. Uwzględnij migracje down w procesie wdrożeniowym i upewnij się, że skrypt rollbacku je uruchamia.

Co dalej

CI/CD z Codex GitHub Action Buduj kompleksowe pipeline'y CI/CD z Codex GitHub Action

Skanowanie bezpieczeństwa z Codex Dodaj kontrole bezpieczeństwa do pipeline wdrożeniowego