Start FastAPI app via Uvicorn

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

This multi-stage Dockerfile follows best practices:

- Uses a builder stage to compile dependencies cleanly.
- Copies only the final packages into a minimal Alpine runtime.
- Runs as a non-root user for security.
- Reduces image size and rebuild time by caching dependency layers.

Claude’s reasoning ensures every line serves a clear purpose. If you change your dependencies, Claude can automatically update only the relevant build stage rather than the entire image.

deploy.sh

This script automates building, tagging, and deploying your container to production or a test environment.

#!/usr/bin/env bash

deploy.sh — build, tag, and deploy the TaskFlow API container

Usage: ./deploy.sh [tag]

Example: ./deploy.sh staging v1.2.0

set -euo pipefail

ENVIRONMENT=${1:-"staging"}

TAG=${2:-"latest"}

APP_NAME="taskflow"

REGISTRY="ghcr.io/your-org"

IMAGE="$REGISTRY/${APP_NAME}:${TAG}"

echo "[INFO] Building Docker image..."

docker build -t "${IMAGE}" .

echo "[INFO] Pushing image to registry..."

docker push "${IMAGE}"

echo "[INFO] Deploying $AP{P}_{N}AME(${TAG}) to ${ENVIRONMENT} environment..."

docker rm -f "${APP_NAME}" >/dev/null 2>&1 || true

Run container with environment-specific variables

docker run -d \

--name "${APP_NAME}" \

--restart unless-stopped \

-p 8000:8000 \

-e ENVIRONMENT="${ENVIRONMENT}" \

-e LOG_LEVEL="info" \

"${IMAGE}"

echo "[INFO] Waiting for health check..."

for i in {1..10}; do

if curl -fsS "http://localhost:8000/health" >/dev/null; then

echo "[SUCCESS] ${APP_NAME} deployed and healthy!"

exit 0

fi

sleep 2

done

echo "[ERROR] Health check failed; printing logs."

docker logs "${APP_NAME}" || true

exit 1

This script can be run locally, in CI/CD pipelines, or through Claude’s reasoning layer to automatically generate version tags and release summaries. Claude can even add rollback logic upon request.

Clarification Table: Best Practices for Docker and Deployment Automation

| Goal | Claude’s Assistance | Practical Outcome |
| --- | --- | --- |
| Optimize image builds | Detects redundant layers, recommends multi-stage builds | Smaller, faster builds |
| Enforce security | Removes root privileges, installs only needed packages | Reduced attack surface |
| Maintain environment parity | Generates .en v templates for staging/production | Consistent deployments |
| Automate rollbacks | Suggests version tagging and health checks | Safe redeploys |
| Reduce costs | Proposes lightweight base images | Lower registry and bandwidth usage |

Writing Dockerfiles and deployment scripts is no longer a repetitive task when working with Claude Code—it becomes an intelligent, iterative conversation. Instead of memorizing every command or syntax rule, you define intent (“secure, fast, portable”), and Claude translates that into practical, runnable infrastructure logic.

By combining Claude’s reasoning power with containerization best practices, you gain reliable automation that’s transparent, auditable, and production-ready. In the next section, you’ll extend these principles to automated scaling and monitoring, using Claude to reason about load patterns, performance metrics, and self-healing infrastructure.

## 8.3 Claude-Assisted CI/CD Pipeline Configuration
Continuous Integration and Continuous Deployment (CI/CD) pipelines are the beating heart of modern software delivery. They ensure that every code change is built, tested, and deployed automatically with minimal human intervention. However, setting up and maintaining a pipeline that is both efficient and secure can be complex—especially when balancing testing depth, build speed, and cost.

This is where Claude Code becomes an invaluable DevOps collaborator. Claude doesn’t just write YAML or Bash; it reasons through workflows, dependencies, and environments. It explains the “why” behind each configuration, spots inefficiencies, and produces deploy-ready pipelines that follow best practices. In this section, you’ll learn how to use Claude to design and implement a reliable CI/CD pipeline that integrates testing, containerization, and cloud deployment—all while maintaining auditability and cost control.

Concept Development

