Application engineers wouldn’t ship code without a test suite running on every commit. Most data science and data engineering portfolios do exactly that — a notebook that ran once, on one machine, with no record of whether it would still run tomorrow.
A pipeline that only works on your laptop isn’t finished
“It works on my machine” is a punchline in software engineering for a reason — and data pipelines have the exact same failure mode, just less often called out. A pipeline that depends on a specific local Python environment, a manually-run notebook cell order, or a dataset that happens to sit in the right folder isn’t reproducible. It’s a demo that worked once.
What CI/CD actually adds to a data project
Continuous integration means every change gets automatically tested before it’s trusted. For a data pipeline specifically, that means:
- Automated test runs on every change — not “I ran it once and it looked right,” but a test suite that runs the same checks every single time, catching regressions a human would eventually miss.
- A reproducible environment — pinned dependencies and a defined runtime so the pipeline behaves identically regardless of whose machine (or which server) it runs on.
- A visible pass/fail signal — anyone reviewing the project can see, at a glance, whether the current version actually works, instead of taking a README’s word for it.
A real example: CI on a classification pipeline
The network intrusion detection project runs its full pipeline through GitHub Actions CI, so results on the NSL-KDD benchmark are reproducible on every change — not a one-time notebook run that nobody could rerun and verify. That’s the difference between “trust me, it scored well” and “here’s a pipeline anyone can re-execute and get the same answer.”
Data-quality tests are CI for your data, not just your code
CI/CD in software engineering tests whether the code behaves correctly. In a data pipeline, the equivalent question is whether the data behaves correctly — and that needs its own automated tests, running on every build, not a one-time manual check:
- The retail analytics warehouse runs 35 automated data-quality tests — uniqueness, referential integrity, not-null, accepted values — on every build.
- The Olist e-commerce analytics engineering project runs 34 similar tests against its dbt star schema, on a real dataset of 99,441 orders.
- The retail ETL pipeline gates raw exports behind schema, null, and business-rule checks before anything is trusted downstream — the same instinct as a CI test suite, applied one stage earlier.
None of these tests are exotic. They’re the same category of check a CI pipeline runs on application code — just aimed at rows and schemas instead of functions and classes.
Version tracking is CI/CD’s other half
Testing tells you whether the current version works. Tracking tells you whether the new version is actually better than the last one. The support ticket triage platform logs every model iteration in MLflow specifically so a retrained model gets compared against its predecessor before it’s trusted to route real tickets — the ML equivalent of not deploying a new build until it passes the test suite.
A quick checklist
- Does your pipeline run the same way on a fresh machine, or does it depend on your specific local setup?
- Do you have automated tests that run on every change, or a manual check you did once?
- Does your data get validated on every run — schema, nulls, business rules — or only when something looks visibly wrong?
- If you retrain a model, can you tell whether the new version actually improved on the old one?
A project that answers yes across the board reads as engineering discipline. A project that answers no reads as a script that happened to work once — and reviewers who’ve been burned by pipelines like that can tell the difference immediately.
FAQ
Do I need a full CI/CD pipeline for a portfolio project?
Even a single GitHub Actions workflow that runs your tests on every push demonstrates the habit. It doesn’t need to be elaborate — it needs to exist and actually run.
What’s the difference between testing code and testing data?
Code tests check that functions produce correct outputs given known inputs. Data tests check that the data itself — which you don’t control the way you control code — meets expectations: no unexpected nulls, referential integrity intact, values within accepted ranges.
Is dbt test the same thing as a CI pipeline?
Not by itself — dbt test defines and runs the data-quality checks, while a CI tool like GitHub Actions is what triggers those checks automatically on every change. Together they cover both halves: what to check, and when to check it.
