Ci Cd And Automation

1---2name: ci-cd-and-automation3description: Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.4---5 6# CI/CD and Automation7 8## Overview9 10Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.11 12**Shift Left:** Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.13 14**Faster is Safer:** Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.15 16## When to Use17 18- Setting up a new project's CI pipeline19- Adding or modifying automated checks20- Configuring deployment pipelines21- When a change should trigger automated verification22- Debugging CI failures23 24## The Quality Gate Pipeline25 26Every change goes through these gates before merge:27 28```29Pull Request Opened30    │31    ▼32┌─────────────────┐33│   LINT CHECK     │  eslint, prettier34│   ↓ pass         │35│   TYPE CHECK     │  tsc --noEmit36│   ↓ pass         │37│   UNIT TESTS     │  jest/vitest38│   ↓ pass         │39│   BUILD          │  npm run build40│   ↓ pass         │41│   INTEGRATION    │  API/DB tests42│   ↓ pass         │43│   E2E (optional) │  Playwright/Cypress44│   ↓ pass         │45│   SECURITY AUDIT │  npm audit46│   ↓ pass         │47│   BUNDLE SIZE    │  bundlesize check48└─────────────────┘49    │50    ▼51  Ready for review52```53 54**No gate can be skipped.** If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.55 56## GitHub Actions Configuration57 58### Basic CI Pipeline59 60```yaml61# .github/workflows/ci.yml62name: CI63 64on:65  pull_request:66    branches: [main]67  push:68    branches: [main]69 70jobs:71  quality:72    runs-on: ubuntu-latest73    steps:74      - uses: actions/checkout@v475 76      - uses: actions/setup-node@v477        with:78          node-version: '22'79          cache: 'npm'80 81      - name: Install dependencies82        run: npm ci83 84      - name: Lint85        run: npm run lint86 87      - name: Type check88        run: npx tsc --noEmit89 90      - name: Test91        run: npm test -- --coverage92 93      - name: Build94        run: npm run build95 96      - name: Security audit97        run: npm audit --audit-level=high98```99 100### With Database Integration Tests101 102```yaml103  integration:104    runs-on: ubuntu-latest105    services:106      postgres:107        image: postgres:16108        env:109          POSTGRES_DB: testdb110          POSTGRES_USER: ci_user111          POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}112        ports:113          - 5432:5432114        options: >-115          --health-cmd pg_isready116          --health-interval 10s117          --health-timeout 5s118          --health-retries 5119 120    steps:121      - uses: actions/checkout@v4122      - uses: actions/setup-node@v4123        with:124          node-version: '22'125          cache: 'npm'126      - run: npm ci127      - name: Run migrations128        run: npx prisma migrate deploy129        env:130          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb131      - name: Integration tests132        run: npm run test:integration133        env:134          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb135```136 137> **Note:** Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.138 139### E2E Tests140 141```yaml142  e2e:143    runs-on: ubuntu-latest144    steps:145      - uses: actions/checkout@v4146      - uses: actions/setup-node@v4147        with:148          node-version: '22'149          cache: 'npm'150      - run: npm ci151      - name: Install Playwright152        run: npx playwright install --with-deps chromium153      - name: Build154        run: npm run build155      - name: Run E2E tests156        run: npx playwright test157      - uses: actions/upload-artifact@v4158        if: failure()159        with:160          name: playwright-report161          path: playwright-report/162```163 164## Feeding CI Failures Back to Agents165 166The power of CI with AI agents is the feedback loop. When CI fails:167 168```169CI fails170    │171    ▼172Copy the failure output173    │174    ▼175Feed it to the agent:176"The CI pipeline failed with this error:177[paste specific error]178Fix the issue and verify locally before pushing again."179    │180    ▼181Agent fixes → pushes → CI runs again182```183 184**Key patterns:**185 186```187Lint failure → Agent runs `npm run lint --fix` and commits188Type error  → Agent reads the error location and fixes the type189Test failure → Agent follows debugging-and-error-recovery skill190Build error → Agent checks config and dependencies191```192 193## Deployment Strategies194 195### Preview Deployments196 197Every PR gets a preview deployment for manual testing:198 199```yaml200# Deploy preview on PR (Vercel/Netlify/etc.)201deploy-preview:202  runs-on: ubuntu-latest203  if: github.event_name == 'pull_request'204  steps:205    - uses: actions/checkout@v4206    - name: Deploy preview207      run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}208```209 210### Feature Flags211 212Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:213 214- **Ship code without enabling it.** Merge to main early, enable when ready.215- **Roll back without redeploying.** Disable the flag instead of reverting code.216- **Canary new features.** Enable for 1% of users, then 10%, then 100%.217- **Run A/B tests.** Compare behavior with and without the feature.218 219```typescript220// Simple feature flag pattern221if (featureFlags.isEnabled('new-checkout-flow', { userId })) {222  return renderNewCheckout();223}224return renderLegacyCheckout();225```226 227**Flag lifecycle:** Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.228 229### Staged Rollouts230 231```232PR merged to main233    │234    ▼235  Staging deployment (auto)236    │ Manual verification237    ▼238  Production deployment (manual trigger or auto after staging)239    │240    ▼241  Monitor for errors (15-minute window)242    │243    ├── Errors detected → Rollback244    └── Clean → Done245```246 247### Rollback Plan248 249Every deployment should be reversible:250 251```yaml252# Manual rollback workflow253name: Rollback254on:255  workflow_dispatch:256    inputs:257      version:258        description: 'Version to rollback to'259        required: true260 261jobs:262  rollback:263    runs-on: ubuntu-latest264    steps:265      - name: Rollback deployment266        run: |267          # Deploy the specified previous version268          npx vercel rollback ${{ inputs.version }}269```270 271## Environment Management272 273```274.env.example       → Committed (template for developers)275.env                → NOT committed (local development)276.env.test           → Committed (test environment, no real secrets)277CI secrets          → Stored in GitHub Secrets / vault278Production secrets  → Stored in deployment platform / vault279```280 281CI should never have production secrets. Use separate secrets for CI testing.282 283## Automation Beyond CI284 285### Dependabot / Renovate286 287```yaml288# .github/dependabot.yml289version: 2290updates:291  - package-ecosystem: npm292    directory: /293    schedule:294      interval: weekly295    open-pull-requests-limit: 5296```297 298### Build Cop Role299 300Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.301 302### PR Checks303 304- **Required reviews:** At least 1 approval before merge305- **Required status checks:** CI must pass before merge306- **Branch protection:** No force-pushes to main307- **Auto-merge:** If all checks pass and approved, merge automatically308 309## CI Optimization310 311When the pipeline exceeds 10 minutes, apply these strategies in order of impact:312 313```314Slow CI pipeline?315├── Cache dependencies316│   └── Use actions/cache or setup-node cache option for node_modules317├── Run jobs in parallel318│   └── Split lint, typecheck, test, build into separate parallel jobs319├── Only run what changed320│   └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)321├── Use matrix builds322│   └── Shard test suites across multiple runners323├── Optimize the test suite324│   └── Remove slow tests from the critical path, run them on a schedule instead325└── Use larger runners326    └── GitHub-hosted larger runners or self-hosted for CPU-heavy builds327```328 329**Example: caching and parallelism**330```yaml331jobs:332  lint:333    runs-on: ubuntu-latest334    steps:335      - uses: actions/checkout@v4336      - uses: actions/setup-node@v4337        with: { node-version: '22', cache: 'npm' }338      - run: npm ci339      - run: npm run lint340 341  typecheck:342    runs-on: ubuntu-latest343    steps:344      - uses: actions/checkout@v4345      - uses: actions/setup-node@v4346        with: { node-version: '22', cache: 'npm' }347      - run: npm ci348      - run: npx tsc --noEmit349 350  test:351    runs-on: ubuntu-latest352    steps:353      - uses: actions/checkout@v4354      - uses: actions/setup-node@v4355        with: { node-version: '22', cache: 'npm' }356      - run: npm ci357      - run: npm test -- --coverage358```359 360## Common Rationalizations361 362| Rationalization | Reality |363|---|---|364| "CI is too slow" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. |365| "This change is trivial, skip CI" | Trivial changes break builds. CI is fast for trivial changes anyway. |366| "The test is flaky, just re-run" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |367| "We'll add CI later" | Projects without CI accumulate broken states. Set it up on day one. |368| "Manual testing is enough" | Manual testing doesn't scale and isn't repeatable. Automate what you can. |369 370## Red Flags371 372- No CI pipeline in the project373- CI failures ignored or silenced374- Tests disabled in CI to make the pipeline pass375- Production deploys without staging verification376- No rollback mechanism377- Secrets stored in code or CI config files (not secrets manager)378- Long CI times with no optimization effort379 380## Verification381 382After setting up or modifying CI:383 384- [ ] All quality gates are present (lint, types, tests, build, audit)385- [ ] Pipeline runs on every PR and push to main386- [ ] Failures block merge (branch protection configured)387- [ ] CI results feed back into the development loop388- [ ] Secrets are stored in the secrets manager, not in code389- [ ] Deployment has a rollback mechanism390- [ ] Pipeline runs in under 10 minutes for the test suite