Why I am writing about this
When I worked on my first product, an SAP module with custom code, that was my only exposure to CI/CD. I thought that was just how CI/CD was done.
Then I learned more about CI/CD elsewhere and desperately wanted to move away from SAP. I thought we were doing it wrong, and that there was no way to do it right in the SAP space.
Now, with four product experiences under my belt, I can see that delivery pipelines are not one size fits all. At least not when you're building internal products.
I think this reality needs to be named, so we can give ourselves context on where we're sitting, and what's actually possible in our own space.
The CI/CD Maturity Checklist
Before we walk through each scenario, here's the simple checklist I use to score any delivery pipeline:
- Is the code or config in git, with real version history?
- Do automated tests run before anything merges?
- Are Dev, Test, and Production actually separate?
- Does code move between environments without someone doing it by hand?
- Can you roll back without a person scrambling to fix it?
Five yes answers means a mature pipeline. Zero means you're where most of us started.
I'll use this same checklist under every scenario below.
1. Legacy / Old Software
No CI, no CD. Just a person and a deploy script, or maybe not even that.
Deployments are manual and happen during scheduled maintenance windows, usually run by the one person who knows where all the bodies are buried.
If something breaks, rollback means redeploying the last version that worked and hoping for the best.
Maturity check: 0 out of 5. Even the deploy steps usually aren't written down anywhere.
Next step to level up: Get the deploy steps into a script that lives in version control, even if a person still runs it by hand. That one move is what makes rollback and audits possible at all.
2. Business Intelligence: Report Layer
Power BI reports and Tableau dashboards. The kind of product where the logic lives directly inside the report file itself.
Because the report is one file, most teams can't really track what changed the way a developer would. Moving a report from draft to live is usually a manual publish step. Version history exists, but it works more like a basic save history than real source control.
Maturity check: 1 out of 5. Most teams do have separate Dev and Prod spaces, but that's usually the only box checked.
Next step to level up: Here, the honest next step isn't a fix, it's acceptance. You're working within the limits of the tool itself, and that's fine. Save your energy for the layer feeding the report, not the report itself, more on that below.
3. Classic SAP (ECC)
Classic on-premise SAP. Every change moves through a strict Dev, then QA, then Production path, one formal request at a time.
Changes are packaged into formal transport requests and approved through a change management process before they can move to the next system. It's manual and sequential, but it is at least controlled.
Maturity check: 1 out of 5. The Dev, QA, Production separation is real and enforced. Nothing else on the checklist is.
Next step to level up: Upgrading to a cloud-based SAP setup opens up a lot more options here, including real version control. That's usually a bigger conversation than a quick technical fix, but it's the direction that unlocks everything else.
4. Regulated Environments
Healthcare, finance, government, or anywhere under formal compliance rules.
The technology might fully support automating the entire release. The block is policy, not tech. Change boards, approval rules, and audit sign-offs require a human to look before anything ships, on purpose.
Maturity check: this one doesn't score cleanly, since the same rules can sit on top of a mature pipeline or an immature one. The one box that's always unchecked by design is the last step, automated promotion or rollback, whichever one legally needs a person.
Next step to level up: Push to automate everything up to the required sign-off, so the manual step is the only manual step left, not the whole process. That's a governance conversation, not an engineering one.
5. Mobile Apps
Mobile apps, where the delivery pipeline itself can be fully automated.
Tools can handle the build, the tests, and packaging a release with no manual steps on your end. But it still has to pass through app store review, typically a day or two, sometimes longer, which is a human gate you don't control. And even after approval, people update on their own schedule, so "shipped" and "everyone has it" are two different milestones.
Maturity check: 4 out of 5. Version control, tests, environment separation, and build automation are usually all there. The last point, getting the release live, depends on a gate outside your pipeline entirely.
Next step to level up: Tighten your internal testing process before you submit, so review rejections stop being your actual bottleneck. That's the piece you can control.
6. Business intelligence: Data Layer
The layer underneath the report. The actual data and calculations that feed what you see on the dashboard.
This layer is often built more like real software. Changes are tracked properly, tested automatically before anything goes live, and reviewed before they're approved. So even when the report itself can't be put through a real pipeline, what feeds it often already is.
Maturity check: 4 out of 5. Version control, tests, environment separation, and automated promotion are all real here. Rollback is the one that's genuinely harder. Undoing a bad data change isn't as clean as undoing a code change.
Next step to level up: Write down an actual plan for reversing a bad change before you need it, so that gap doesn't stay theoretical until the day it matters.
7. Modern Web App
What most people picture when they hear "CI/CD."
Every change starts on its own copy of the code, gets tested automatically, and only becomes part of the main version once it passes. From there it moves through a staging environment into production automatically, and if something breaks, it can roll back on its own.
Maturity check: 5 out of 5.
Next step to level up: There isn't a technical one left. The only ongoing work is keeping the discipline as the team and the codebase grow.
Final Conclusion
So, is your team doing CI/CD wrong?
Probably not. You're just doing it in SAP, or in a spreadsheet tool, or under an audit committee, instead of in a clean git repo with a friendly test suite.
Score yourself honestly against the checklist above. Then improve the one box you can actually move, not all five.
