Expert Deployment Bot

A deployment engineering agent that automates and optimizes application deployment processes, covering CI/CD pipeline design, blue-green deployments, canary releases, rollback strategies, and deployment observability.

When to Use This Agent

Choose Expert Deployment Bot when:

• Setting up CI/CD pipelines for automated deployments
• Implementing deployment strategies (blue-green, canary, rolling)
• Designing rollback procedures and automated recovery
• Optimizing deployment speed and reducing deployment risk
• Integrating deployment with monitoring and alerting

Consider alternatives when:

• Building infrastructure (use a cloud architect or IaC agent)
• Debugging application code (use a debugging agent)
• Managing Kubernetes specifically (use a Kubernetes specialist)

Quick Start

Copy
# .claude/agents/expert-deployment-bot.yml
name: Expert Deployment Bot
description: Automate and optimize deployment processes
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep

Example invocation:

claude "Set up a deployment pipeline for our Node.js app with staging and production environments, canary releases, automated rollback on error rate spike, and Slack notifications"

Core Concepts

Deployment Strategy Comparison

Strategy	Risk	Downtime	Rollback Speed	Complexity
Rolling	Medium	Zero	Medium (minutes)	Low
Blue-Green	Low	Zero	Instant (switch)	Medium
Canary	Very Low	Zero	Instant (route)	High
Recreate	High	Yes	Slow (redeploy)	Lowest
A/B Testing	Low	Zero	Instant (route)	High

CI/CD Pipeline Design

Copy
# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image_tag: ${{ steps.meta.outputs.tags }}
    steps:
      - uses: actions/checkout@v4
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ steps.meta.outputs.tags }}

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Deploy to staging
        run: |
          kubectl set image deployment/myapp \
            myapp=${{ needs.build.outputs.image_tag }} \
            --namespace staging
      - name: Run smoke tests
        run: |
          npx wait-on https://staging.myapp.com/health
          npm run test:smoke -- --base-url https://staging.myapp.com

  deploy-canary:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy canary (10% traffic)
        run: |
          kubectl set image deployment/myapp-canary \
            myapp=${{ needs.build.outputs.image_tag }} \
            --namespace production
          kubectl scale deployment/myapp-canary --replicas=1

      - name: Monitor canary (5 minutes)
        run: |
          sleep 300
          ERROR_RATE=$(curl -s 'http://prometheus:9090/api/v1/query?query=rate(http_errors_total{deployment="canary"}[5m])')
          if [ "$(echo "$ERROR_RATE > 0.01" | bc)" -eq 1 ]; then
            echo "Canary error rate too high, rolling back"
            kubectl scale deployment/myapp-canary --replicas=0
            exit 1
          fi

      - name: Promote to full rollout
        run: |
          kubectl set image deployment/myapp \
            myapp=${{ needs.build.outputs.image_tag }} \
            --namespace production
          kubectl scale deployment/myapp-canary --replicas=0

Rollback Automation

Copy
#!/bin/bash
# scripts/auto-rollback.sh

DEPLOYMENT="myapp"
NAMESPACE="production"
ERROR_THRESHOLD=0.05
CHECK_INTERVAL=30

while true; do
  ERROR_RATE=$(kubectl exec -n monitoring prometheus-0 -- \
    promtool query instant \
    'rate(http_requests_total{status=~"5.."}[2m]) / rate(http_requests_total[2m])')

  if (( $(echo "$ERROR_RATE > $ERROR_THRESHOLD" | bc -l) )); then
    echo "Error rate $ERROR_RATE exceeds threshold $ERROR_THRESHOLD"
    echo "Rolling back deployment..."

    kubectl rollout undo deployment/$DEPLOYMENT -n $NAMESPACE
    kubectl rollout status deployment/$DEPLOYMENT -n $NAMESPACE

    # Notify team
    curl -X POST "$SLACK_WEBHOOK" \
      -H 'Content-Type: application/json' \
      -d "{\"text\": \"Auto-rollback triggered for $DEPLOYMENT. Error rate: $ERROR_RATE\"}"
    exit 1
  fi

  sleep $CHECK_INTERVAL
done

Configuration

Parameter	Description	Default
strategy	Deployment strategy (rolling, blue-green, canary)	rolling
ci_provider	CI/CD platform (github-actions, gitlab, jenkins)	github-actions
container_registry	Image registry (ecr, acr, ghcr, dockerhub)	Auto-detect
orchestrator	Deployment platform (kubernetes, ecs, app-service)	Auto-detect
rollback_trigger	Auto-rollback metric (error-rate, latency, health)	error-rate
notification_channel	Alert destination (slack, teams, email)	slack

Best Practices

1. Deploy to staging automatically, require approval for production. Every merge to main should trigger an automated staging deployment with smoke tests. Production deployments should require explicit approval (GitHub environment protection rules, manual gate). This creates a consistent flow where every change is tested in staging before a human decides to promote it.

2. Start with rolling deployments and upgrade to canary only when you have observability. Canary deployments require robust monitoring to detect issues in the canary traffic. Without metrics on error rate, latency, and business KPIs split by deployment version, you cannot tell whether the canary is healthy. Implement rolling deployments first, build observability, then add canary routing when you can measure its health.

3. Make every deployment reversible within 5 minutes. Rollback should be a single command or automatic trigger, not a process. For container deployments, kubectl rollout undo or ECS service rollback. For serverless, Lambda version aliases. For database migrations, design migrations to be backward-compatible so rollback does not require a data migration. Test the rollback procedure as part of the deployment pipeline.

4. Include deployment metadata in every released artifact. Tag Docker images, Lambda versions, and deployment manifests with: git commit SHA, build number, timestamp, and branch name. This traceability lets you answer "what code is running in production right now?" instantly. Include a /version or /health endpoint that returns this metadata for quick verification.

5. Separate application deployment from infrastructure deployment. Application code changes (new features, bug fixes) should deploy independently from infrastructure changes (new services, network modifications). Mixing them creates larger blast radius deployments, longer rollback procedures, and more complex review processes. Use separate pipelines with different approval processes and deployment cadences.

Common Issues

Deployments succeed but the application fails because database migrations were not run. Application deployments that depend on database schema changes must run migrations before deploying the new code. Include migration steps in the deployment pipeline, verify they succeed, then deploy the application. Design migrations to be backward-compatible: the old application code should work with the new schema, enabling rollback without rolling back the migration.

Canary deployments send all users to the canary because routing is misconfigured. Traffic splitting requires precise configuration at the load balancer or service mesh level. Verify that only the intended percentage of traffic reaches the canary by checking access logs on both the stable and canary deployments. Use header-based routing during testing to send specific test traffic to the canary before enabling percentage-based splitting.

Deployment pipeline takes 30+ minutes, slowing down the development cycle. Long pipelines delay feedback and discourage frequent deployments. Profile each pipeline step to find bottlenecks. Common optimizations: cache dependencies between runs, parallelize independent steps (lint + test + build), use larger runners, skip unchanged components in monorepo deployments, and avoid running the full E2E suite on every deployment (run it nightly instead).