Comparaison de l'expérience développeur des orchestrateurs

Le développement local, les tests et le workflow de review des PR sont là où la friction au quotidien apparaît pour Dagster, Airflow et Prefect — et là où les trois divergent le plus nettement.

Développement local

Dagster : interface complète, sans Docker

Dagster offre la meilleure expérience de développement local des trois. Exécutez dagster dev et vous obtenez l’interface complète sur localhost:3000, sans Docker requis. Vous pouvez matérialiser des assets individuels, inspecter le lignage et voir les logs d’exécution, le tout sur votre laptop.

# Démarrer Dagster en local avec l'interface complète
pip install dagster dagster-webserver dagster-dbt
dagster dev

L’instance locale est fonctionnellement identique au déploiement en production. Vous voyez le même graphe d’assets, le même historique de matérialisation (pour les exécutions locales) et la même visualisation du lignage. Pour l’intégration dbt spécifiquement, le manifest est généré localement via prepare_if_dev(), donc votre graphe d’assets reflète les modèles dbt de la branche courante.

Les tests sont construits autour des I/O typées et des ressources pluggables. Échangez votre ressource BigQuery contre une ressource en mémoire et vos tests s’exécutent sans toucher à l’entrepôt :

from dagster import build_asset_context

def test_daily_metrics():
    # Utilise des ressources en mémoire, pas de connexion à l'entrepôt nécessaire
    context = build_asset_context(
        resources={"bigquery": MockBigQueryResource()}
    )
    result = daily_metrics(context)
    assert result is not None

Prefect a avancé que Dagster requiert « 50+ lignes de configuration de mock » par test. C’est une exagération pour les tests d’assets typiques, mais la configuration des ressources ajoute effectivement du code répétitif comparé au test d’une simple fonction Python. Le compromis est que le système de ressources de Dagster permet une réelle isolation d’environnement — le même code s’exécute contre différents backends en dev, staging et production — tandis que les approches plus simples ont souvent des bugs subtils spécifiques à l’environnement.

Airflow : Docker requis, en amélioration

Airflow a historiquement été pénible en local. Docker est nécessaire, typiquement via le CLI Astro ou docker-compose, et l’itération est lente car le planificateur doit parser les fichiers DAG. La surcharge au démarrage seule — pull des images, démarrage du planificateur, du webserver et de la base de données de métadonnées — peut prendre plusieurs minutes.

# Astro CLI (Airflow managé d'Astronomer)
astro dev init
astro dev start  # Démarre les conteneurs Docker pour le planificateur, le webserver, etc.

Airflow 2.5 a ajouté dag.test() pour exécuter toutes les tâches dans un seul processus Python, ce qui a significativement aidé pour l’itération rapide :

# Test local rapide sans infrastructure Airflow complète
if __name__ == "__main__":
    my_dag.test()

TRM Labs a documenté avoir rendu le développement Airflow 20 fois plus rapide avec des outils personnalisés, réduisant le coût de l’environnement de dev de 200 $/mois à 0 $. Mais leur approche a nécessité un investissement significatif en outillage développeur que la plupart des équipes ne feront pas — runners locaux personnalisés, observateurs de fichiers et simulation d’environnement. Par défaut, le développement local Airflow reste plus lourd que les alternatives.

Le CLI Astro améliore substantiellement l’expérience par défaut. Le rechargement à chaud des fichiers DAG, les images Docker préconfigurées et la gestion d’environnement le rapprochent de la simplicité de dagster dev. Pour les équipes utilisant l’Airflow managé d’Astronomer, l’histoire du dev local est significativement meilleure que l’Airflow nu.

Prefect : la friction la plus faible

Prefect est le plus simple à démarrer en local. Installez le package, démarrez le serveur, et vos flows sont des fonctions Python que vous pouvez appeler directement :

pip install prefect
prefect server start  # Optionnel - fonctionne sans serveur aussi

# Votre flow est juste une fonction Python - appelez-le directement
python my_flow.py

Les tests sont du pytest standard sans mock framework nécessaire :

def test_my_pipeline():
    # Appelez la fonction flow directement - c'est juste du Python
    result = my_pipeline(sources=["test_source"])
    assert result is not None

