Gate promotion with a pre-deploy DQ check

At a glance

Learning objectives

• Attach the DQ suite to a pre-deploy trigger
• Promote only when critical tests pass on staged output
• Block promotion while keeping the previous production data

What you need

• A pipeline that writes to a staging namespace before production
• A dbt or Great Expectations test suite for the model
• A deployment workflow with a pre-deploy stage to register the hook

Steps

1. Wire the check to the pre-deploy trigger, before promotion to production. (from hook-pre-deployment-dq-check )
2. After a pipeline writes to the staging namespace, run the model's dbt/GE tests against the staged output. (from hook-pre-deployment-dq-check )
3. Promote only if all critical tests pass. (from hook-pre-deployment-dq-check )
4. Otherwise leave the previous production data in place and report the failed expectations. (from hook-pre-deployment-dq-check )
5. Confirm the failure behavior is block — a not-null test failing on 412 rows in staging blocks promotion, production untouched. (from hook-pre-deployment-dq-check )

Check yourself

• [object Object]
• The hook's failure_behavior is block — an all-green critical suite is the only path to promotion.

Worked example

# hook-pre-deployment-dq-check
trigger: pre-deploy
purpose: Run the quality suite against a staged run before promoting to production.
failure_behavior: block

After a pipeline writes to the staging namespace, run the model's dbt/GE tests
against the staged output. Promote only if all critical tests pass; otherwise
leave the previous production data in place and report the failed expectations.

A not-null test fails on 412 rows in staging → promotion blocked, production untouched.

Sourced from

• Pre-deployment DQ Check
• Data quality failure

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• The check runs after the pipeline writes to staging — an empty or stale staging namespace has nothing to test.
• Tier the expectations: critical (block) vs warning (alert only) — blocking on a warning-tier expectation turns small blips into outages.
• When the gate blocks, production still serves the previous data — say so in the report instead of assuming the deploy partially landed.

Production considerations

• Promote only on an all-green critical suite; anything else leaves the previous production data in place.
• Report the failed expectations with the block — the operator needs the column, rule and row count.

Diagram

deploy
   |
   |- pipeline writes --> staging namespace
   |
   |- pre-deploy hook --> run dbt/GE tests on staged output
   |
   |- all critical pass --> promote --> production
   |
   |- any critical fail --> block --> production untouched --> report failures

Registry stats