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.
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. Do not disable the rule. If a test fails, fix the code. Do not skip the test.
Note: The gates are language-general; only the commands change per ecosystem. The Node commands in the gates above map directly to other stacks. For example, Python (
ruff check,mypy,pytest,pip-audit) or Rust (cargo build,cargo clippy,cargo test,cargo audit). Keep the same gate order regardless of language.
Feeding CI Failures Back to Agents
Read references/ci-failure-feedback-loop.md when a CI run has already failed and the failure needs to be routed back to an agent for a fix. Skip it when setting up a new pipeline or adding a gate for the first time — that branch has no failure yet to feed back.
Reference materials
The gate order above is fixed. These supply the commands and config that realize it.
references/github-actions.md: workflow YAML for the quality pipeline, Postgres-backed integration tests, and Playwright E2E.references/deployment-strategies.md: preview deploys, feature-flag lifecycle, staged rollouts, and the rollback workflow.references/automation-and-environments.md: where env vars and secrets live across.env*and CI, plus Dependabot and branch protection.references/ci-optimization.md: the slow-pipeline decision tree, caching, and job parallelism.references/ci-failure-feedback-loop.md: the copy-error-to-agent feedback loop; read only once a CI run has failed.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "CI is too slow" | Optimize the pipeline (see references/ci-optimization.md), don't skip it. A 5-minute pipeline prevents hours of debugging. |
| "This change is trivial, skip CI" | Trivial changes break builds. CI is fast for trivial changes anyway. |
| "The test is flaky, just re-run" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |
| "We'll 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 what you can. |
Red Flags
- Production deploys without staging verification
- No rollback mechanism
- Secrets stored in code or CI config files (not secrets manager)
Verification
After setting up or modifying CI:
- [ ] All quality gates are present (lint, types, tests, build, audit)
- [ ] Pipeline runs on every PR and push to main
- [ ] Failures block merge (branch protection configured)
- [ ] CI results feed back into the development loop
- [ ] Secrets are stored in the secrets manager, not in code
- [ ] Deployment has a rollback mechanism
- [ ] Pipeline runs in under 10 minutes for the test suite