Three simple questions:
- Who controls your source data?
- Do you trust them not to change it?
- When something changes - how do you usually find out about it?
What is Trust? How about: “repeatedly demonstrating you do as you say you will do”
Trust in data is the heart of this demo because 'Trust' and 'Hope' lead to very different outcomes.
- Provde a database with a green release.
- Introduce change that will break the release / normal operations and finally
- Catch and communicate the failure before a technical issue becomes a Trust issue.
The pipeline supports four scenarios via demoScenario:
baseline: No breakage (expected green run)schema: Schema driftduplicates: Duplicate keyreference: Business rule breakage (orphaned order, date sequence and pricing).
This supports a quick side-by-side of a clean deployment versus a blocked one.
The pipeline is organized into three stages:
ResetAndSeedIntroduceIssue(skipped for baseline)DQ_Gates
In DQ_Gates, both tools run, publish evidence, and fail the pipeline if either gate fails.
You need:
- An Azure SQL Database reachable from Azure DevOps hosted agents.
- An Azure DevOps service connection.
- A Key Vault containing
SQL-HOSTandDB-NAME. - A contained database user for the service principal.
The pipeline uses Entra ID token authentication — no SQL passwords are stored. It acquires a short-lived Azure SQL access token at runtime via Azure CLI and uses that token for SQL script execution and scanning.
For the actual setup steps, use SETUP.md.
The DQ_Gates stage installs dependencies from requirements.txt, runs both validation toolchains, and publishes artifacts as dq-evidence.
Expected evidence includes:
artifacts/soda_scan.logartifacts/soda_summary.txtartifacts/great_expectations_results.jsonartifacts/great_expectations_summary.txtartifacts/great_expectations_data_docs.htmlartifacts/soda_exit_code.txtartifacts/gx_exit_code.txtartifacts/pipeline_diagnostics.txt
- Run with
demoScenario=baselineto show a passing deployment and gate run. - Run with
demoScenario=schemato show schema drift detection. - Run with
demoScenario=duplicatesto show uniqueness failure. - Run with
demoScenario=referenceto show referential and business-rule failure. - Review the
dq-evidenceartifact and pipeline logs.
azure-pipelines.yml: Demo pipeline with reset, defect injection, and quality gates.sql/: Reset, seed, and break scripts.quality/soda/: Soda configuration and checks.quality/ge/ge_validate_orders.py: Great Expectations validation script.docs/log_review.txt: Simple log review template.
Use SETUP.md once to prepare Azure SQL, Key Vault, and the Azure DevOps service connection. After that, start with demoScenario=baseline and then run one failing scenario.