Versioning

Votre architecture évolue en permanence. Le versioning vous donne les mêmes garanties qu'un dépôt Git, mais appliquées à vos schémas : historique complet, points de restauration, travail en parallèle et fusion maîtrisée.

Pourquoi versionner son architecture ?#

Une architecture n'est jamais figée : services ajoutés, dépendances qui changent, refontes successives. Sans versioning, ces évolutions posent trois problèmes concrets.

• Le risque du changement. Modifier une vue partagée, c'est risquer de casser la référence sur laquelle toute l'équipe s'appuie. Impossible d'expérimenter sereinement.
• La perte de mémoire. Six mois plus tard, personne ne sait plus pourquoi l'architecture a changé, ni à quoi elle ressemblait avant.
• La comparaison manuelle. Sans outil, comparer deux états revient à poser deux captures d'écran côte à côte et à chercher les différences à la main.

Le versioning résout ces trois points en appliquant à vos schémas les réflexes d'un dépôt Git : expérimenter sans risque, tracer chaque évolution, comparer et fusionner proprement.

Cas d'usage#

Tester une refonte sans rien casser#

Vous envisagez de découper un monolithe en microservices. Créez une branche, modélisez la cible, faites-la relire, puis fusionnez-la une fois validée. La vue de production reste intacte pendant toute l'exploration.

Préparer une revue d'architecture#

Avant une revue, posez un tag sur l'état à présenter. Vous disposez d'un point de référence stable et immuable, même si le projet continue d'évoluer en parallèle.

Comprendre ce qui a changé#

Au moment de fusionner une branche, la prévisualisation du merge liste ce qui a été ajouté, supprimé ou modifié, nœud par nœud, pour arbitrer en connaissance de cause. La comparaison visuelle entre deux versions quelconques de l'historique arrive prochainement.

Revenir en arrière après une mauvaise décision#

Un choix s'avère inadapté ? Restaurez un tag antérieur et repartez d'un état sain, sans avoir à reconstruire le schéma à la main.

Stabiliser les vues d'ensemble#

Un projet d'équipe embarque plusieurs projets liés. Épinglez chaque projet lié sur un tag précis pour que votre vue globale ne bouge pas à chaque modification des équipes en amont.

Fonctionnement#

Versions nommées et tags#

Chaque projet conserve un historique de ses modifications. Nommez une version pour marquer un état important (une mise en production, une revue d'architecture) et posez un tag immuable dessus pour y revenir à tout moment.

Branches#

Créez une branche pour explorer un changement sans toucher à la vue de production. Vous testez une refonte, une migration ou une hypothèse en isolation, puis vous la fusionnez une fois validée, ou vous l'abandonnez.

Merge sémantique#

La fusion réconcilie deux branches en tenant compte de la sémantique de l'architecture (composants, connexions, propriétés), pas seulement du visuel. Le diff est calculé nœud par nœud : la prévisualisation du merge met en évidence ce qui a été ajouté, supprimé ou modifié, et signale les conflits, présentés pour être arbitrés avant d'être appliqués.

Diff visuel entre versions (à venir)#

La comparaison de deux versions de l'historique, en surimpression directement sur le canvas, arrive prochainement. Aujourd'hui, ce sont la restauration d'un tag et la prévisualisation du merge qui vous permettent de suivre les évolutions.

Épinglage des projets liés#

Quand un projet en embarque un autre via les Projets Liés, vous choisissez sur quelle version il pointe : la dernière en date, un tag figé ou une branche précise. Vos vues d'ensemble restent stables même quand les projets sous-jacents évoluent.

Disponibilité#

Les tags sont inclus à partir du plan Pro. Les branches, le merge et l'épinglage des projets liés sont inclus à partir du plan Team. La protection de branches avec revue obligatoire est réservée au plan Enterprise. Voir la page Tarifs pour le détail.