Dagster Branch Deployments pour dbt

Les branch deployments de Dagster+ créent un environnement de prévisualisation éphémère pour chaque pull request. Pour les équipes dbt, cela permet d’inspecter les assets modifiés, le nouveau graphe de dépendances et les matérialisations de test avant la fusion — sans affecter la production.

Les branch deployments couvrent l’ensemble du graphe d’assets, pas seulement les modèles dbt. Si une PR modifie un asset Python en amont d’un modèle dbt, l’impact complet est visible. Si un sensor déclenchant des runs dbt est modifié, le branch deployment reflète le nouveau comportement de déclenchement. Le périmètre est plus large que les jobs CI de dbt Cloud, qui ne couvrent que les modèles dbt.

Ce que montrent les Branch Deployments

Lorsqu’une PR modifiant des modèles dbt est ouverte, le branch deployment :

1. Crée une instance Dagster séparée avec le code de la branche, incluant le manifest.json mis à jour issu du projet dbt modifié.
2. Affiche le diff du graphe d’assets. Les nouveaux assets apparaissent en surbrillance. Les assets modifiés montrent ce qui a changé. Les assets supprimés sont signalés.
3. Permet des matérialisations de test. Il est possible de matérialiser les assets modifiés dans l’environnement de prévisualisation pour vérifier qu’ils se compilent correctement, produisent les données attendues et réussissent leurs asset checks.
4. Montre l’impact sur la lineage. Si un modèle a été renommé, si une nouvelle dépendance a été ajoutée ou si les références upstream d’un modèle ont changé, le diff du graphe le rend visible en parallèle du diff de code.

Pour les équipes pratiquant des tests dbt rigoureux, les branch deployments ajoutent une couche de revue visuelle. Les réviseurs peuvent inspecter le diff du graphe d’assets en même temps que le diff de code dans la PR. Cela détecte une catégorie de problèmes que la revue de code seule ne voit pas : un modèle qui compile et passe les tests, mais qui introduit un chemin de dépendance inattendu ou casse la lineage prévue.

Sélection basée sur l’état

Pour les workflows CI/CD, Dagster prend en charge la sélection basée sur l’état qui reproduit le comportement state:modified de dbt Cloud. Cela permet de n’exécuter que les modèles modifiés et leurs dépendances downstream en CI, en maintenant des builds rapides même dans les grands projets.

Le principe fonctionne en comparant le manifest de la branche avec le manifest de production. Les modèles qui diffèrent — nouveaux modèles, SQL modifié, configurations changées — sont sélectionnés pour l’exécution. Leurs dépendants downstream sont inclus pour vérifier que les changements ne cassent rien en aval.

Pour un environnement BigQuery, c’est particulièrement utile pour la maîtrise des coûts. Un projet dbt de 200 modèles où une PR en modifie 3 n’exécutera que ces 3 modèles plus leurs dépendances downstream, pas les 200. Avec la tarification au byte de BigQuery, cela peut réduire les coûts de build CI de plus de 90 % par rapport aux builds complets.

Exécution par partitions

Le système de partitions de Dagster fonctionne avec les modèles incrémentaux de dbt. Il est possible de définir des partitions journalières et de matérialiser des plages de dates spécifiques, ce qui correspond à passer --vars à dbt avec la date de partition.

from dagster import DailyPartitionsDefinition

@dbt_assets(
    manifest=my_project.manifest_path,
    partitions_def=DailyPartitionsDefinition(start_date="2025-01-01"),
)
def my_dbt_assets(context, dbt: DbtCliResource):
    time_window = context.partition_time_window
    dbt_vars = {
        "min_date": str(time_window.start),
        "max_date": str(time_window.end),
    }
    yield from dbt.cli(
        ["build", "--vars", str(dbt_vars)],
        context=context,
    ).stream()

Cela offre :

