Dbt Deployment: Commands and CI/CD

Goal: master the dbt Command Line Interface (CLI) and implement efficient CI/CD pipelines.

1. The Essential Commands

While there are many commands, you will spend 90% of your time with these four.

dbt compile

Compiles your code into raw SQL in the target/ folder.

• Use when: Debugging complex Jinja logic without waiting for execution.

dbt run

Runs your models.

• Use when: You are actively developing and need to materialize tables.

dbt test

Runs your tests.

• Use when: You want to validate data quality without rebuilding tables.

dbt build ⭐️

The gold standard. It runs seeds, snapshots, models, and tests in dependency order.

• Why it’s better: If an upstream model fails, dbt build skips downstream models to save time and compute.
• Use when: Always, especially in CI/CD.

2. Surgical Precision: Node Selection

Don’t run the whole project every time. Use --select (or -s).

Basic Selection

1
2
3

dbt run --select stg_green_tripdata  # Run one model
dbt run --select models/staging      # Run a directory
dbt run --select tag:nightly         # Run by tag

Graph Operators (+)

The real power comes from selecting dependencies.

• +my_model: Run model and everything upstream.
• my_model+: Run model and everything downstream.
• +my_model+: Run model and all related lineage.

Scenario: You changed a staging model. You want to test the impact downstream.

1

dbt build --select stg_green_tripdata+

3. Advanced CI/CD: “Slim CI”

In a large project, running everything on every Pull Request is too slow and expensive. Enter Slim CI.

The Logic

1. State: dbt compares your current code against a “manifest” (artifact) from a previous run (usually Production).
2. Modified: It identifies which models have changed.
3. Run: It runs only the modified models and their downstream dependencies.

The Command

1

dbt build --select state:modified+ --state ./prod-artifacts

• state:modified: The changed models.
• +: Their downstream children (to ensure you haven’t broken anything).
• --state: Path to the manifest.json from production.

4. Deployment Environments

Always separate Dev from Prod.

• Dev: Local schema (e.g., dbt_alice). Sandbox for experimentation.
• Prod: Production schema (e.g., analytics). Read-only for humans, writable only by the Orchestrator.

Command:

1

dbt build --target prod

This concludes our series on Analytics Engineering with dbt. Happy modeling!