CI/CD Pipeline Design — From Push to Production in Minutes

The goal is boring deploys#

The best CI/CD pipeline is one nobody thinks about. Push code, tests pass, deploy happens, users don't notice. Boring is the goal.

Here's how to design a pipeline that gets you there.

The stages#

Every CI/CD pipeline has the same basic stages. The details vary, but the structure doesn't:

1. Build#

Compile code, install dependencies, generate artifacts.

Keep it fast. If your build takes 10 minutes, developers stop running it locally. Cache dependencies aggressively — node_modules, pip packages, Maven artifacts.

2. Test#

Run your test suite. This is the gate — nothing moves forward unless tests pass.

The testing pyramid:

• Unit tests (fast, lots of them) — test individual functions
• Integration tests (medium speed, fewer) — test service interactions
• E2E tests (slow, very few) — test critical user flows

Don't run E2E tests on every push. Run unit + integration on push, E2E on merge to main.

3. Security scan#

Automated checks before code reaches production:

• Dependency audit — known vulnerabilities in packages
• Static analysis — code quality, potential bugs
• Secret scanning — API keys accidentally committed
• Container scanning — vulnerabilities in Docker images

4. Deploy to staging#

Automatically deploy to a staging environment that mirrors production.

Staging should be identical to production. Same infrastructure, same config (with test API keys), same data schema. If it works in staging but breaks in production, your staging is lying to you.

5. Deploy to production#

The scary part. Except it shouldn't be, because you have:

• Automated rollback on error spike
• Feature flags to decouple deploy from release
• Monitoring that catches issues in seconds

Deployment strategies#

Rolling deployment#

Replace old instances one at a time. At any point, some instances run the old version and some run the new.

Pros: No downtime. Uses existing infrastructure. Cons: Two versions running simultaneously — must be backward compatible.

Blue-green deployment#

Run two identical environments. Deploy to the inactive one (green), then switch traffic.

Pros: Instant rollback (switch back to blue). Full testing on green before switch. Cons: Doubles infrastructure cost during deployment.

Canary deployment#

Route a small percentage (1-5%) of traffic to the new version. Monitor. Gradually increase.

Pros: Limits blast radius. Real user traffic validates the release. Cons: More complex routing. Need good observability to detect issues at low traffic percentages.

Feature flags#

Deploy the code but don't activate it. Toggle features on per-user, per-team, or per-percentage.

Pros: Decouple deployment from release. A/B test easily. Kill switch for broken features. Cons: Technical debt if flags aren't cleaned up. Code branching complexity.

Pipeline anti-patterns#

Flaky tests. Tests that sometimes pass and sometimes fail destroy trust. Developers start ignoring failures, and real bugs slip through. Fix or delete flaky tests immediately.

Manual approval gates. A human clicking "approve" before every deploy defeats the purpose. Use automated checks instead. Reserve manual approval for regulated environments only.

Slow pipelines. If CI takes 30 minutes, developers batch changes into large PRs. Large PRs are harder to review and more likely to break. Target under 10 minutes for the full pipeline.

No rollback plan. "We'll fix forward" isn't a plan. Automated rollback on error rate increase should be default.

The tools#

GitHub Actions is the default for most teams in 2026. It's good enough, integrated with your repo, and free for public projects.

See the full pipeline#

On Codelit, search for "GitHub CI/CD" in the command palette (⌘K) to see a complete pipeline architecture — from webhook triggers through job queues, runner pools, build caches, artifact stores, and deploy services. Click any component to audit it.

---

Explore CI/CD architectures: open ⌘K on Codelit.io and search for "GitHub CI/CD" to load the full pipeline instantly.