Release-Management: Verfolgen Sie Jedes Deployment in Ihrer Architektur

Vor zwei Monaten saß ich in einem Post-Mortem, bei dem die zentrale Frage täuschend einfach war: "Welche Version des Payment Service läuft gerade in Produktion?"

Vier Personen gaben drei verschiedene Antworten. Eine prüfte die GitHub-Releases-Seite. Eine andere öffnete ArgoCD. Eine dritte scrollte durch den Slack-Deploy-Kanal. Die vierte — diejenige, die tatsächlich deployed hatte — war im Urlaub.

Das war kein Startup. Das war ein Team mit einer ausgereiften CI/CD-Pipeline, guten Tagging-Praktiken und einem gut gepflegten Architekturdiagramm in Archyl. Das Diagramm zeigte exakt, welche Systeme existierten, wie sie verbunden waren, welche Protokolle sie verwendeten. Es konnte nur nicht sagen, welche Version von irgendetwas tatsächlich lief. Nirgendwo.

Diese Lücke stört mich schon seit einer Weile. Architekturdokumentation sagt Ihnen die Struktur eines Systems. Deployment-Historie sagt Ihnen den Zustand eines Systems. Diese beiden Dinge sollten zusammenleben. Ab heute tun sie das.

Releases, Verknüpft mit der Architektur

Archyls Release-Management verfolgt Deployments als erstklassige Objekte in Ihrem Architektur-Workspace. Ein Release hat eine Version, einen Status, eine Umgebung, ein Changelog und — entscheidend — eine Verknüpfung zum C4-Element, zu dem es gehört.

Dieser letzte Punkt macht den Unterschied zu Ihrem CI/CD-Dashboard. Ein GitHub-Actions-Run sagt Ihnen, dass v2.4.0 deployed wurde. Aber deployed wohin, im Kontext Ihrer Architektur? Welches System? Welcher Container? Archyls Releases beantworten das, indem sie Deployment-Events direkt mit den Systemen und Containern in Ihrem C4-Diagramm verbinden.

Wenn Sie das Detail-Panel eines Systems öffnen, sehen Sie dessen aktuelle Releases neben seinen Beziehungen, ADRs und API-Verträgen. Das Architekturdiagramm wird zu einer lebendigen Karte — nicht nur davon, was existiert, sondern was ausgeliefert wurde und wann.

Drei Wege zur Ingestion

Wir wollten nicht, dass Release-Tracking mehr manuelle Arbeit bedeutet. Wenn Sie bereits über eine Pipeline deployen, sollten Releases automatisch in Archyl einfließen.

GitHub Actions — Wir veröffentlichen eine offizielle GitHub Action, die Sie in Ihren Deployment-Workflow einfügen. Ein minimales Setup sind zwei Zeilen in Ihrer YAML-Datei. Die Action sendet Version, Commit-SHA, Umgebung und Changelog bei jedem erfolgreichen Deploy an Archyl. Sie unterstützt auch benutzerdefinierte Felder — Verknüpfung mit einem bestimmten System oder Container, Status setzen, Autor angeben.

- uses: archyl/release-action@v1
  with:
    api-key: ${{ secrets.ARCHYL_API_KEY }}
    version: ${{ github.ref_name }}

Das ist alles. Jedes getaggte Release erscheint nun in Ihrem Architektur-Workspace.

Webhooks — Konfigurieren Sie einen Webhook-Endpoint in Ihren Projekteinstellungen und richten Sie dann die Release-Webhooks von GitHub oder GitLab darauf. Wenn ein neues Release veröffentlicht oder ein Tag gepusht wird, empfängt Archyl das Event und erstellt automatisch einen Release-Eintrag. Sie können ein Tag-Pattern festlegen (z.B. v*), um zu filtern, welche Tags Releases erstellen, und eine Standard-Umgebung zuweisen, damit Webhook-erstellte Releases am richtigen Ort landen.

