Les ingénieurs logiciel ne déploient pas de code sans contrôle de version. Ils révisent les diffs, testent en staging et font un rollback quand quelque chose casse. Les workflows IA méritent la même discipline.
Le système de contrôle de version de workflows de JieGou vous donne un historique de versions immuable, des diffs structurels, un rollback en un clic et des déploiements canary — le tout intégré dans l’éditeur de workflow.
Chaque modification crée une version
Quand vous modifiez la structure d’un workflow — ajout, suppression ou réorganisation d’étapes, changement de schémas d’entrée/sortie — JieGou crée automatiquement une nouvelle version. L’historique est en mode ajout uniquement. Rien n’est écrasé.
Chaque version est un instantané complet : chaque étape, chaque mapping d’entrée, chaque définition de schéma, figés dans le temps. Vous pouvez parcourir la chronologie complète de l’évolution d’un workflow, voir qui a fait chaque changement et quand, et comprendre exactement comment un workflow est arrivé à son état actuel.
Cela se passe de manière transparente. Vous éditez les workflows de la même façon que d’habitude — la couche de versioning fonctionne en coulisses.
Diffs structurels
Savoir *qu’*un changement a eu lieu ne suffit pas. Vous devez savoir ce qui a changé.
Le moteur de diff compare deux versions quelconques structurellement. Il identifie :
- Étapes ajoutées — Nouvelles étapes qui n’existaient pas dans la version précédente
- Étapes supprimées — Étapes qui ont été effacées
- Étapes modifiées — Étapes dont la configuration a changé (recette, mappings d’entrée, conditions, configuration de boucle, politique d’approbation)
- Étapes réordonnées — Étapes qui ont changé de position dans l’ordre d’exécution
- Changements de schéma — Champs ajoutés, supprimés ou modifiés dans les schémas d’entrée/sortie
Pour les étapes modifiées, le diff va plus profond. Les structures imbriquées comme les branches conditionnelles (thenSteps / elseSteps), les corps de boucle et les branches parallèles sont comparées récursivement. Vous voyez exactement quel champ dans quelle étape a changé.
Le résultat est un résumé lisible — « 2 étape(s) modifiée(s), 1 étape(s) ajoutée(s), schéma d’entrée modifié » — aux côtés de la vue détaillée du diff.
Le rollback comme nouvelle version
Le rollback ne réécrit pas l’historique. Quand vous revenez à la version 3, JieGou copie les étapes et schémas de cette version dans une toute nouvelle version (disons, la version 8). La chronologie montre l’histoire complète : les versions 4 à 7 ont existé, quelque chose s’est mal passé, et la version 8 est une restauration de la version 3.
Cela signifie que les rollbacks sont sûrs. Vous pouvez toujours avancer à nouveau si le rollback lui-même était une erreur.
Déploiements canary
Le moment le plus risqué pour tout workflow est juste après un changement. Les déploiements canary vous permettent de tester les changements sur une fraction du trafic automatisé avant de vous engager.
Voici comment ça fonctionne :
- Démarrer un canary. Sélectionnez la nouvelle version et un pourcentage de trafic — disons, 10 %.
- Routage automatisé. Quand une planification ou un webhook déclenche le workflow,
resolveWorkflowVersion()génère un nombre aléatoire. 10 % des exécutions sont routées vers la version canary ; 90 % continuent sur la version active. - Les métriques s’accumulent. Chaque exécution enregistre succès/échec, durée et utilisation de tokens contre sa version. Les compteurs Redis agrègent cela en temps réel.
- Promouvoir ou rollback. Quand vous êtes confiant, promouvez le canary en actif (retirant l’ancienne version). Ou faites un rollback si les métriques ne sont pas satisfaisantes.
Pour un fonctionnement automatique, configurez l’auto-promotion : définissez un nombre minimum d’exécutions et un taux de succès minimum. Une fois que le canary atteint les deux seuils, il est promu automatiquement. Si le canary n’a pas atteint le seuil après une limite de temps configurable, il est automatiquement annulé.
L’exécution manuelle utilise toujours la version active sauf si vous en sélectionnez explicitement une autre.
Métriques par version
Chaque version accumule ses propres données de performance :
- Total d’exécutions — Combien de fois cette version a été exécutée
- Taux de succès — Pourcentage d’exécutions terminées sans erreur
- Durée moyenne — Combien de temps l’exécution prend sur cette version
- Nombre d’erreurs — Combien d’exécutions ont échoué
Ces métriques alimentent les décisions de promotion/rollback du canary, mais elles sont aussi utiles pour repérer les régressions. Si la version 5 avait un taux de succès de 98 % et que la version 6 tombe à 91 %, vous savez que quelque chose a changé — et vous pouvez comparer les deux versions pour trouver quoi.
Pourquoi c’est important
Sans contrôle de version, les changements de workflow sont irréversibles. Une mauvaise modification signifie reconstruire manuellement ce à quoi le workflow ressemblait avant. Avec le contrôle de version :
- Les auditeurs peuvent tracer exactement ce qui a changé, quand et par qui
- Les équipes peuvent revoir les diffs avant de promouvoir des changements en production
- Les opérateurs peuvent tester les changements en canary sur du vrai trafic sans risque
- N’importe qui peut faire un rollback instantanément quand quelque chose casse
L’historique de versions et les diffs sont disponibles sur tous les plans. Les déploiements canary et l’auto-promotion sont disponibles sur Enterprise. En savoir plus sur les workflows ou démarrer votre essai gratuit.