# CI CD And Automation > 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. - Skill: `tomevault-io/ci-cd-and-automation-10` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/ci-cd-and-automation-10` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/ci-cd-and-automation-10/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/ci-cd-and-automation-10 --- # CI/CD and Automation ## Overview Automate quality gates to enforce tests, lint, type checking, and build before production. CI/CD catches what humans miss, consistently on every change. **Shift Left:** Catch problems early — linting bugs cost minutes, production bugs cost hours. Move checks upstream: static analysis → tests → staging → production. **Faster is Safer:** Smaller batches reduce risk. A 3-change deployment is easier to debug than 30. ## 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 Concrete pipeline examples (Basic CI, database integration tests, E2E tests) live in [`references/github-actions-examples.md`](references/github-actions-examples.md). Use them as starting points, not as a contract. ## Feeding CI Failures Back to Agents The power of CI with AI agents is 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. See [`references/github-actions-examples.md`](references/github-actions-examples.md) for workflow configuration. ### Feature Flags Feature flags decouple deployment from release — ship code without enabling it, roll back without redeploying, canary to users, or run A/B tests. Set a cleanup date when creating flags; flags that live forever become technical debt. ### Staged Rollouts ``` PR merged → Staging (auto) → Manual verify → Production → Monitor 15 min → Rollback or Done ``` ### Rollback Plan Every deployment must be reversible. See [`references/github-actions-examples.md`](references/github-actions-examples.md) for rollback workflow examples. ## 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 Configure automated dependency updates via `.github/dependabot.yml`. See [`references/github-actions-examples.md`](references/github-actions-examples.md) for configuration examples. ### Build Cop Role Designate one person responsible for CI. When the build breaks, they fix or revert — not the change author. Prevents broken builds from accumulating. ### 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: ``` 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 configurations** for caching, parallelism, and matrix builds are in [`references/github-actions-examples.md`](references/github-actions-examples.md). ## Common Rationalizations | Rationalization | Reality | |---|---| | "CI is too slow" | Optimize the pipeline, 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. Fix the flakiness. | ## 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 --- > Source: [wryenmeek/knowledgebase](https://github.com/wryenmeek/knowledgebase) — distributed by [TomeVault](https://tomevault.io).