The purpose of CI/CD is to make deployment predictable, fast, and reversible. A mature pipeline follows this general pattern:

1. Code → Build → Test → Deploy → Verify.
2. Each stage runs automatically on commit.
3. Failures stop the pipeline before reaching production.

Claude can assist across every layer of this sequence by:

- Generating clean CI/CD configuration files (GitHub Actions, GitLab CI, Jenkins, or CircleCI).
- Analyzing pipeline bottlenecks such as redundant build steps or unnecessary dependency installs.
- Proposing parallel jobs to reduce runtime.
- Integrating secret management securely without exposing credentials.
- Producing rollback strategies and post-deployment checks.

Claude also ensures the pipeline adheres to least privilege principles—for example, limiting tokens, using minimal runners, and sanitizing environment variables.

Let’s now build a Claude-guided pipeline for our TaskFlow API project that integrates container builds, automated tests, and deployment to production.

Hands-On Example: Building a Claude-Assisted CI/CD Pipeline

Suppose you start with this prompt:

“Claude, generate a robust GitHub Actions CI/CD workflow for a FastAPI app with Docker. It should build and test the code, push to GHCR, and deploy to production if tests pass. Add health checks, rollback logic, and environment variables for secrets.”

Claude would reason through this and produce a complete, valid YAML file.

.github/workflows/deploy.yml
```yaml
name: TaskFlow CI/CD

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  workflow_dispatch:

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}/taskflow

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          python -m venv .venv
          source .venv/bin/activate
          pip install -r requirements.txt

      - name: Run tests
        run: |
          source .venv/bin/activate
          pytest -q || (echo "Tests failed"; exit 1)

  docker:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            $env.REGISTRY/${{ env.IMAGE_NAME }}:latest
            $env.REGISTRY/${{ env.IMAGE_NAME }}:${{ github.sha }}

  deploy:
    needs: docker
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: SSH Deploy to Server
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          script: |
            set -e
            cd /srv/taskflow
            ./deploy.sh ghcr.io/$github.repository/taskflow:${{ github.sha }}
            sleep 5
            if curl -fsS "http://127.0.0.1:8000/health"; then
              echo "✅Deployment successful"
            else
              echo "⚠️Deployment failed, rolling back"
              ./rollback.sh
            fi

This configuration ensures:

• All commits to main trigger automated builds and tests.
• Docker images are tagged with both latest and commit SHA for reproducibility.
• Deployments happen only after successful builds and tests.
• A rollback occurs automatically if the health check fails.

Claude can further explain why each section exists, helping you learn the underlying DevOps logic instead of memorizing syntax.

Hands-On Example: Claude-Assisted Rollback Script

If the health check fails during deployment, Claude can generate a simple rollback script that restores the previous version:

#!/usr/bin/env bash

# rollback.sh — revert TaskFlow container to last stable version
set -euo pipefail

APP_NAME="taskflow"

PREV_IMAGE=$(docker images --format "{{.Repository}}:{{.Tag}}" | grep taskflow | head -n 2 | tail -n 1)

if [[ -z "$PREV_IMAGE" ]]; then
  echo "[ERROR] No previous image found for rollback."
  exit 1
fi

echo "[INFO] Rolling back to $PREV_IMAGE"

docker rm -f "$APP_NAME" >/dev/null 2>&1 || true

docker run -d --name "$AP{P}_{N}AME"-p8000:8000"$PREV_IMAGE"

echo "[SUCCESS] Rollback complete. Service restored."

Claude can even help you integrate this rollback automatically into your CI/CD pipeline, reducing downtime and ensuring safer deployments.

Clarification Table: CI/CD Pipeline Elements and Claude’s Role

Claude transforms CI/CD configuration from a trial-and-error process into a guided engineering experience. It not only writes the code for automation but teaches you how each part fits into a resilient DevOps workflow.By reasoning about dependencies, versions, and environments, Claude creates pipelines that are clear, maintainable, and audit-ready.

In the next section, you’ll extend these principles to multi-environment orchestration, where Claude helps manage separate configurations for development, staging, and production while ensuring consistency and cost efficiency across all tiers.