DevOps Pipeline Designer

Design CI/CD pipelines for modern applications with comprehensive automation.

**Application Type:** [NEXT.JS APP / REACT SPA / NODE.JS API / PYTHON SERVICE / RUST BINARY / MULTI-MONOREPO]
**Hosting Platform:** [VERCEL / AWS / GCP / AZURE / DOCKER + KUBERNETES]
**Team Size:** [1-2 / 3-10 / 10+]

**Pipeline Stages Design:**

**Stage 1: Source Control & Commit Hooks**
- Branch naming convention (feature/, bugfix/, hotfix/, release/)
- Protected branch rules (main requires PR + 2 approvals)
- Pre-commit hooks: linting, formatting, secret scanning (git-secrets/truffleHog)
- Conventional commits format enforcement (commitlint + husky)

**Stage 2: Build & Lint**
- Dependency installation with lockfile verification
- TypeScript/type checking pass (--noEmit)
- ESLint + Prettier validation with fail-on-error configuration
- Security audit (npm audit / pip-audit / cargo audit)
- Bundle size tracking with growth alerting (>5% increase triggers warning)

**Stage 3: Unit Testing**
- Test runner configuration (Jest/Vitest/Mocha)
- Coverage threshold enforcement (minimum 80% line coverage, 70% branch)
- Parallel test execution for speed
- Flaky test detection and quarantine process
- Code coverage reporting to PR comments

**Stage 4: Integration Testing**
- Database test container setup (PostgreSQL/Redis in Docker)
- API endpoint integration tests with mock external services
- E2E test framework selection (Playwright/Cypress) with visual regression testing
- Test environment provisioning strategy

**Stage 5: Container Building & Security Scanning**
- Multi-stage Docker builds for minimal image size
- Image signing with Cosign/Notary
- Vulnerability scanning (Trivy, Snyk, or Grype)
- Base image update monitoring (Docker Scout / Dependabot)
- Image push to registry with tag strategy (SHA + semantic version)

**Stage 6: Deployment**
- Staging deployment on every main branch merge (auto-deploy)
- Production deployment triggered by release tag or manual approval
- Blue-green or canary deployment strategy for zero-downtime releases
- Database migration handling (run before app deploy, backward compatible)
- Health check verification after deployment with automatic rollback on failure
- Environment variable management (secrets in vault, config in environment)

**Stage 7: Monitoring & Observability**
- Application performance monitoring setup (New Relic, Datadog, Sentry)
- Log aggregation strategy (structured JSON logs → ELK/Datadog)
- Error tracking with source map upload for minified bundles
- Uptime monitoring with synthetic checks
- Alert routing: Slack for warnings, PagerDuty for critical failures

**Infrastructure as Code:**
- Terraform/Pulumi module structure for environments (dev/staging/prod)
- State file storage with locking (S3 + DynamoDB for Terraform)
- Environment parity strategy (same infrastructure, different variable values)
- Cost estimation in PRs using Infracost

**Rollback Strategy:**
- Automatic rollback on health check failure within 5 minutes of deploy
- One-click manual rollback button in deployment dashboard
- Database migration rollback procedures (down migrations with data preservation)

How to Customize It

Replace each bracketed placeholder with your own details before running the prompt. The more specific you are, the better the output — vague inputs produce generic results.

• [NEXT.JS APP / REACT SPA / NODE.JS API / PYTHON SERVICE / RUST BINARY / MULTI-MONOREPO]Swap in your next.js app or react spa or node.js api or python service or rust binary or multi-monorepo.
• [VERCEL / AWS / GCP / AZURE / DOCKER + KUBERNETES]Swap in your vercel or aws or gcp or azure or docker + kubernetes.

When to Use It

• Setting up CI/CD for a new repo and wanting the whole flow designed before writing YAML by trial and error.
• Speeding up a pipeline that has crept past 20 minutes — the caching and parallelization sections apply directly.
• Adding deployment safety (preview environments, staged rollout, automatic rollback) to a pipeline that currently YOLOs to production.

Tips for Better Results

• 1Name your actual CI provider; the design translates to GitHub Actions vs. GitLab CI differently and the YAML is half the deliverable.
• 2Ask for pipeline runtime budget per stage — "tests under 5 minutes" is a design constraint, not an aspiration.
• 3The rollback answer matters more than the deploy answer. If the design can't undo a bad release in one step, iterate.