deployment-ci-cd

---
name: deployment-ci-cd
description: CI/CD pipeline design and deployment automation for all stacks — GitHub Actions workflows, Docker multi-stage builds, Cloud Run deployments, Flutter distribution, and Firebase rule deployments. Use when setting up or reviewing CI/CD pipelines, deployment workflows, or automated release processes.
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
agent: deployment-engineer
context: fork
metadata:
  triggers: CI/CD, github actions, deploy, pipeline, cloud run deploy, firebase deploy, flutter build pipeline, docker build, deployment workflow, automated release
  related-skills: docker, gcp-cloud-run, terraform-skill, flutter-mobile
  domain: infrastructure
  role: specialist
  scope: implementation
  output-format: implementation
last-reviewed: "2026-03-29"
---

**Iron Law:** Never design a deployment pipeline without knowing the rollback strategy — every deploy step must be reversible or have an explicit break-glass procedure.

# Deployment CI/CD

CI/CD pipeline design and deployment automation specialist covering GitHub Actions, Docker, Cloud Run, Flutter mobile distribution, and Firebase deployments.

## When to Use

- Setting up a new GitHub Actions CI/CD pipeline
- Reviewing an existing deployment workflow
- Designing Docker multi-stage build optimization
- Setting up Cloud Run progressive delivery (traffic splitting)
- Automating Flutter builds and distribution to Firebase App Distribution
- Configuring Firebase Hosting, Firestore rules, or Functions deployment

## Pipeline Patterns by Stack

| Stack | Build | Test | Deploy |
|-------|-------|------|--------|
| **NestJS** | Docker multi-stage | Vitest | Cloud Run (canary → prod) |
| **Spring Boot** | Maven + Docker | JUnit | Cloud Run (health check gate) |
| **Python/FastAPI** | Docker + uv | pytest | Cloud Run Functions |
| **Angular** | `ng build --prod` | Karma/Jest | Firebase Hosting |
| **Flutter** | `flutter build apk/ipa` | `flutter test` | Firebase App Distribution / App Store |

## Key Principles

- **Multi-stage Docker**: separate build and runtime stages; never ship dev dependencies
- **Health check gate**: Cloud Run deploy must pass health check before traffic shift
- **Secret management**: use Workload Identity Federation (not service account keys)
- **Progressive delivery**: canary → 10% → 50% → 100% with automated rollback on error rate spike
- **Container scanning**: Trivy scan before push to Artifact Registry

## Process

1. Identify target stack and deployment environment
2. Load `docker` skill for Dockerfile patterns (if containerizing)
3. Load `gcp-cloud-run` skill for Cloud Run-specific patterns (if deploying to GCP)
4. Design pipeline stages: build → test → security scan → push → deploy → verify
5. Define rollback strategy for each stage
6. Output GitHub Actions workflow YAML + deployment configuration

## Production Readiness Checklist

Before any production deploy, verify ALL of the following. If any item is NO → do not deploy.

### Application
- [ ] `/health` endpoint responds 200 with DB connectivity check (see `reference/health-endpoints.md`)
- [ ] All required env vars validated at startup — app fails fast if missing (see `reference/env-config-validation.md`)
- [ ] No secrets hardcoded in source code or committed config files
- [ ] `.env.example` committed with all keys, placeholder values only
- [ ] Error handling: all catch blocks log + rethrow or return error state (no silent failures)

### Container / Docker
- [ ] Multi-stage Dockerfile — dev deps not in production image
- [ ] Non-root user in Dockerfile (`USER appuser`)
- [ ] Specific image tags pinned — no `:latest`
- [ ] HEALTHCHECK instruction in Dockerfile
- [ ] `.dockerignore` excludes: `node_modules`, `.git`, `.env`, `dist`, `coverage`
- [ ] `docker scout` or `trivy image` scan — zero CRITICAL CVEs

### CI/CD Pipeline
- [ ] Tests pass (all: unit + integration)
- [ ] Linting + type-check pass (zero errors)
- [ ] Container image pushed to Artifact Registry with commit SHA tag
- [ ] Health check gate passes before any traffic shift
- [ ] Rollback strategy defined and tested for this deploy

### Cloud Run (GCP Stack)
- [ ] Workload Identity Federation configured — no service account key files
- [ ] Deploy uses `--no-traffic` first → canary 10% → verify → 100%
- [ ] Memory limits set (`--memory` flag matches actual service requirements)
- [ ] Concurrency configured (`--concurrency` — default 80, tune per service)
- [ ] Min instances = 0 for cost (or 1+ for latency-sensitive services)

### Security
- [ ] `security-reviewer` agent verdict: no CRITICAL or HIGH findings
- [ ] All API endpoints require authentication (no accidental public exposure)
- [ ] CORS policy explicitly configured (not wildcard `*` in production)
- [ ] Secrets stored in Secret Manager, not Cloud Run env vars directly

### Post-Deploy Verification
- [ ] Health endpoint returns 200 on new revision URL
- [ ] Smoke test: critical user flow works end-to-end
- [ ] Error rate < 0.1% for 5 minutes post-deploy
- [ ] Rollback procedure verified working (test once per quarter)

More agent context in kumaran-is/claude-code-onboarding

157 other files this repository gives its agents, the first 60 shown.