• Des backfills ciblés. Dans l’UI Dagster, il suffit de sélectionner une plage de dates et de matérialiser uniquement ces partitions. Pas besoin d’écrire des scripts de backfill personnalisés ni de passer manuellement des paramètres de date.
• Une surveillance par partition. Chaque partition possède son propre statut de matérialisation. Il est possible de voir que le 15 janvier a réussi mais que le 16 janvier a échoué, puis de ne relancer que la partition en échec.
• Un alignement incrémental. Les dates de partition correspondent directement à la clause WHERE dans le bloc is_incremental() du modèle incrémental. Dagster passe les dates ; dbt filtre sur celles-ci.

Pour les équipes utilisant la stratégie insert_overwrite sur BigQuery ou la stratégie microbatch (dbt 1.9+), les partitions Dagster s’alignent naturellement avec la gestion des partitions native de dbt. L’orchestrateur et l’outil de transformation s’accordent sur ce que signifie « traiter les données du 16 janvier ».

Matérialisations sélectives

Au-delà du CI/CD et de l’exécution par partitions, l’UI Dagster prend en charge la matérialisation sélective ad hoc. Il est possible de :

• Sélectionner un seul asset et le matérialiser avec ou sans ses dépendances upstream.
• Sélectionner un asset et tous ses descendants — le pattern « j’ai corrigé ce modèle, maintenant je reconstruis tout ce qui en dépend ».
• Utiliser la syntaxe de sélection dbt dans la configuration de run pour cibler des tags, des dossiers ou des noms de modèles spécifiques.

C’est utile pour des scénarios opérationnels que dbt Cloud gère mais que les orchestrateurs plus simples (Cloud Run Jobs, planificateurs basés sur cron) ne prennent pas en charge :

• Un modèle mart a produit des données incorrectes. Corriger le SQL, matérialiser ce modèle et ses marts downstream, laisser tout le reste intact.
• Une table source a été backfillée avec des données historiques corrigées. Matérialiser le modèle de base et propager le rafraîchissement à travers les couches intermédiaires et mart.
• Un nouveau modèle a été ajouté en milieu de sprint. Matérialiser uniquement le nouveau modèle et ses tests pour vérifier qu’il fonctionne dans l’environnement de production avant le prochain run planifié.

Le flux CI/CD

Un workflow CI/CD typique pour dbt dans Dagster combine les branch deployments avec la sélection basée sur l’état :

1. Le développeur ouvre une PR avec les modèles dbt modifiés.
2. Le pipeline CI construit le manifest depuis la branche (dbt deps && dagster-dbt project prepare-and-package).
3. Le branch deployment crée un environnement de prévisualisation avec le nouveau manifest.
4. La sélection basée sur l’état identifie les modèles modifiés et leurs descendants.
5. Les matérialisations de test s’exécutent dans l’environnement de prévisualisation avec les asset checks.
6. Le réviseur inspecte à la fois le diff de code et le diff du graphe d’assets.
7. La fusion déploie le manifest mis à jour en production.

Ce workflow offre plus de confiance que le CI de dbt Cloud pour les équipes avec des pipelines mixtes Python/dbt, car le branch deployment teste l’ensemble du graphe d’assets, pas seulement la partie dbt. Pour les équipes purement dbt, l’expérience est comparable au CI de dbt Cloud, avec en plus l’avantage du diff visuel du graphe.

Quand les Branch Deployments s’appliquent

Les branch deployments et la sélection basée sur l’état sont des fonctionnalités de Dagster+ (l’offre cloud managée). Dagster OSS auto-hébergé ne les inclut pas. Pour les équipes évaluant Dagster vs dbt Cloud, les capacités CI/CD sont comparables : Dagster couvre un périmètre cross-système ; dbt Cloud ne nécessite pas de configuration supplémentaire pour les projets purement dbt.

La valeur s’accroît avec la complexité du projet. Un projet dbt de 20 modèles sans assets Python bénéficie peu de cette fonctionnalité — dbt build en CI atteint la même validation. Un projet de 200 modèles avec ingestion Python en amont et features ML en aval bénéficie du diff complet du graphe sur chaque PR.