👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
Most teams I talk to will tell me they have a pipeline.
They have GitHub Actions. Or Jenkins. Or Azure DevOps. The build compiles, the Docker image gets pushed, a deploy script runs, and a green checkmark shows up next to the commit. That’s a pipeline, right?
It isn’t.
What they have is build and deployment automation. The green checkmark only proves the code compiled. Nothing in that verified that the code actually works before the bytes reach a customer.
I know this because the symptom is always the same.
The release went out on Tuesday. By Wednesday morning, the support inbox is full — somebody broke a critical path that nobody tested. Someone stays late. War room reconvenes.
And it ends with the line every senior engineer has heard a hundred times: “the pipeline didn’t catch it.”
The pipeline didn’t catch it because there was no pipeline. There was a conveyor belt.
A Pipeline Has Checkpoints, NOT Steps
Here is the part most teams skip: a pipeline is not a sequence of build steps. It is a sequence of checkpoints.
Because steps just run.
But a real pipeline doesn’t just move code forward. It asks at every checkpoint:
“Does this build move forward?”
If the answer is no, everything stops.
Most “pipelines” don’t do that.
They just run jobs until they’re done and call it success.
“The Pipeline Didn’t Catch It”
Each stage ran. Each stage passed.
But there were no tests.
So the bugs slipped through.
A real pipeline tests the system at each stage:
“Does it work on my machine?”
Commit Stage — compile, run the fast tests (unit, narrow integration, component, contract), run static analysis, package, publish. Fast. Under five minutes. Triggered on every push.
“Does it work when deployed?”
Acceptance Stage — deploy it and runs system tests (smoke, acceptance, external system contract, E2E).
“Do we release it?”
Release Stage — takes it through QA and into production.
Each stage verifies something different. Each stage can stop the pipeline. The Commit Stage’s job is not the Acceptance Stage’s job, and treating them as one big “CI/CD workflow” is how you end up with code that “passed CI” but breaks the moment it gets deployed.
If you compile and deploy but never run the deployed code and check whether the deployed version does what it is supposed to do, you’re skipping the most important point.
You Didn’t Deploy the Same Build You Tested
Now here’s the part that quietly breaks most pipelines — even the ones with good tests.
The Commit Stage produces a build (e.g. a backend image and a frontend bundle). And from that point on, every stage is supposed to run the same build.
No rebuilds. No separate “QA build.” No special “production image.”
Testing the SAME build makes deployments predictable. "Works in Acceptance" means it will work in Production, because it's the same build.
The moment you rebuild between stages — even to swap a config, even to “just bump the version” — the guarantee disappears. The build your tests verified is not what is shipped.
This is the single most common quiet failure mode I see in real pipelines. The team did the work. They wrote the tests. They setup up the stages. And then somewhere in the middle, a “for deployment convenience” rebuild crept in and silently invalidated the whole chain.
Is It a Pipeline or Just Automation?
If you want to know whether your team has a pipeline or just automation, ask three questions:
1. What does the green checkmark prove?
“The code compiled” — this is a build, not a pipeline.
“The code was tested” — this is a pipeline.
❌ Just ran
✅ Verified behavior
2. What runs between commit and production?
If the answer is “compile, package, deploy,” you’re missing the Acceptance Stage. The pipeline cannot tell you whether the version works — only that it built.
❌ Just built
✅ It works
3. Are you running the same build in production that you tested earlier?
If you rebuild between stages, the answer is no. If you cannot tell, the answer is also no.
❌ Different built
✅ Same build
If any of those answers comes back wrong, the green checkmark is lying to you.
A pipeline is not a deploy script.
It is a sequence of checkpoints that decide whether a build should move forward.
If your green checkmark only means “it compiled and got deployed,” then you don’t have a pipeline — you have a conveyor belt that moves broken code faster.
And that’s why release day still feels like a gamble.
👉 I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.
No rebuild tricks. No “it passed CI but broke anyway” surprises.
€100 off with code EARLYBIRD100 — limited spots.
A real pipeline: it's the difference between 'it ran' and 'it was verified'.
Yess, we need to talk more of what CI really means!