What Three Stages of CI/CD Maturity Actually Bought You
The same artifact shipped through three different pipelines, and the same three-part question that decides which stage any project actually needs.
Back in the first post of this series, one folder of built files got a name: the artifact. Every post since has been about the pipeline around it, never the folder itself.
That folder never changed. It shipped through three completely different pipelines, and it's worth looking at what actually changed between them, side by side.
The same folder, three levels of care
Push to main. One workflow file, two jobs, one artifact. A static AWS key in a repo secret, hardcoded on purpose.
CI and CD split into two files. Cached, branch-protected, one shared build definition instead of two copies drifting apart.
OIDC instead of a static key. Actions pinned to a commit hash. Permissions denied by default. A production environment with a human gate.
Notice what didn't change anywhere in that progression: the artifact, the build steps, the actual product. Every single change, across all three stages, was about how carefully that one folder got handled on its way out the door.
Naming the problem was the actual skill
At the end of every stage in this series, there was a pros-and-cons list, on purpose. Stage one's cons became stage two's phase goals. Stage two's cons became stage three's.
That's not a coincidence, it's the actual method. A pipeline doesn't need to be perfect at any single stage. It needs to know, explicitly, what's wrong with it right now, so the next stage has a real target instead of a vague feeling that something could be better.
This is the exact same habit as naming a serverless architecture's actual gaps instead of assuming it's finished: a design is only as trustworthy as the honesty of its own known-issues list.
A proof-of-concept with a hardcoded bucket name and no tests isn't an unfinished pipeline. It's a pipeline that correctly named "no tests yet" as an acceptable gap for what it needed to prove. The skill this whole series was actually teaching wasn't any single YAML trick, it was that habit: name what's wrong before deciding whether it's worth fixing right now.
The question that decides which stage you need
You don't need enterprise-grade OIDC and SHA-pinning on a two-person side project, and you don't need to stay on a hardcoded proof-of-concept once a security reviewer is actually looking at your pipeline.
The same three-part question from the start of this series still answers it:
- Are you the only one who can touch this pipeline? Stage one is correct, not lazy.
- Did a second contributor just join, or did someone push straight to main by mistake? That's the signal for stage two.
- Is a security reviewer, an auditor, or real user data now involved? That's the signal for stage three, whether or not the team feels ready.
Think of it the way you'd think about building a house. A foundation is enough until you need to keep the rain out. Walls come next. A roof only matters the moment you actually need to stay dry, not before, and not so late that you're already soaked.
The Essentials
- The artifact never changed. Only the care around it did, across all three stages of this entire series.
- Naming a pipeline's specific, current gaps is the actual skill. Every stage's cons list became the next stage's goals, on purpose.
- The three-part question still decides the stage. Are you alone, did someone else just join, or is a real reviewer now involved. Match the pipeline to the answer, not to what looks impressive.
Further Reading and Watching
Keep reading