The state of CI/CD in 2026

Fifteen years into “CI/CD” as an industry obsession, here is where things actually stand: one vendor won the default slot, the tool everyone declared dead in 2019 is still running half the world’s builds, and the median pipeline is still slow, flaky, and over-privileged.

I say this as a practitioner, not a spectator. I’ve run Chef-driven Jenkins pipelines on a defense program, CodeDeploy at a healthcare startup, and today I own CI/CD for a platform org where the pipelines gate infrastructure touching hundreds of millions of requests a day.

GitHub Actions won by default, and default is the operative word

When GitHub shipped Actions in 2019, it wasn’t the best CI system available. It won anyway, because it sat where the code already lived and the marginal cost of adopting it was one YAML file. That’s the whole story. Not superior scheduling, not a better execution model. Proximity.

The consequence is that Actions is now the thing most teams mean when they say CI, and its weaknesses are the industry’s weaknesses:

• Runner economics get ugly at scale. Hosted minutes are convenient until the bill says otherwise, and then you’re running self-hosted runners, which means you’re back in the infrastructure business you were trying to leave.
• The marketplace model outsources trust. Every third-party action you reference is code you run with access to your secrets. The compromise of the widely-used tj-actions/changed-files action in early 2025 leaked secrets from thousands of repositories, and it will not be the last incident of its shape. Pin actions to commit SHAs. Yes, it’s tedious. Do it anyway.
• Workflow YAML doesn’t compose well. Reusable workflows and composite actions help, but a 40-repo org still ends up with 40 slightly different copies of the same pipeline unless someone owns the paved road.

None of this is disqualifying. It’s the standard toolchain now and fighting that default needs a reason. But “everyone uses it” and “it’s good” are different claims.

Jenkins refuses to die because it does something real

Jenkins is a punchline in conference talks and a load-bearing wall in a very large share of the enterprises I’ve worked with. Both things are true.

The reason it persists isn’t inertia alone. Jenkins is still the tool you reach for when the job doesn’t look like “build a container from a git push”: hardware in the loop, air-gapped environments, decade-old build chains, approval flows that map to an org chart. At Raytheon our Jenkins pipelines orchestrated Chef deployments into environments that would never touch a SaaS CI vendor, for reasons the compliance team could recite from memory.

What’s actually wrong with most Jenkins installations is operational, not architectural. Nobody owns them. Plugins accrete until an upgrade becomes a gamble. The controller becomes a pet with 400 jobs nobody can rebuild. If that describes yours, the problem isn’t that Jenkins is old. It’s that you’ve been treating CI as furniture instead of as production infrastructure.

The keys problem is finally solvable, so solve it

For most of CI’s history, deploying to AWS meant a long-lived access key in a secrets store, and that key was the single most attractive theft target in the company. OIDC federation ended the excuse. Your CI job proves its identity to the cloud provider with a short-lived token, scoped to a repo and branch, and there is no stored credential to steal.

GitHub Actions has supported this since late 2021. GitLab, Buildkite, and CircleCI all have equivalents. If your pipelines still authenticate with stored cloud keys in 2026, that’s a choice, and in my view an indefensible one. This site deploys through OIDC role assumption with zero stored AWS credentials, and setting that up took an afternoon.

What still hurts

The unsolved problems in CI/CD are mostly not tool problems.

Slow pipelines are an engineering-discipline problem. The 40-minute pipeline usually contains ten minutes of work and thirty minutes of accumulated ritual: dependency installs that ignore the cache, tests that rebuild the world, artifact uploads nobody downloads, and quality gates bolted on years ago by teams that no longer exist. Nobody profiles the pipeline because the pipeline isn’t anyone’s job.

Flaky tests are a culture problem. Retries paper over them, and then the retry becomes the culture. A pipeline that fails 20% of the time has stopped being a gate; it trains people to click rerun until the light goes green.

And deployment, the CD half of the acronym, is still where the maturity gap lives. Plenty of teams with pristine CI still deploy by clicking. GitOps tooling (Argo CD in particular, which I run in production) has made Kubernetes deployment genuinely declarative and auditable. Outside Kubernetes, the story is patchier.

Merge queues deserve a mention as real progress: GitHub’s went GA in 2023, and for busy trunks they eliminate the “green PR, red main” class of failure outright.

What I’d actually pick

For a team starting today, on GitHub, without exotic constraints: GitHub Actions with OIDC to your cloud, actions pinned by SHA, reusable workflows owned by one team, and a merge queue once you have enough traffic on main to need it. Argo CD if you’re on Kubernetes.

If you’re carrying a Jenkins estate, either resource it like production or plan its retirement. The worst position is the common one: depending on it and neglecting it at the same time.