01
Développement
branche development
Créez, exécutez, déboguez et publiez les changements avec les services et identifiants de développement.
Publication activée
Workflows IA en production
Passez les workflows IA du développement à la production sans partager les environnements.
Exécutez le développement, le staging et la production dans des instances Dagu distinctes. Promouvez par Git uniquement les définitions relues, tandis que chaque instance conserve ses propres identifiants, workers, historiques, règles d’accès et routes d’incident.
agent-workflow.yaml
name: release-review
steps:
- id: collect_context
run: ./scripts/collect-context.sh
output: CONTEXT
- id: draft
action: harness.run
with:
provider: codex
prompt: |
Review this release:
${steps.collect_context.outputs.CONTEXT}
retry_policy:
limit: 2
approval:
prompt: Review the agent output before release
rewind_to: collect_context
depends: [collect_context]
- id: publish
run: ./scripts/publish.sh
depends: [draft]
Une instance Dagu distincte par environnement
Promotion des workflows après revue Git
Approbations, retries, logs, métriques et traces
Slack, PagerDuty et reprise MCP authentifiée
Architecture des environnements
Git promeut les définitions. Des instances séparées assurent l’isolation.
Un workspace de développement dans un serveur partagé n’est pas une frontière de production. Donnez à chaque environnement son propre serveur Dagu, stockage, identifiants, workers et accès réseau. Configurez Git Sync sur chaque instance pour suivre la branche approuvée pour cet environnement.
Promouvoir par pull request
02
Staging
branche staging
Récupérez les définitions relues dans une instance isolée et validez-les avec les dépendances de staging.
Git Sync en lecture seule
Promouvoir par pull request
03
Production
branche main protégée
Exécutez uniquement les révisions promues avec les identifiants, politiques, télémétrie et routes d’incident de production.
Git Sync en lecture seule
Contrôles de production
Encadrez le travail non déterministe par des contrôles déterministes.
Le modèle ou le runtime de l’agent peut changer sans modifier le contrat opérationnel. Dagu garde le chemin d’exécution explicite, vérifiable et récupérable.
Versionner le workflow
Conservez les DAG et les skills de création de workflows dans Git, relisez les différences et promouvez une révision connue entre environnements.
Contrôler les effets
Mettez en pause après la sortie de l’agent, recueillez l’avis du reviewer puis approuvez, rejetez ou renvoyez le workflow avant toute action en production.
Borner les échecs
Utilisez dépendances, délais, retries limités, files et contrôles de concurrence plutôt qu’une logique de prompts sans limite.
Valider la sortie
Exécutez des tests déterministes, contrôles de politique ou commandes d’évaluation externes comme étapes ordinaires avant approbation ou publication.
Observer l’exécution
Consultez historique, logs et artefacts ; exportez les métriques vers Prometheus et les traces DAG/étapes via OpenTelemetry.
Maîtriser la reprise
Alertez les opérateurs, ouvrez un incident après épuisement des retries et laissez les clients MCP autorisés examiner et récupérer les runs.
Promotion par Git
La production doit consommer Git, pas des modifications locales.
Le développement peut publier des changements. Le staging et la production devraient normalement utiliser `push_enabled: false`, suivre des branches protégées et ne récupérer que les définitions relues. Le staging peut se synchroniser automatiquement ; la production peut suivre automatiquement une branche protégée ou effectuer un pull contrôlé après approbation du déploiement.
Git Sync suit les fichiers DAG et les skills de création de workflows. Les secrets, la configuration serveur, le stockage, l’historique des runs, les workers et l’accès réseau restent propres à chaque instance Dagu.
config.yaml de production
git_sync:
enabled: true
repository: github.com/acme/ai-workflows
branch: main
push_enabled: false
auth:
type: token
token: ${GITHUB_TOKEN}
auto_sync:
enabled: true
on_startup: true
interval: 300
Échec et reprise
Transformez l’échec d’un agent en processus opérationnel.
Dagu sépare les notifications ordinaires du cycle de vie des incidents, puis expose des opérations de workflow authentifiées aux clients MCP.
- 01
Une étape de workflow ou d’agent échoue et exécute ses retries configurés.
- 02
Après épuisement des retries, Dagu envoie l’échec final aux routes Slack configurées.
- 03
Le routage PagerDuty peut ouvrir ou actualiser un incident dédupliqué pour le workflow en échec.
- 04
Un client MCP autorisé lit le run et ses logs, prévisualise une modification de DAG, puis relance ou arrête le run avec les outils Dagu.
- 05
Un run ultérieur réussi résout l’incident ouvert tant que la route du fournisseur reste identifiable.
Limites précises
Ce que Dagu fournit — et ce qui relève d’une autre couche.
Dagu est la couche de contrôle du workflow autour d’un système IA. Des limites claires rendent l’architecture plus sûre et la promesse de production plus utile.
| Dagu fournit | Limite | |
|---|---|---|
| Séparation des environnements | Serveurs, stockages, identifiants, workers, politiques d’accès et réglages d’incident indépendants, avec Git Sync pour les définitions. | Les workspaces et profils d’exécution d’une même instance ne remplacent pas une isolation forte des environnements. |
| Observabilité du workflow | État des runs et étapes, logs, artefacts, historique, métriques Prometheus et traces DAG/étapes OpenTelemetry. | Les traces de prompts, tokens, coûts et la qualité sémantique doivent être émises ou mesurées par l’agent ou la pile d’évaluation. |
| Évaluation et garde-fous | Un graphe pour validateurs déterministes, évaluations externes, approbations et retries bornés. | Dagu ne décide pas si la réponse d’un LLM est factuellement correcte ou sûre pour un domaine donné. |
| Sécurité et incidents | Opérations authentifiées, clés API à portée limitée, notifications, contrôles MCP et routage vers les fournisseurs d’incidents. | Les journaux d’audit et intégrations d’incident en self-hosted exigent une licence ou un essai actif ; Dagu managé les inclut. |
FAQ
Questions pratiques avant la production
Le développement, le staging et la production doivent-ils partager un serveur Dagu ?
Non si l’isolation compte. Utilisez des instances distinctes afin que les identifiants, le stockage, les workers, le réseau, les logs et les politiques ne partagent pas la même frontière opérationnelle. Promouvez les définitions avec Git Sync.
Git Sync copie-t-il les secrets de production ou l’historique des runs ?
Non. Git Sync aligne les DAG et les skills de création avec un dépôt. Les secrets, la configuration, le stockage, l’historique et les workers restent locaux à chaque instance.
Dagu peut-il déterminer si la réponse d’un agent est correcte ?
Pas seul. Dagu peut exécuter vos tests ou outils d’évaluation comme étapes et conditionner l’action suivante à leur résultat, mais la logique d’évaluation appartient à ces outils et aux reviewers métier.
Que peut faire un client MCP pendant un incident ?
Selon l’authentification et les autorisations Dagu, il peut examiner les DAG, runs et logs, prévisualiser ou appliquer des modifications validées, puis démarrer, mettre en file, relancer, arrêter ou suivre des runs.
Étape suivante
Commencez par mettre un workflow d’agent en production.
Placez une commande d’agent existante dans un DAG Dagu, validez sa sortie, ajoutez une frontière d’approbation et promouvez la même définition relue dans des instances de développement, staging et production isolées.