REST-API — Für Teams, die Jenkins, CircleCI, Bitbucket Pipelines oder ein anderes CI/CD-Tool verwenden, akzeptiert der Ingest-Endpoint einen einfachen JSON-Payload. Authentifizieren Sie sich mit einem API-Key, senden Sie Version und Metadaten, und das Release erscheint in Archyl. Dies ist die universelle Lösung — wenn Ihr Tool eine HTTP-Anfrage machen kann, kann es Releases melden.

Alle drei Methoden werden in den Projekteinstellungen unter dem Releases-Tab konfiguriert, mit kopierbaren Code-Snippets und automatisch ausgefüllten API-Keys.

Umgebungen

Nicht alle Deploys sind gleich. Nach Staging zu pushen ist Routine. Nach Produktion zu pushen ist ein Ereignis. Release-Management verfolgt beides, getrennt.

Umgebungen sind benutzerdefiniert und farbcodiert. Erstellen Sie "Development", "Staging", "Production" — oder was auch immer Ihr Team verwendet. Jedes Release wird mit seiner Zielumgebung getaggt, und Sie können die Timeline filtern, um nur Produktions-Deploys zu sehen, oder nur was gerade in Staging ist.

Das Umgebungsmodell ist flexibel. Ein Team, das einen einzelnen Service verwaltet, hat vielleicht zwei Umgebungen. Ein Plattform-Team, das vierzig Microservices verwaltet, hat vielleicht fünf. Sie definieren, was für Ihr Projekt sinnvoll ist, und die Releases organisieren sich entsprechend.

Die Timeline

Die Release-Timeline ist die primäre Ansicht. Releases werden nach Monat gruppiert, in umgekehrter chronologischer Reihenfolge angezeigt, mit Versions-Badges, Umgebungs-Tags und Status-Indikatoren. Es ist die Antwort auf "Was ist kürzlich passiert?" — auf einen Blick.

Jeder Release-Eintrag zeigt:

• Version — Der Semver-Tag oder Identifier (z.B. v2.4.0, 3.12.0-rc.2)
• Status — Deployed, In Progress, Planned, Failed oder Rolled Back
• Umgebung — Farbcodiertes Badge (Production, Staging, etc.)
• Verknüpftes Element — Das System oder der Container, zu dem dieses Release gehört
• Quelle — Woher das Release stammt (GitHub Action, Webhook, API, manuell)
• Changelog — Was sich geändert hat, wer es geschrieben hat, Signed-off-by-Informationen

Klicken Sie auf ein Release, um das Detail-Panel mit dem vollständigen Changelog, Daten (erstellt, released, aktualisiert), betroffenen C4-Elementen und einem Link zurück zur Quelle (Commit, GitHub-Release-Seite, etc.) zu öffnen.

Die Deployment-Matrix

Für Teams, die mehrere Services über mehrere Umgebungen verwalten, haben wir eine zweite Ansicht gebaut: die Deployment-Matrix.

Dies ist ein Raster, in dem die Zeilen Ihre Systeme und Container sind, die Spalten Ihre Umgebungen, und jede Zelle das zuletzt deployete Release für diese Kombination zeigt. Auf einen Blick können Sie sehen, dass die Account API auf v3.1.0 in Produktion ist, aber auf v3.2.0-beta in Staging. Oder dass der Notification Service seit drei Wochen nicht mehr in Produktion deployed wurde.

Die Matrix macht Umgebungsdrift sichtbar. Wenn Staging- und Produktionsversionen divergieren, erkennen Sie es sofort. Wenn ein Service zurückfällt, während andere voranschreiten, ist die Lücke offensichtlich.

Status-Lebenszyklus

Releases sind nicht immer sauber. Deploys scheitern. Releases werden zurückgerollt. Wir verfolgen den gesamten Lebenszyklus:

