Overview
Automate quality gates to ensure any change passes tests, lint, type checking, and build before entering production. CI/CD is the execution mechanism for all other skills; it catches issues that humans and agents miss, and enforces this consistently for every change.
Shift Left: Catch issues as early as possible in the pipeline. A bug found in linting costs only a few minutes; the same bug found in production costs hours. Shift checks left: static analysis before tests, tests before staging, staging before production.
Faster is Safer: Smaller batches and more frequent releases reduce risk rather than increase it. A deployment containing 3 changes is easier to debug than one containing 30 changes. Frequent releases build confidence in the release process itself.
When to Use
- Set up a CI pipeline for a new project
- Add or modify automated checks
- Configure deployment pipelines
- When a change should trigger automated verification
- Debug CI failures
Quality Gate Pipeline
Every change passes through these gates before merging:
Pull Request Opened
│
▼
┌─────────────────┐
│ LINT CHECK │ eslint, prettier
│ ↓ pass │
│ TYPE CHECK │ tsc --noEmit
│ ↓ pass │
│ UNIT TESTS │ jest/vitest
│ ↓ pass │
│ BUILD │ npm run build
│ ↓ pass │
│ INTEGRATION │ API/DB tests
│ ↓ pass │
│ E2E (optional) │ Playwright/Cypress
│ ↓ pass │
│ SECURITY AUDIT │ npm audit
│ ↓ pass │
│ BUNDLE SIZE │ bundlesize check
└─────────────────┘
│
▼
Ready for review
No gate may be skipped. If lint fails, fix the lint, do not disable the rule. If tests fail, fix the code, do not skip the tests.
GitHub Actions Configuration
Basic CI Pipeline
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npx tsc --noEmit
- name: Test
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Security audit
run: npm audit --audit-level=high
Including Database Integration Tests
integration:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_USER: ci_user
POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Run migrations
run: npx prisma migrate deploy
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
- name: Integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
Note: Even for a test database used only by CI, store credentials in GitHub Secrets rather than hardcoded values. This builds good habits and prevents test credentials from being accidentally reused in other contexts.
E2E Tests (End-to-End Tests)
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Install Playwright
run: npx playwright install --with-deps chromium
- name: Build
run: npm run build
- name: Run E2E tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/
Feed CI Failures Back to Agents
The power of CI combined with AI agents lies in the feedback loop. When CI fails:
CI fails
│
▼
Copy the failure output
│
▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
│
▼
Agent fixes → pushes → CI runs again
Key patterns:
Lint failure → Agent runs `npm run lint --fix` and commits
Type error → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependencies
Deployment Strategies
Preview Deployments
Every PR gets a preview deployment for manual testing:
# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
runs-on: ubuntu-latest
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
- name: Deploy preview
run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}
Feature Flags
Feature flags decouple deployment from release. Deploy unfinished or risky features behind flags so you can:
- Ship code without enabling it. Merge to main early, enable when ready.
- Roll back without redeploying. Disable the flag instead of reverting code.
- Canary new features. Enable for 1% of users first, then 10%, then 100%.
- Run A/B tests. Compare behavior with and without the feature.
// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
return renderNewCheckout();
}
return renderLegacyCheckout();
Flag lifecycle: Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt, so set a cleanup date when creating them.
Staged Rollout
PR merged to main
│
▼
Staging deployment (auto)
│ Manual verification
▼
Production deployment (manual trigger or auto after staging)
│
▼
Monitor for errors (15-minute window)
│
├── Errors detected → Rollback
└── Clean → Done
Rollback Plan
Every deployment should be rollback-able:
# Manual rollback workflow
name: Rollback
on:
workflow_dispatch:
inputs:
version:
description: 'Version to rollback to'
required: true
jobs:
rollback:
runs-on: ubuntu-latest
steps:
- name: Rollback deployment
run: |
# Deploy the specified previous version
npx vercel rollback ${{ inputs.version }}
Environment Management
.env.example → Committed (template for developers)
.env → NOT committed (local development)
.env.test → Committed (test environment, no real secrets)
CI secrets → Stored in GitHub Secrets / vault
Production secrets → Stored in deployment platform / vault
CI should never have production secrets. Use separate secrets for CI testing.
Automation Beyond CI
Dependabot / Renovate
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: npm
directory: /
schedule:
interval: weekly
open-pull-requests-limit: 5
Build Cop Role
Designate a specific person responsible for keeping CI green. When the build fails, the Build Cop's job is to fix or roll back, not the person who caused the failure. This prevents broken builds from accumulating under the assumption that "someone else will fix it."
PR Checks
- Required reviews: At least 1 approval before merging
- Required status checks: CI must pass before merging
- Branch protection: Force-pushes to main are prohibited
- Auto-merge: Auto-merge if all checks pass and it is approved
CI Optimization
When the pipeline exceeds 10 minutes, apply these strategies in order from greatest to least impact:
Slow CI pipeline?
├── Cache dependencies
│ └── Use actions/cache or setup-node cache option for node_modules
├── Run jobs in parallel
│ └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│ └── Shard test suites across multiple runners
├── Optimize the test suite
│ └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
└── GitHub-hosted larger runners or self-hosted for CPU-heavy builds
Example: Caching and parallelism
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm run lint
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npx tsc --noEmit
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm test -- --coverage
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "CI is too slow" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline can avoid hours of debugging. |
| "This change is small, skip CI" | Small changes can also break the build. Besides, CI is usually fast for small changes. |
| "Tests are flaky, just rerun" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |
| "Add CI later" | Projects without CI accumulate broken states. Set it up on day one. |
| "Manual testing is enough" | Manual testing doesn't scale and isn't repeatable. Automate everything that can be automated. |
Red Flags
- No CI pipeline in the project
- CI failures are ignored or muted
- Tests are disabled in CI to make the pipeline pass
- Deploying to production without staging verification
- No rollback mechanism
- Secrets stored in code or CI config files (instead of a secrets manager)
- CI takes a long time but there is no investment in optimization
Verification
After setting up or modifying CI:
- All quality gates are present (lint, types, tests, build, audit)
- The pipeline runs on every PR and push to main
- Failures block merging (branch protection is configured)
- CI results feed back into the development loop
- Secrets are stored in a secrets manager, not in code
- Deployments have a rollback mechanism
- The test suite's pipeline completes within 10 minutes