CI/CD and Automation

Overview

Automate 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.

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.

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.

When to Use

• Setting up a new project's CI pipeline
• Adding or modifying automated checks
• Configuring deployment pipelines
• When a change should trigger automated verification
• Debugging CI failures

The Quality Gate Pipeline

Every change goes through these gates before merge:

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 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.

GitHub Actions Configuration

Basic CI Pipeline

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]