Seminar Structurizr Server: APIs, Workspace-Lebenszyklus, Branches und Versionierung

Workspaces werden als verwaltete Serverobjekte mit eindeutiger Identität, Zugriffsrechten und nachvollziehbarer Änderungshistorie behandelt. Commands, API-Aufrufe und Weboberfläche werden zu einem einheitlichen Betriebs- und Veröffentlichungsprozess verbunden.

Inhaltsverzeichnis

1. Einordnung
2. Zielgruppe
3. Voraussetzungen
4. Lernziele
5. Seminarinhalte
6. Praxisfall und Übungsartefakte

Einordnung

Der Server arbeitet nicht direkt auf lokal bearbeiteten Dateien. Inhalte werden über die Workspace-API übertragen. Dadurch entstehen klare Grenzen zwischen Autorenrepository, publizierter Version, Branches und freigegebenen Einbettungen. Diese Grenzen bilden die Grundlage für kontrollierte Zusammenarbeit.

Zielgruppe

Softwarearchitektinnen und Softwarearchitekten, Plattform- und DevOps-Teams, technische Integrationsverantwortliche sowie Personen, die Structurizr Server in Portale oder CI/CD-Prozesse einbinden.

Voraussetzungen

Grundkenntnisse der Structurizr DSL, Kommandozeile und HTTP-APIs. Eine laufende Serverinstanz oder das Seminar zum Grundbetrieb wird empfohlen.

Lernziele

• Workspaces über Oberfläche, Commands oder API kontrolliert erstellen und verwalten.
• API-Schlüssel sicher behandeln und Übertragungen nachvollziehbar protokollieren.
• Sperren, Versionen, Branches und Rollback für parallele Änderungen einsetzen.
• Sharing- und Einbettungsvarianten passend zum Schutzbedarf auswählen.
• Workspace-Lebenszyklus in CI/CD, Architekturreview und Betrieb integrieren.

Seminarinhalte

1. Workspace-Identität und Erstellung

Ein Workspace wird mit eindeutiger ID, Eigentum und Sichtbarkeit angelegt.

1. Erstellungsweg über Oberfläche, Command oder Admin-Prozess auswählen.
2. ID, Titel, Beschreibung und Zuständigkeit dokumentieren.
3. API-Schlüssel erzeugen, geschützt ablegen und Zugriff testen.

2. Push, Pull und Inhaltsformate

Lokale DSL- oder JSON-Artefakte werden kontrolliert mit der Serverfassung synchronisiert.

1. DSL und JSON hinsichtlich Portabilität und Layoutinformationen vergleichen.
2. Push mit passender Merge-Strategie ausführen.
3. Pull für Vergleich, Sicherung und nachgelagerte Prüfungen einsetzen.

3. Sperren und konkurrierende Änderungen

Arbeitsbereiche werden vor kritischen Änderungen geschützt.

1. Sperrregeln und Verantwortlichkeiten festlegen.
2. Lock und Unlock im normalen sowie im Fehlerfall testen.
3. Verwaiste Sperren erkennen und kontrolliert auflösen.

4. Versionen, Branches und Rollback

Änderungshistorie und parallele Architekturarbeit werden praktisch erprobt.

1. Versionserzeugung und Aufbewahrung nachvollziehen.
2. Branch-Namensschema und Freigabeprozess definieren.
3. Vorherige Version anzeigen, vergleichen und bei Bedarf wiederherstellen.

5. Sharing und Einbettung

Diagramme werden kontrolliert für interne Zielsysteme bereitgestellt.

1. Öffentliche Lesesicht, tokenisierte Freigabe und geschützte Nutzung unterscheiden.
2. Live-Diagramm per iframe oder Bilddarstellung einbetten.
3. Perspektiven, Tags und Diagramm-Keys in der Einbettung testen.

6. Integration und Betriebsprozess

Alle Funktionen werden in einen nachvollziehbaren Lebenszyklus überführt.

1. Status von Entwurf, Review, Freigabe und Veröffentlichung definieren.
2. CI/CD- und Portalintegration mit Protokollierung und Secret-Regeln verbinden.
3. Regelmäßige Schlüsselrotation, Versionenkontrolle und Integrationsprüfung planen.

Praxisfall und Übungsartefakte

Mehrere Workspace-Versionen und ein Branch werden erstellt, gesperrt, aktualisiert und zurückgerollt. Anschließend wird ein freigegebenes Diagramm in eine interne Beispielseite eingebettet und durch Zugriffstests geprüft.