Gestion des versions

Chaque workflow vit dans deux mondes complémentaires : une version MAIN, toujours vivante et idéale pour itérer vite, et des versions numérotées, figées une fois en production, qui garantissent la reproductibilité. Comprendre cette distinction est la clé pour développer sans friction tout en livrant en toute sécurité.

MAIN et versions numérotées : le bon réflexe

	MAIN	Versions numérotées (ex. 1.2.0)
Rôle	Ligne de développement permanente	Snapshots nommés, traçables
Évolution	Toujours modifiable, même si déployée ailleurs	Après déploiement : plus aucune modification du graphe ni de la logique
Ajustements possibles	Tout peut changer	Uniquement le niveau de tracing (les autres paramètres restent figés)
Production	Non déployable en environnement de production	C’est le format adapté au déploiement en production

En pratique : vous développez et testez sur MAIN (boucle courte, changements immédiats) ; vous figez une version semver lorsque le comportement vous convient, puis vous déployez cette version vers la prod — pas MAIN.

La version MAIN : toujours en mouvement

MAIN est la version en continu : elle reflète l’état courant du workflow tel que vous l’éditez. Ce n’est pas un snapshot figé.

• Idéal pour développer : vous modifiez le flux, vous enregistrez, vous retestez — sans créer de version à chaque essai.
• Déployée ou non, elle reste éditable : même si MAIN est déployée sur un environnement non productif (dev, recette, etc.), vous pouvez continuer à la modifier. Les prochaines exécutions prendront en compte ces changements : parfait pour tester instantanément une idée ou corriger un détail.
• Effet immédiat : pas de cycle « créer une version → redéployer » tant que vous restez sur des environnements où MAIN est autorisée.

MAIN et production

La version MAIN ne peut pas être déployée en production. Pour tout environnement de production, vous devez passer par une version numérotée (fork semver), puis déployer celle-ci. C’est ce qui protège la prod contre des changements non contrôlés sur une ligne toujours mobile.

Les versions numérotées : semver et immuabilité

Lorsque vous créez une version (fork avec un numéro), vous produisez un identifiant stable (1.0.0, 1.1.0, etc.). Cette version porte son changelog et son historique.

Règle importante : dès qu’une version numérotée est déployée, elle devient immutable pour tout ce qui définit le comportement du workflow (nœuds, connexions, logique métier, etc.). Vous ne pouvez plus « retoucher » cette version pour la faire évoluer : il faut créer une nouvelle version (nouveau numéro).

Seule exception : vous pouvez encore ajuster le niveau de tracing sur une version déjà déployée — utile pour diagnostiquer sans republier une release.

Format de version (SemVer)

Utilisez le Semantic Versioning pour que tout le monde comprenne l’impact d’une release :

• MAJOR : changements incompatibles (ex. 2.0.0)
• MINOR : nouvelles fonctionnalités rétrocompatibles (ex. 1.1.0)
• PATCH : corrections sans changement d’API fonctionnelle attendu (ex. 1.0.1)

Créer une version (fork)

Ecosystem matérialise une nouvelle version numérotée par un fork du flux courant.

Depuis l’éditeur

1. Travaillez sur votre workflow (souvent à partir de MAIN une fois le comportement stabilisé).
2. Cliquez sur Create Version, Version ou Fork (libellé selon l’interface).
3. Renseignez le formulaire :
   • Version : numéro SemVer (1.0.0, 1.1.0, 2.0.0, …)
   • Changelog : résumé des changements (fortement recommandé)
4. Validez avec Create.

La nouvelle version apparaît dans l’historique ; vous pourrez la déployer sur l’environnement voulu (rappel : le trigger doit être déployé sur le même environnement).

Statuts côté versions

Selon le contexte à l’écran, vous croiserez encore des libellés de statut :

• DRAFT : brouillon / édition en cours (non prêt pour les mêmes usages qu’une release semver).
• MAIN : ligne vivante, modifiable à tout moment ; pas de déploiement en production.
• DEPLOYED : la version est (ou a été) associée à au moins un déploiement — pour une version numérotée déployée, le contenu fonctionnel est gelé (sauf tracing).

Gérer les versions dans l’interface

Liste des versions

1. Ouvrez la fiche du workflow.
2. Allez dans l’onglet Versions.
3. La liste affiche notamment : numéro, date de création, changelog, statut.

Consulter une version

1. Onglet Versions.
2. Cliquez sur la ligne de la version.
3. Visualisez le graphe tel qu’il était pour cette release.

Déployer une version

1. Onglet Versions.
2. Choisissez la version (en production, une version semver, pas MAIN).
3. Deploy → choix de l’environnement → confirmation.

Pour le détail des prérequis (trigger, environnements), voir Déployer un workflow.

Bonnes pratiques

• Itérer sur MAIN, figer en semver avant une montée sensible ou la prod.
• Ne jamais compter sur MAIN en production : toujours une version numérotée dédiée.
• Changelog systématique : vos futurs vous remercieront au rollback ou à l’audit.
• Tracing : montez le niveau sur une version déjà déployée pour déboguer sans nouvelle release.
• SemVer discipliné : MAJOR quand le contrat de comportement casse, MINOR pour les ajouts compatibles, PATCH pour les correctifs.

Prochaines étapes

• Déployer un workflow
• Tester un workflow