Versions, Releases et déploiement
Les artefacts déployables d’Ormuz partagent le même modèle de versionnement : chaque sauvegarde significative produit un snapshot immuable, le pointeur Working avance vers le snapshot courant, une Release publie explicitement un snapshot et le déploiement live s’appuie uniquement sur des Releases.
Cycle de vie commun
Éditer fait avancer Working vers un snapshot immuable. Promouvoir ce snapshot crée un jalon durable, puis une Release peut être déployée en live.
Ce modèle s’applique aux Process, Forms, Decisions, Agents, External Tasks et ProcessLaunchers. Les pages propres à chaque artefact décrivent leur contenu exécutable ; cette page définit le contrat de versionnement commun.
Working et snapshots immuables
Working n’est pas une version modifiable en place : c’est un pointeur vers la révision immuable actuellement retenue par l’éditeur. Lorsqu’une sauvegarde change réellement le contenu versionné, Ormuz crée une nouvelle révision et déplace Working vers ce snapshot.
Le contenu est identifié par son hash canonique. Sauvegarder à nouveau sans modifier ce contenu réutilise le snapshot Working existant ; les horodatages de sauvegarde ne font pas partie du contenu versionné et ne provoquent donc pas une nouvelle révision à eux seuls.
Release et déploiement live
Promouvoir un snapshot crée une Release immuable qui référence exactement cette révision. Une Release est un jalon explicite et durable : elle n’est pas supprimée par la rétention automatique des snapshots.
Un environnement live n’accepte pas une dépendance Working flottante. Le déploiement doit résoudre le Process et ses dépendances versionnées vers des snapshots publiés en Release afin de conserver un contrat reproductible.
Rétention des snapshots de travail
Ormuz compacte automatiquement les snapshots ordinaires pour éviter qu’une session d’édition produise un historique de centaines de checkpoints peu utiles. Pour chaque artefact, la plateforme conserve :
- les 5 snapshots ordinaires les plus récents ;
- le dernier snapshot ordinaire de chaque journée UTC pendant les 10 derniers jours ;
- en plus de ces quotas, tout snapshot protégé par son rôle ou par une référence existante.
Un même snapshot peut satisfaire à la fois la règle des cinq plus récents et la règle journalière. La compaction ne renumérote jamais l’historique : les numéros de révision restent monotones même lorsque certains anciens snapshots ne sont plus conservés.
Snapshots encore référencés
La rétention ne supprime pas un snapshot qui participe encore à un contrat reproductible. Sont notamment conservés le snapshot Working, tout snapshot publié en Release, ainsi que les révisions encore référencées par une exécution, un Run, un autre artefact versionné, un historique de déploiement ou un brouillon qui dépend de cette base.
La durée de vie de ces références est indépendante de la fenêtre de 10 jours : tant que la référence existe, le snapshot reste disponible. Lorsqu’elle disparaît, le snapshot redevient éligible à la politique normale de compaction.
Pour le détail d’un artefact, consultez Process, Forms, Decisions ou Agents.