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.

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: 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 With Database Integration Tests 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. E2E Tests Feeding CI Failures Back to Agents The power of CI with AI agents is the feedback loop. When CI fails: Key patterns: Deployment Strategies Preview Deployments Every PR gets a preview deployment for manual testing: Feature Flags Feature flags decouple deployment from release. Deploy incomplete 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, then 10%, then 100%. Run A/B tests. Compare behavior with and without the feature. 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. Staged Rollouts Rollback Plan Every deployment should be reversible: Environment Management CI should never have production secrets. Use separate secrets for CI testing. Automation Beyond CI Dependabot / Renovate Build Cop Role Designate 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. PR Checks Required reviews: At least 1 approval before merge Required status checks: CI must pass before merge Branch protection: No force pushes to main Auto merge: If all checks pass and approved, merge automatically CI Optimization When the pipeline exceeds 10 minutes, apply these strategies in order of impact: Example: caching and parallelism Common Rationalizations Rationalization Reality "CI is too slow" Optimize the pipeline (see CI Optimization below), 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 No CI pipeline in the project CI failures ignored or silenced Tests disabled in CI to make the pipeline pass Production deploys without staging verification No rollback mechanism Secrets stored in code or CI config files (not secrets manager) Long CI times with no optimization effort 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

ci-cd-and-automation