dbt Architect: Orchestration, Deployment, and CI/CD

Orchestration questions check that you can schedule, select, and gate dbt runs so production is correct and pull requests are cheap: job design, selectors, state-based selection, deferral, artifacts, and failure handling.

Selection and command semantics

dbt build runs models, tests, snapshots, and seeds in DAG order and skips dependents when a test fails. Running dbt run then dbt test executes everything before testing anything, so a failing test does not stop downstream models. Selectors combine graph operators (+model for ancestors, model+ for descendants, @model for a model plus its tests) with tag:, path:, config.materialized:, and result:/source_status: from a previous run's artifacts.

Slim CI with state

Persist manifest.json from production. In a pull request run dbt build --select state:modified+ --defer --state ./prod-artifacts --target ci. state:modified adds changed models plus tests and exposures that reference them; --defer resolves unbuilt refs to production relations so only changed work is built. Without --defer, CI rebuilds every upstream model; without persisted state there is no diff to compute.

Production job structure

Typical order: dbt source freshness with warn/error thresholds, dbt build, then dbt docs generate so documentation matches deployed state. Use on-run-start/on-run-end hooks for grants or run logging. Chain jobs when a later layer must wait, or use tags inside one job to respect the DAG.

Concurrency and reliability

Overlapping jobs writing the same relations cause locks and deadlocks; serialize them or split by schema. Alert on job failures and on warn-severity tests that matter. Retries help with transient warehouse errors, not data defects.

Worked example

A pull request changes int_orders_enriched and one of its tests. The CI job runs dbt build --select state:modified+ --defer --state prod/ --target ci, rebuilding the changed model, its downstream marts, and their tests, while upstream staging models resolve to production. Merging triggers the deploy job: freshness check, dbt build, docs generation, and artifact upload so the next pull request has current state.

Traps

• state:modified without --defer, pulling full upstream builds into every pull request.
• Overwriting the production manifest with a CI manifest, corrupting the next diff.
• Scheduling two jobs that write the same mart simultaneously.
• Putting --full-refresh in the daily production command.
• Running tests in a separate job whose failures nobody reads.