There's a complaint I keep running into in DevOps threads, usually from someone who has just cleaned up after a bad release. The team treated its CI/CD pipeline as its release process, and it turned out the pipeline couldn't carry that weight.
I'm not an engineer, and I won't pretend to know your pipeline better than you do. Full disclosure: I'm Head of Marketing at Y2 / Release Management Apps, and we build release tooling for Jira, so I'm not neutral on this. What I can offer is the view of someone who reads a lot of these threads. The same few gaps show up again and again, and some engineers have described them publicly better than I could.
The short version: a pipeline answers whether an artifact can be built, tested, and pushed to an environment. Release management answers whether the release should go live, what's in it, and who said yes. The two questions sit right next to each other, which is probably why teams mix them up.
Gap one: approval is a decision, and the pipeline only sees a click
On Adobe's Experience League community, a user once filed a small feature request. In their stage pipeline, an accidental click on Approve sent the build to production, with no way to cancel. They asked for a confirmation dialog.
It's almost funny, but it shows how thin approval gets when it lives only inside the pipeline. One button, one mouse slip, production.
The other side of the same problem shows up in audits. A vCISO describes the first SOC 2 audit they sat in on with an engineering team. The pipeline was good: trunk-based, tests gated on merge, everything in Terraform. The auditor picked a date from the deploy history and asked for proof that the code shipped that day had been reviewed by someone other than its author. Everyone knew it had. Nobody could show it. By the author's count, answering for one change meant linking five artifacts across four systems.
Neither story is about a bad pipeline. In a company of any size, approval is a business decision made by people who often don't have pipeline access: a CAB, a compliance officer, a product owner. They approve a defined scope, for a defined environment, at a defined time. The button in the pipeline is where that decision gets recorded. When the button becomes the only record, the question "on whose authority?" has no good answer.
Gap two: nobody can say what's running where
The most detailed story I found is from a DevOps engineer at a licensed broker with seven production environments across different jurisdictions.
Before they reworked their process, finding out which version ran in a given environment meant checking the cluster or asking in chat. The engineer admits, with some humor, that chat really was their source of truth for a while. When auditors started asking who deployed version X to environment Y, when, and who approved it, each answer turned into a small investigation. The Jira ticket was half filled in, the logs were somewhere, and the person who clicked the button remembered everything but happened to be on vacation.
What I find telling is how they fixed it. The pipeline stayed. Around it they added change tickets in Jira created automatically for every deployment, one status model for everything, a single registry of environments, and one Slack thread per deployment. Put simply, they built a release management layer on top of CI/CD, with Jira as its record.
Gap three: dependencies live in people's heads
The same write-up has a quieter detail that I think many teams will recognize. Their main CRM has a companion component that has to run exactly the same version. With manual releases, that companion was often forgotten, and background jobs started failing hours later. The engineer also notes that the correct deployment order and the quirks of each environment weren't written down anywhere, so a new engineer needed months before anyone trusted them with a release.
A pipeline has no idea that service B has to go out together with service A unless someone tells it. In most teams I read about, that knowledge sits in a spreadsheet, a stand-up, or the memory of whoever has been around longest. When that person leaves, the dependency map leaves with them.
Branches don't have stakeholders
The workaround that comes up most in these threads is letting a branching strategy stand in for a release process. GitFlow, trunk-based with release tags, a release branch per quarter. The branch is the release: cut it, stabilize it, tag it, ship it.
It holds up for a while. Then a few things happen. The CAB approves a set of changes described in plain language, and nobody there is looking at release/2026.q2, so keeping the two in sync becomes manual work that goes stale within a sprint. The same branch can sit in UAT for one client and in production for another, and the branch won't tell you which. And once you're at ten teams, each with its own convention, the release becomes whatever shape appears where those conventions meet. You can't really govern that shape. You negotiate it every Friday afternoon.
Branching is a source control concept. Release management is an organizational one. They overlap, and that's about where the similarity ends.
A layer above the pipeline
The way I've come to think about it, release management is a layer that sits above CI/CD and answers its own set of questions:
- What's in this release?
- Who approved that scope, and on what basis?
- Which environments has it reached, and which are still waiting?
- What else does it depend on?
- Who outside engineering needs to know, and when?
The pipeline tells you whether a deployment succeeded. This layer tells you whether it should have happened, what it contained, and who needs to hear that it's live.
Visibility is a big part of it. Release information that lives only in the pipeline UI is visible to the people who open the pipeline UI, which usually means ops. Product, support, compliance, and the release manager end up asking in Slack. Someone writes the answer into a document, the document goes stale in a week, and the cycle starts again. The broker's engineer counts the end of "what's in prod?" messages in chat among the changes they enjoyed most, and I believe them.
Where this leaves us
None of these stories is about a broken pipeline. The SOC 2 team's setup sounds like something most engineering leads would be proud of, and the broker's releases worked before they changed anything. What failed was everything around the pipeline: the evidence, the scope, the map of what runs where. CI/CD was never meant to hold that, and it's worth giving it a proper home before an auditor or an incident asks for it.
I'm curious where that home is on your team today. The pipeline, a Jira board, a Confluence page, or someone's head? Tell me in the comments, especially if the honest answer is the last one.
