Seminar Magnolia CMS – DevOps, Deployment und Konfigurationsmanagement

Das Seminar entwickelt eine automatisierbare Lieferkette für Konfiguration, Light Modules, Java-Module, Umgebungsparameter, Tests, Rollback und Betriebsübergabe. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Umgebungs- und Lieferarchitektur
2. Quellstruktur und Build
3. Parameter, Geheimnisse und Konfiguration
4. Deployment, Rollback und Datenänderungen
5. Automatisierte Qualität und Betriebsübergabe
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Umgebungs- und Lieferarchitektur

Inhaltsverzeichnis

• Entwicklung, Test, Abnahme und Produktion
• Author-Public-Topologie und Abhängigkeiten
• Artefakte, Konfiguration und Verantwortungsgrenzen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Entwicklung, Test, Abnahme und Produktion, Author-Public-Topologie und Abhängigkeiten und Artefakte, Konfiguration und Verantwortungsgrenzen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Entwicklung, Test, Abnahme und Produktion werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Author-Public-Topologie und Abhängigkeiten wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Artefakte, Konfiguration und Verantwortungsgrenzen werden schrittweise konfiguriert oder implementiert. Eine Zielpipeline wird aus Umgebungen, Freigaben und technischen Übergabepunkten modelliert. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Lieferarchitektur mit Artefakt- und Verantwortungsmatrix.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Quellstruktur und Build

Inhaltsverzeichnis

• Git-Struktur und Branching
• Light Modules, Webressourcen und Java-Artefakte
• Versionierung, Abhängigkeiten und reproduzierbare Builds
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Git-Struktur und Branching, Light Modules, Webressourcen und Java-Artefakte und Versionierung, Abhängigkeiten und reproduzierbare Builds zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Git-Struktur und Branching werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Light Modules, Webressourcen und Java-Artefakte wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Versionierung, Abhängigkeiten und reproduzierbare Builds werden schrittweise konfiguriert oder implementiert. Ein konsistentes Repository wird erstellt und ein wiederholbarer Build erzeugt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Buildstandard mit Versions- und Abhängigkeitsregeln.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Parameter, Geheimnisse und Konfiguration

Inhaltsverzeichnis

• umgebungsspezifische Werte
• MicroProfile- und Systemkonfiguration
• Geheimnisverwaltung und Trennung von Code und Betrieb
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet umgebungsspezifische Werte, MicroProfile- und Systemkonfiguration und Geheimnisverwaltung und Trennung von Code und Betrieb zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: umgebungsspezifische Werte werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für MicroProfile- und Systemkonfiguration wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Geheimnisverwaltung und Trennung von Code und Betrieb werden schrittweise konfiguriert oder implementiert. Konfigurationen werden zwischen Umgebungen getrennt, geprüft und ohne Klartextgeheimnisse bereitgestellt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Konfigurationskatalog mit Eigentümern und Schutzbedarf.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Deployment, Rollback und Datenänderungen

Inhaltsverzeichnis

• Release-Reihenfolge
• kompatible Inhalts- und Konfigurationsänderungen
• Rollback, Backup und Wiederanlauf
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Release-Reihenfolge, kompatible Inhalts- und Konfigurationsänderungen und Rollback, Backup und Wiederanlauf zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Release-Reihenfolge werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für kompatible Inhalts- und Konfigurationsänderungen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Rollback, Backup und Wiederanlauf werden schrittweise konfiguriert oder implementiert. Ein Release wird mit Vorprüfungen, Deployment, Smoke-Test und kontrolliertem Rollback durchgeführt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Release-Runbook mit Go-/No-Go-Kriterien.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Automatisierte Qualität und Betriebsübergabe

Inhaltsverzeichnis

• Linting, Definitionstests und API-Checks
• Sicherheits- und Abhängigkeitsprüfungen
• Release Notes, Monitoring und Supportübergabe
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Linting, Definitionstests und API-Checks, Sicherheits- und Abhängigkeitsprüfungen und Release Notes, Monitoring und Supportübergabe zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Linting, Definitionstests und API-Checks werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Sicherheits- und Abhängigkeitsprüfungen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Release Notes, Monitoring und Supportübergabe werden schrittweise konfiguriert oder implementiert. Eine Pipeline wird um technische Gates und eine standardisierte Betriebsübergabe ergänzt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Abnahmekatalog für CI/CD und Produktionsfreigabe.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: DevOps, Plattformengineering, Magnolia-Entwicklung, Systemadministration, Release Management und technische Projektleitung.

Voraussetzungen: Magnolia- und Git-Grundkenntnisse sowie Erfahrung mit Build-, Deployment- oder Containerprozessen; Shell- und CI/CD-Kenntnisse sind hilfreich.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.