Pas de Docker, pas de configuration de ressources, pas de génération de manifest. Une fonction Python décorée avec @flow s’exécute exactement comme une fonction Python. Cette simplicité est l’argument le plus fort de Prefect pour les petites équipes qui veulent de l’orchestration sans la surcharge du framework.

Le compromis est que la simplicité des tests de Prefect reflète son abstraction plus simple. Il n’y a pas de concept d’injection de ressources ou de configuration spécifique à l’environnement intégré dans le framework de test, car Prefect n’a pas le système de ressources de Dagster. Pour les équipes ayant besoin de différents backends dans différents environnements, cette gestion de configuration se fait en dehors de l’orchestrateur.

Workflows CI/CD

Déploiements de branches Dagster+

Le différenciateur CI/CD de Dagster est les déploiements de branches. Quand vous ouvrez une pull request, Dagster+ crée automatiquement un environnement de prévisualisation éphémère avec vos modifications de code. Les reviewers peuvent :

• Inspecter le diff du graphe d’assets — quels assets sont nouveaux, modifiés ou supprimés
• Déclencher des matérialisations de test dans l’environnement de prévisualisation
• Vérifier que les vérifications d’assets passent sur des données réelles
• Voir les changements de lignage en parallèle du diff de code

Pour les équipes dbt spécifiquement, cela signifie voir comment vos changements SQL affectent le graphe de données complet avant de merger. Une PR qui renomme un modèle, ajoute une dépendance en amont ou change une stratégie incrémentale produit un diff visuel plus facile à reviewer que la lecture du SQL seul.

Aucun autre orchestrateur n’offre cela par défaut. Pour les équipes qui itèrent fréquemment sur des modèles dbt, les déploiements de branches changent entièrement le workflow de review des PR — de « reviewer le code et faire confiance que les tests CI sont suffisants » à « reviewer le code et voir l’impact sur les données ».

Les déploiements de branches sont une fonctionnalité Dagster+ (cloud managé). L’OSS Dagster auto-hébergé ne les inclut pas.

CI/CD Airflow

Le CI/CD Airflow est plus manuel. Les configurations typiques utilisent GitHub Actions ou similaire pour :

1. Parser les DAGs avec python -c "import my_dag" pour attraper les erreurs de syntaxe
2. Exécuter les tests unitaires pour les opérateurs et plugins personnalisés
3. Déployer les fichiers DAG dans le bucket de stockage DAG (GCS pour Cloud Composer, S3 pour MWAA)

Il n’y a pas d’environnement de prévisualisation intégré. Certaines équipes construisent des environnements staging personnalisés, mais cela nécessite de maintenir une deuxième instance Airflow avec ses propres coûts d’infrastructure. Le pipeline de déploiement d’Astronomer améliore cela avec des déploiements basés sur des images et la promotion d’environnements.

# CI GitHub Actions typique pour Airflow
- name: Validate DAGs
  run: |
    python -c "from airflow.models import DagBag; db = DagBag('.'); assert not db.import_errors"
- name: Run tests
  run: pytest tests/
- name: Deploy
  run: gsutil rsync -r dags/ gs://composer-bucket/dags/

CI/CD Prefect

Le CI/CD Prefect est le plus léger. Les flows sont des fonctions Python, donc le CI Python standard s’applique — linting, vérification des types, pytest. Le déploiement utilise prefect deploy ou la configuration prefect.yaml :

deployments:
  - name: daily-pipeline
    entrypoint: flows/pipeline.py:my_pipeline
    work_pool:
      name: my-cloud-run-pool
    schedule:
      cron: "0 6 * * *"

Pas d’environnements de prévisualisation, mais la simplicité du modèle de déploiement signifie que les déploiements sont rapides et les rollbacks directs — déployez la définition de flow d’un commit précédent.

Résumé de l’expérience développeur

Pour les équipes évaluant ces outils, passer une journée à construire un pipeline simple dans chacun est plus instructif que n’importe quel tableau comparatif. Les points de friction sont personnels — ce qui semble naturel à une équipe semble contraignant à une autre. La recommandation : prototypez avec votre vrai projet dbt, pas un exemple jouet, et prêtez attention au workflow de débogage quand quelque chose casse inévitablement.