tomevault-io CI/CD and Automation
Overview
Shift quality checks left — run them as early as possible in the development pipeline. CI catches bugs before they reach production. CD makes deployment boring and repeatable instead of a risky event.
When to Use
- Setting up CI/CD for a new project
- Adding quality gates to an existing pipeline
- Debugging pipeline failures
- Planning a deployment strategy
- Implementing feature flags
When NOT to use: One-off manual deployments where automation cost exceeds benefit. But if you're deploying more than once a month, automate it.
CI Pipeline Design
The Quality Gate Pipeline
Every push runs these checks, in this order:
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Lint │──→│ Type │──→│ Test │──→│ Build │──→│ Security│
│ │ │ Check │ │ │ │ │ │ Scan │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
Fail early: linting is cheapest and catches the most common issues. Don't run expensive tests if linting fails.
Pipeline Configuration
# Minimum CI pipeline — GitHub Actions example
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint
- run: npm run typecheck
- run: npm test
- run: npm run build
Required Checks for PRs
Configure branch protection so PRs can't merge without:
- All CI checks passing
- At least one approval
- Up-to-date with
main
CD Pipeline Design
Deployment Strategy
| Strategy | Risk | Best For |
|---|---|---|
| Direct deploy | High | Small projects, internal tools |
| Blue/green | Low | Stateless services |
| Canary (1% → 10% → 100%) | Very low | High-traffic user-facing apps |
| Feature flags | Very low | Gradual rollout, A/B testing |
Feature Flags
Use feature flags to decouple deployment from release:
// Deployment: code is in production
// Release: feature is visible to users
if (featureFlags.isEnabled('new-checkout', { userId })) {
return <NewCheckout />;
}
return <OldCheckout />;
Feature flag lifecycle:
- Create — disabled by default
- Test — enable for internal users / staging
- Rollout — enable for percentage of users
- Full release — enable for all users
- Clean up — remove the flag and old code path
Shift Left Principles
Move checks earlier in the pipeline to reduce feedback time:
Local (fastest): Linting, formatting, type checking
Pre-commit: Hooks that run lint + format
CI (minutes): Tests, build, security scan
Staging (hours): Integration tests, smoke tests
Production: Monitoring, alerting, feature flags
Tools for local checks:
- Pre-commit hooks —
lint-staged+husky(JS/TS),pre-commit(Python),mix format --check-formatted(Elixir) - Editor integration — ESLint, Prettier, TypeScript in VS Code
Pipeline Anti-Patterns
| Anti-Pattern | Fix |
|---|---|
| Tests take > 15 minutes | Parallelize. Cache dependencies. Use test impact analysis. |
| Flaky tests block deploys | Quarantine flaky tests. Fix or delete within 48 hours. |
| No caching | Cache node_modules, build artifacts, Docker layers. |
| Deploying from local machines | All deployments go through CI/CD. No exceptions. |
| Manual approval gates | Automate everything except production deploy approval. |
| No rollback plan | Every deploy must have a documented rollback. If you can't undo it, don't ship it. |
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "CI is too slow" | Slow CI means your pipeline needs optimization — caching, parallelism, or pruning. Don't skip CI because it's slow. |
| "We'll add CI later" | Later never comes. Set up CI on day 1, even if it's just lint + test. |
| "Feature flags add complexity" | Less complexity than rollback procedures. Flags are the simplest way to deploy safely. |
| "We don't need staging" | You need at least one environment that isn't production. Even a local Docker Compose counts. |
| "I'll just deploy manually this once" | Manual deployments accumulate tribal knowledge and aren't reproducible. |
Red Flags
- PRs merged without CI checks passing
- Deployments from local machines
- No rollback procedure documented
- Feature flags that live forever (clean up after full rollout)
- Flaky tests ignored instead of fixed
- CI pipeline takes > 20 minutes (optimize it)
- Secrets hardcoded in pipeline configuration
Verification
When setting up or modifying CI/CD:
- Every push triggers quality checks (lint, typecheck, test, build)
- PRs can't merge without passing checks
- Dependencies are cached between runs
- Deployment is automated (no manual steps)
- Rollback procedure exists and is documented
- Feature flags are used for incomplete features
- Pipeline completes in < 15 minutes
- Secrets are stored in CI/CD variables, not in code
Source: dreamingechoes/dx-toolkit — distributed by TomeVault.