The Mental Model
CI/CD for analytics engineering applies software delivery discipline to data models: compile, test, document, review, and deploy with clear gates.
Before a change reaches users, it should pass the same kind of gate a backend service would pass. Does it build? Do tests pass? What downstream objects change?
Tiny Example
We will use a small ecommerce dataset throughout the course. Think of these as the only tables in your first warehouse:
| Table | Grain | Example columns |
|---|---|---|
raw_orders | one row per order event | order_id, customer_id, amount, status, created_at |
raw_order_items | one row per item inside an order | order_id, product_id, quantity, item_price |
raw_customers | one row per customer | customer_id, email, country, created_at |
Interactive Check
Question: A pull request changes dim_customers.country. Which models should CI run?
Reveal the answer
Run dim_customers, its direct downstream models, and any tests or metrics affected by country. In mature setups, state-aware selection handles this from lineage.
Inline Practice Lab
This lab is intentionally small. You can solve it by reading the table, writing the SQL/YAML mentally, or pasting the snippet into any SQL scratchpad later.
-- Example starter table
select
order_id,
customer_id,
amount,
status,
created_at
from raw_orders;
The goal is not tooling setup. The goal is learning the production habit: state the grain, clean one thing, test one assumption, and explain the downstream impact.
Self-Check Quiz
- What is the grain of the table you are building?
- Which downstream metric or dashboard would be wrong if this model broke?
- What test would catch the most likely beginner mistake here?