Stop CI Abuse

It's time to fix our pipelines

Stop CI Abuse

Continuous Integration (CI) has revolutionized the way we ship software—but it's time we acknowledge a hard truth: we're abusing it.

In this manifesto, we're using "CI" to mean CI/CD—the entire workflow of validating and shipping software. CI is great for testing and validating changes. CD is great for deploying those validated changes. But too often, everything else gets thrown into the mix, and the result is a bloated, fragile, non-portable mess.

It's time to stop.

What CI/CD Was Meant For

CI/CD was designed to:

  • Run fast, deterministic tests to validate code on every commit.
  • Provide quick feedback loops so developers can fix issues before merging.
  • Help maintain clean, working main branches.
  • Deploy tested, production-ready code automatically and safely.

Good CI/CD pipelines are fast, focused, and tightly scoped. They help engineering teams ship better code more often.

Signs You're Abusing CI/CD

🔁 You're rerunning failed builds just to "unstick" them. 🐢 Your CI takes 20+ minutes for every PR. 🔀 It runs E2E, security, infra, and perf tests in one massive flow. ⏱️ It's used as a job scheduler instead of a validation tool. 💸 You're spending more on CI than your production infra. 🧩 You can't reproduce a CI failure locally. 🧾 You're writing and debugging YAML instead of code.

CI/CD is not your release pipeline. It's not your staging environment. It's not a batch job runner. It's not your security scanner of last resort.

Common Abuses of CI/CD

Cron Overload

  • ❌ Used as a generic cron scheduler for unrelated jobs
  • ❌ Running security scans that should live in a dedicated security pipeline or platform
  • ❌ Automating dependency updates that trigger entire pipelines unnecessarily

Good Intentions, Bad Execution

  • ⚠️ 100+ distinct jobs in a single workflow—impossible to maintain or reason about
  • ⚠️ Constantly retrying flaky tests instead of fixing them
  • ⚠️ Test runs that take 20+ minutes and delay feedback

Local Development Nightmare

  • ❌ CI-only secrets and ephemeral environments make local reproduction impossible
  • ❌ YAML-based workflows are not portable—you have to push and pray
  • ❌ Debugging is slow and opaque: commit, push, wait, fail, repeat

This isn’t about vendor lock-in. It’s about developer experience. If you can’t run it locally, you don’t control it.

What Belongs in CI/CD

  • ✅ Unit tests
  • ✅ Linting, static analysis
  • ✅ Fast, deterministic integration tests
  • ✅ Code formatting checks
  • ✅ Build and packaging steps that are under 5–10 minutes
  • ✅ Validated deploys to staging and production (CD)

These should be:

  • Fast (ideally under 10 minutes)
  • Parallelizable
  • Deterministic (no flakes)
  • Reproducible locally
  • Directly tied to software correctness and delivery

What Belongs Outside of CI/CD

  • ❌ Long-running E2E tests
  • ❌ Infrastructure drift detection
  • ❌ Performance benchmarks
  • ❌ Security scans that take 30+ minutes
  • ❌ Scheduled jobs or backups
  • ❌ Ad hoc maintenance tasks or cron jobs

These should run in their own pipelines—triggered by events, schedules, or dedicated workflows—not every single time a developer pushes code.

Better Alternatives

Instead of cramming everything into CI/CD, consider:

  • Pre-merge CI: fast and focused, for code validation
  • Post-merge CD: scoped to deploy and verify builds
  • Nightly regression suites: slow, broad, catch-all tests
  • On-demand test environments: spin up only when needed
  • GitOps or infra workflows: separate from application CI

A Smarter CI/CD Philosophy

Design your pipelines like you design products:

  • With clear intent
  • With measurable outcomes
  • With developer experience in mind

Use the right tool for the job—and CI/CD becomes powerful again.

Join the Movement

Is your team abusing CI/CD? Do you know someone who is?

Let’s stop CI abuse. Together.

Sign the Pledge