Gestion des Releases : Suivez Chaque Déploiement à Travers Votre Architecture
Il y a deux mois, j'ai assisté à un post-mortem où la question centrale était d'une simplicité trompeuse : "Quelle version du Service de Paiement tourne en production en ce moment ?"
Quatre personnes ont donné trois réponses différentes. L'une a vérifié la page des releases GitHub. Une autre a ouvert ArgoCD. Une troisième a scrollé dans le canal Slack des déploiements. La quatrième — celle qui avait effectivement déployé — était en vacances.
Ce n'était pas une startup. C'était une équipe avec un pipeline CI/CD mature, de bonnes pratiques de tagging, et un diagramme d'architecture bien maintenu dans Archyl. Le diagramme disait exactement quels systèmes existaient, comment ils étaient connectés, quels protocoles ils utilisaient. Il ne pouvait simplement pas dire quelle version de quoi que ce soit tournait réellement. Où que ce soit.
Ce manque me dérange depuis un moment. La documentation d'architecture vous dit la structure d'un système. L'historique de déploiement vous dit l'état d'un système. Ces deux choses devraient vivre ensemble. À partir d'aujourd'hui, c'est le cas.
Des Releases Liées à l'Architecture
La gestion des releases d'Archyl suit les déploiements en tant qu'objets de première classe dans votre espace d'architecture. Une release a une version, un statut, un environnement, un changelog, et — point crucial — un lien vers l'élément C4 auquel elle appartient.
C'est cette dernière partie qui fait la différence avec votre tableau de bord CI/CD. Un run GitHub Actions vous dit que v2.4.0 a été déployée. Mais déployée où, dans le contexte de votre architecture ? Quel système ? Quel conteneur ? Les releases d'Archyl répondent à cette question en connectant les événements de déploiement directement aux systèmes et conteneurs de votre diagramme C4.
Quand vous ouvrez le panneau de détail d'un système, vous voyez ses releases récentes aux côtés de ses relations, ADR et contrats d'API. Le diagramme d'architecture devient une carte vivante — pas seulement de ce qui existe, mais de ce qui a été livré et quand.
Trois Façons d'Ingérer
Nous ne voulions pas que le suivi des releases signifie plus de travail manuel. Si vous déployez déjà via un pipeline, les releases devraient arriver dans Archyl automatiquement.
GitHub Actions — Nous publions une GitHub Action officielle que vous ajoutez à votre workflow de déploiement. Un setup minimal, c'est deux lignes dans votre YAML. L'action envoie la version, le SHA du commit, l'environnement et le changelog à Archyl à chaque déploiement réussi. Elle supporte aussi des champs personnalisés — lier à un système ou conteneur spécifique, définir le statut, inclure l'auteur.
- uses: archyl/release-action@v1
with:
api-key: ${{ secrets.ARCHYL_API_KEY }}
version: ${{ github.ref_name }}
C'est tout. Chaque release taguée apparaît désormais dans votre espace d'architecture.
Webhooks — Configurez un endpoint webhook dans les paramètres de votre projet, puis pointez les webhooks de release GitHub ou GitLab dessus. Quand une nouvelle release est publiée ou un tag est poussé, Archyl reçoit l'événement et crée une entrée de release automatiquement. Vous pouvez définir un pattern de tag (par ex. v*) pour filtrer quels tags créent des releases, et assigner un environnement par défaut pour que les releases créées par webhook atterrissent au bon endroit.
API REST — Pour les équipes utilisant Jenkins, CircleCI, Bitbucket Pipelines ou tout autre outil CI/CD, l'endpoint d'ingestion accepte un simple payload JSON. Authentifiez-vous avec une clé API, envoyez la version et les métadonnées, et la release apparaît dans Archyl. C'est la solution universelle — si votre outil peut faire une requête HTTP, il peut reporter des releases.
Les trois méthodes sont configurées dans les paramètres du projet sous l'onglet Releases, avec des snippets de code copiables et des clés API pré-remplies.
Environnements
Tous les déploiements ne se valent pas. Pousser en staging, c'est de la routine. Pousser en production, c'est un événement. La gestion des releases suit les deux, séparément.
Les environnements sont définis par l'utilisateur et associés à un code couleur. Créez "Development", "Staging", "Production" — ou tout ce que votre équipe utilise. Chaque release est taguée avec son environnement cible, et vous pouvez filtrer la timeline pour ne voir que les déploiements production, ou uniquement ce qui est en staging en ce moment.
Le modèle d'environnement est flexible. Une équipe gérant un seul service pourrait avoir deux environnements. Une équipe plateforme gérant quarante microservices pourrait en avoir cinq. Vous définissez ce qui a du sens pour votre projet, et les releases s'organisent en conséquence.
La Timeline
La timeline des releases est la vue principale. Les releases sont regroupées par mois, affichées en ordre chronologique inverse, avec des badges de version, des tags d'environnement et des indicateurs de statut. C'est la réponse à "qu'est-ce qui s'est passé récemment ?" — en un coup d'œil.
Chaque entrée de release affiche :
- Version — Le tag semver ou identifiant (par ex.
v2.4.0,3.12.0-rc.2) - Statut — Deployed, In Progress, Planned, Failed ou Rolled Back
- Environnement — Badge coloré (Production, Staging, etc.)
- Élément lié — Le système ou conteneur auquel cette release appartient
- Source — D'où vient la release (GitHub Action, webhook, API, manuelle)
- Changelog — Ce qui a changé, qui l'a écrit, les informations signed-off-by
Cliquez sur n'importe quelle release pour ouvrir son panneau de détail avec le changelog complet, les dates (créée, déployée, mise à jour), les éléments C4 impactés et un lien vers la source (commit, page de release GitHub, etc.).
La Matrice de Déploiement
Pour les équipes gérant plusieurs services à travers plusieurs environnements, nous avons construit une seconde vue : la Matrice de Déploiement.
C'est une grille où les lignes sont vos systèmes et conteneurs, les colonnes sont vos environnements, et chaque cellule montre la dernière release déployée pour cette combinaison. D'un coup d'œil, vous pouvez voir que l'Account API est en v3.1.0 en production mais en v3.2.0-beta en staging. Ou que le Notification Service n'a pas été déployé en production depuis trois semaines.
La matrice rend la dérive d'environnement visible. Quand les versions staging et production divergent, vous le repérez immédiatement. Quand un service prend du retard pendant que les autres avancent, l'écart est évident.
Cycle de Vie des Statuts
Les releases ne sont pas toujours propres. Les déploiements échouent. Les releases sont annulées. Nous suivons le cycle de vie complet :
- Planned — La release existe mais n'a pas encore été déployée. Utile pour suivre les versions à venir.
- In Progress — Le déploiement est en cours. Défini automatiquement par les intégrations CI/CD pendant l'étape de déploiement.
- Deployed — La release est en ligne dans son environnement cible. Le cas nominal.
- Failed — Le déploiement n'a pas réussi. L'entrée de release reste comme trace de ce qui a été tenté.
- Rolled Back — La release a été déployée puis ensuite annulée. Cela préserve l'historique — vous pouvez voir que
v2.3.1a été rollbackée, quand, et pourquoi.
Les transitions de statut sont automatiques avec les intégrations CI/CD, ou manuelles quand on crée des releases via l'interface.
Liaison aux Éléments d'Architecture
Chaque release peut être liée à un système, un conteneur, ou les deux. C'est ce qui donne aux releases leur contexte architectural.
Dans les paramètres du projet, vous configurez une cible de liaison par défaut — le système et optionnellement un conteneur où les releases seront attachées. Les snippets de code pour GitHub Actions, les webhooks et l'API REST se mettent à jour automatiquement pour inclure les bons identifiants d'éléments.
Sur le diagramme, les éléments liés affichent leur historique de releases dans le panneau de détail. Faites un clic droit sur un conteneur et vous voyez non seulement ses relations et contrats, mais aussi sa timeline de déploiement. C'est là que la documentation d'architecture et la réalité opérationnelle convergent.
Pourquoi C'est Important
Les diagrammes d'architecture ont toujours été un instantané figé. Ils vous montrent ce que le système est — les boîtes, les flèches, les protocoles. Mais ils ne montrent pas ce que le système fait. Ce service est-il sur la dernière version ? Quand a eu lieu le dernier déploiement ? Quelqu'un a-t-il rollbacké la release de mardi dernier ?
Ce sont des questions qui reviennent dans chaque revue d'architecture, chaque réponse à incident, chaque onboarding. Et jusqu'ici, la réponse était toujours "vérifie l'outil CI/CD" ou "demande à l'équipe qui le gère."
La gestion des releases met l'historique de déploiement là où il doit être : sur l'architecture elle-même. Quand quelqu'un demande "quelle version tourne sur la Payment Gateway ?", la réponse est là, sur le diagramme — pas dans un outil différent, pas dans un onglet différent, pas dans la tête de quelqu'un.
C'est la même philosophie que les Contrats d'API et les ADR : la documentation d'architecture devrait répondre aux vraies questions qui se posent chaque jour, pas seulement décrire la structure dans l'abstrait.
Pour Commencer
Naviguez vers les Paramètres de votre projet et ouvrez l'onglet Releases. Choisissez votre méthode d'intégration — GitHub Action, webhooks ou API REST — et suivez le guide de configuration. Créez vos environnements, liez un système ou conteneur cible, et livrez votre première release.
À partir de là, chaque déploiement arrive automatiquement dans votre espace d'architecture. Vos diagrammes C4 cessent d'être des plans statiques et deviennent un registre vivant de ce qui tourne réellement.
Votre architecture est plus que de la structure. Maintenant, vos outils le reflètent.
Vous voulez en savoir plus sur comment connecter votre architecture à la réalité ? Découvrez comment les Contrats d'API lient vos specs au diagramme, ou comment les Demandes de Changement d'Architecture apportent un workflow de pull request à votre modèle C4.