• Planned — Das Release existiert, wurde aber noch nicht deployed. Nützlich zur Verfolgung kommender Versionen.
• In Progress — Das Deployment läuft. Wird automatisch von CI/CD-Integrationen während des Deploy-Schritts gesetzt.
• Deployed — Das Release ist live in seiner Zielumgebung. Der Happy Path.
• Failed — Das Deployment war nicht erfolgreich. Der Release-Eintrag bleibt als Aufzeichnung dessen, was versucht wurde.
• Rolled Back — Das Release wurde deployed, aber anschließend zurückgerollt. Dies bewahrt die Historie — Sie können sehen, dass v2.3.1 zurückgerollt wurde, wann und warum.

Status-Übergänge sind automatisch bei CI/CD-Integrationen oder manuell beim Erstellen von Releases über die Benutzeroberfläche.

Verknüpfung mit Architektur-Elementen

Jedes Release kann mit einem System, einem Container oder beidem verknüpft werden. Das gibt Releases ihren architektonischen Kontext.

In den Projekteinstellungen konfigurieren Sie ein Standard-Verknüpfungsziel — das System und optional einen Container, an den Releases angehängt werden. Die Code-Snippets für GitHub Actions, Webhooks und die REST-API aktualisieren sich automatisch, um die richtigen Element-IDs einzuschließen.

Im Diagramm zeigen verknüpfte Elemente ihre Release-Historie im Detail-Panel an. Klicken Sie mit der rechten Maustaste auf einen Container und Sie sehen nicht nur seine Beziehungen und Verträge, sondern auch seine Deployment-Timeline. Hier konvergieren Architekturdokumentation und operative Realität.

Warum das Wichtig Ist

Architekturdiagramme waren schon immer eine Momentaufnahme. Sie zeigen Ihnen, was das System ist — die Boxen, die Pfeile, die Protokolle. Aber sie zeigen nicht, was das System tut. Ist dieser Service auf der neuesten Version? Wann war das letzte Deployment? Hat jemand das Release vom letzten Dienstag zurückgerollt?

Das sind Fragen, die in jeder Architektur-Review, jeder Incident Response, jedem Onboarding aufkommen. Und bisher war die Antwort immer "Schau ins CI/CD-Tool" oder "Frag das Team, das es betreibt."

Release-Management platziert die Deployment-Historie dort, wo sie hingehört: auf der Architektur selbst. Wenn jemand fragt "Welche Version läuft auf dem Payment Gateway?", ist die Antwort direkt im Diagramm — nicht in einem anderen Tool, nicht in einem anderen Tab, nicht in jemandes Kopf.

Das ist dieselbe Philosophie hinter API-Verträgen und ADRs: Architekturdokumentation sollte echte Fragen beantworten, die jeden Tag auftauchen, nicht nur Struktur im Abstrakten beschreiben.

Erste Schritte

Navigieren Sie zu den Einstellungen Ihres Projekts und öffnen Sie den Releases-Tab. Wählen Sie Ihre Integrationsmethode — GitHub Action, Webhooks oder REST-API — und folgen Sie der Einrichtungsanleitung. Erstellen Sie Ihre Umgebungen, verknüpfen Sie ein Zielsystem oder einen Container, und liefern Sie Ihr erstes Release aus.

Ab dann fließt jedes Deployment automatisch in Ihren Architektur-Workspace. Ihre C4-Diagramme hören auf, statische Blaupausen zu sein, und werden zu einem lebendigen Verzeichnis dessen, was tatsächlich läuft.

Ihre Architektur ist mehr als Struktur. Jetzt spiegeln Ihre Werkzeuge das wider.

Möchten Sie mehr darüber erfahren, wie Sie Ihre Architektur mit der Realität verbinden? Erfahren Sie, wie API-Verträge Ihre Specs mit dem Diagramm verknüpfen, oder wie Architektur-Änderungsanträge Pull-Request-Workflows in Ihr C4-Modell bringen.