tomevault-io 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. 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 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 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 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.
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 — distributed by TomeVault.