One path to production, and it is the pipeline

Most teams have a pipeline. Fewer have a pipeline that is the only way to change production. Somewhere alongside it there is a console login with write access, a script on someone’s laptop, or a setting that was fixed by hand during an incident and never written down.

Each of those made sense on the day it happened. Together they mean the code in the repository no longer describes what is running, and nobody can say with confidence what a fresh deploy would change.

The practice we push for is simple to state: one path to production, and it is the pipeline. Application code, infrastructure, and configuration all go the same way.

Every exception becomes the process

The side door always opens for a good reason. A customer is down, the pipeline is slow, the change is one line. So someone edits it in place, and it works.

The trouble starts on the next deploy. The pipeline rebuilds from the repository, the hand fix disappears, and the outage comes back looking like a new bug. Or the fix survives, and now production depends on a change that exists nowhere but production. We have watched teams spend a full day diagnosing a problem that turned out to be a months-old manual edit that only one person remembered making.

After a few of these, “just this once” is the real deployment process and the pipeline is the ceremonial one.

What one path actually means

• Infrastructure is code. Networks, permissions, queues, and DNS are defined in the repository and applied by the pipeline, not created in a console and documented later.
• People read production; the pipeline writes to it. Day-to-day access is read-only. Write access exists for emergencies, is logged, and every use ends with the change going back through the repository.
• Configuration and secrets have a home. Values live in a managed store and are referenced by name from code, so a changed setting has a history and a reviewer like anything else.
• Rollback is a deploy. Going back means shipping the previous known-good version through the same path, not reversing steps by memory at two in the morning.

For federal teams this has a second payoff. The audit trail for “who changed what, when, and who approved it” stops being a document someone assembles before an assessment. It is the commit history and the pipeline log, produced as a side effect of doing the work.

Make the path fast enough that nobody routes around it

A rule that says “always use the pipeline” fails the first time the pipeline takes an hour and production is down. People are not being careless when they route around a slow process. They are being rational, and the fix is to change the math.

That means a pipeline measured in minutes, with the slow checks split so the ones that gate a release run first. It means an emergency lane that skips nothing that matters, just waits for nothing that doesn’t. And it means the people on call have practiced the fast path before they need it, so the pipeline is the obvious choice under pressure rather than the brave one.

This matters more as more code is written with AI assistance. When changes arrive faster, the pipeline is where the hardening a senior engineer is accountable for actually gets enforced. A side door skips all of it.

Where to start

Do not try to close every door at once. Pick one service. Remove standing write access to its production environment for a sprint and keep a list of every time someone needed it. That list is your backlog: each item is either something the pipeline should do, or something that should not be happening at all.

When the list stays empty for a few weeks, move to the next service. It is slow, unglamorous work, and it is the difference between knowing what is running and hoping. It is also where our cloud, DevOps and platform work usually starts.