ci-cd

CI/CD

Purpose

Build a pipeline that catches problems before production and is fast enough that engineers do not learn to ignore it. A twenty-minute CI run is a pipeline people bypass.

When to Use

• Setting up CI/CD for a new project.
• A pipeline that is slow, flaky, or routinely skipped.
• Introducing a safer deployment strategy.
• Managing secrets and deployment credentials.

Capabilities

• Pipeline structure: what runs on every commit, what runs on merge, what runs on release.
• Caching and parallelization to cut wall-clock time.
• Deployment strategies: blue/green, canary, rolling, feature flags.
• Secrets management and OIDC-based cloud authentication.
• Flaky-test detection and quarantine.

Inputs

• The repository, its test suite, and current pipeline timings.
• The deployment target and its rollback capability.
• Compliance requirements: approvals, audit trail, signed artifacts.

Outputs

• A pipeline with a fast feedback stage and a thorough merge stage.
• Deployments that are observable and reversible.
• No long-lived cloud credentials in CI.

Workflow

1. Split fast from thorough — Lint, type-check, and unit tests on every push, in under five minutes. Integration, E2E, and security scans on the merge queue or on main.
2. Cache the right things — Dependencies, build artifacts, and Docker layers. A cache keyed on the lockfile hash is correct; one keyed on the branch is a source of stale-build mysteries.
3. Parallelize the test suite — Shard by timing, not alphabetically. The slowest shard determines the wall clock.
4. Deploy progressively — Canary to a small percentage, watch the error rate and latency, then proceed. Automate the abort.
5. Authenticate with OIDC — Short-lived tokens federated from the CI provider to the cloud. A long-lived access key in CI secrets is a breach waiting to be exfiltrated by a malicious dependency.
6. Track flakes — A test that fails 2% of the time will train the team to re-run the pipeline reflexively, at which point CI has stopped working.