Tests de qualité des données dans les pipelines CI/CD dbt

Tester en production détecte les problèmes après qu’ils atteignent le warehouse. Tester en CI les empêche d’y arriver. Une stratégie efficace de qualité des données utilise les deux : les tests en production comme filet de sécurité, les tests en CI comme barrière.

Slim CI : le fondement

Le pattern Slim CI de dbt Cloud est la pierre angulaire des tests de qualité des données basés sur la CI. Il utilise la comparaison de manifestes pour identifier les modèles qui ont changé et n’exécute que ces modèles ainsi que leurs dépendances en aval :

dbt build --select state:modified+ --defer --state ./

Trois flags rendent cela possible :

• state:modified+ sélectionne les modèles modifiés dans la branche actuelle ainsi que tout ce qui en dépend en aval (le suffixe +). Cela capture à la fois les changements directs et les impacts en cascade.
• --defer indique à dbt de lire depuis le manifeste de production pour tout modèle amont non modifié plutôt que de le reconstruire. Le job CI n’a pas besoin de reconstruire l’intégralité du DAG — seulement la partie modifiée.
• --state pointe vers le répertoire contenant le manifeste de production pour la comparaison.

Résultat : un job CI qui pourrait prendre 45 minutes à tout reconstruire se termine en 2-3 minutes en se concentrant sur ce qui a réellement changé. Les coûts de calcul diminuent de plus de 90 % tout en capturant les régressions dans les modèles modifiés et leurs consommateurs en aval.

Pour dbt Core 1.8+, le flag --empty va encore plus loin en validant les contrats et la structure du schéma sans traiter aucune donnée :

dbt build --select state:modified+ --empty --defer --state ./prod-manifest

Cela permet des vérifications CI purement gouvernance qui se complètent en quelques secondes pour un coût warehouse quasi nul. La validation du schéma, l’application des contrats et les vérifications de compilation s’exécutent toutes sans scanner une seule ligne.

Workflow GitHub Actions

Pour les équipes sur dbt Core (ou souhaitant plus de contrôle que la CI intégrée de dbt Cloud), un workflow GitHub Actions couvre les points de contrôle qualité essentiels :

name: dbt CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint SQL
        run: sqlfluff lint models/
      - name: Build and test modified models
        run: dbt build --select state:modified+ --defer --state ./
      - name: Run data tests
        run: dbt test

Ce workflow applique trois couches de qualité :

1. Le linting SQL capture les violations de style et les anti-patterns SQL courants avant qu’ils n’atteignent le warehouse. SQLFluff est le linter standard pour les projets dbt, avec un support natif du templating Jinja.
2. Build and test compile les modèles, les matérialise dans un schéma CI, et exécute les tests génériques et singuliers associés. Les échecs de compilation font remonter les violations de contrat et les incompatibilités de types. Les échecs de tests font remonter les problèmes de qualité des données.
3. La suite de tests complète exécute tous les tests, y compris ceux non directement associés aux modèles modifiés mais potentiellement affectés par des changements de schéma.

Le pattern state:modified+ nécessite un artefact manifest de production. Stockez-le en tant qu’artefact GitHub Actions depuis votre déploiement en production, dans un stockage cloud, ou dans une branche dédiée. Sans lui, la CI repasse à la reconstruction complète.

Au-delà de build-and-test : outils de détection de régressions

Le workflow CI standard capture les problèmes structurels et basés sur des règles, mais manque les régressions au niveau des valeurs. Un modèle peut être construit avec succès et passer tous les tests tout en produisant des chiffres subtilement différents en raison d’un changement de logique. Trois outils comblent cette lacune.

Datafold

Datafold effectue une différenciation automatique des données entre votre branche PR et la production. Il compare les comptages de lignes, les statistiques au niveau des colonnes et les valeurs réelles entre les tables correspondantes. Le résultat apparaît directement dans votre pull request sous forme de commentaire montrant quelles colonnes ont changé, de combien, et dans quelles lignes.

Cela capture la catégorie de bugs où un modèle refactorisé produit des résultats légèrement différents — peut-être un COALESCE qui gère maintenant les NULLs différemment, ou une condition de jointure qui correspond à moins de lignes. Ces changements passent tous les tests mais produisent des chiffres différents dans les rapports.

Recce

Recce analyse le lignage au niveau des colonnes pour catégoriser les changements comme cassants, partiellement cassants ou non cassants. Plutôt que de comparer les valeurs des données, il examine l’impact structurel de vos changements SQL sur les consommateurs en aval. Un renommage de colonne est classifié différemment d’un changement de filtre, et chaque catégorie déclenche des exigences de révision appropriées.

Cette approche est plus légère qu’une différenciation complète des données et fonctionne bien pour les projets à grande échelle où comparer chaque ligne est prohibitivement coûteux.

SQLFluff

Au-delà du linting basique, SQLFluff applique la cohérence du style SQL au sein d’une équipe. Dans un contexte CI, il empêche les régressions de style d’être fusionnées et garantit que tout le SQL dbt suit les mêmes conventions. Ce n’est pas de la qualité des données à proprement parler, mais la qualité du code impacte directement la qualité des données dans le temps — un SQL incohérent est plus difficile à revoir, plus difficile à déboguer et plus susceptible de contenir des erreurs de logique subtiles.

Ce que la CI détecte que la production ne détecte pas

La valeur des tests CI n’est pas seulement « détecter les bugs plus tôt ». Elle change fondamentalement le mode d’échec :

La différence de coût est significative. Une étude Forrester Total Economic Impact a constaté une augmentation de 30 % de la productivité des développeurs et une économie de 60 % sur le temps de retraitement des données pour les équipes adoptant dbt Cloud avec des workflows CI. Les gains viennent non pas de l’infrastructure CI elle-même mais de l’effet shift-left : les problèmes trouvés dans une PR prennent quelques minutes à corriger, tandis que les problèmes trouvés en production prennent des heures ou des jours.

Séquence d’adoption

• state:modified+ avec des tests basiques élimine la catégorie de régression la plus courante (les changements qui cassent les modèles en aval) et constitue le point de départ à plus fort levier.
• SQLFluff en CI empêche l’accumulation de dette de style. À configurer une fois ; le nettoyage initial des violations existantes est l’effort principal.
• Datafold et les outils similaires de différenciation des données offrent la protection la plus profonde mais nécessitent une infrastructure (schémas de comparaison, stockage d’artefacts) et un budget de calcul. Plus précieux pour les équipes où les régressions au niveau des valeurs sont coûteuses — finance, reporting réglementaire, modèles de tarification.
• Les règles de protection de branche devraient exiger que les vérifications CI passent avant la fusion vers main. Un workflow CI qui ne bloque pas les fusions a tendance à être ignoré.