Seminar Enonic XP 8 – Testing, Qualitätssicherung und CI/CD

Das Seminar verankert Qualitätssicherung im gesamten Lebenszyklus einer Enonic-XP-8-Anwendung. Testbarkeit, reproduzierbare Umgebungen, automatisierte Verträge und kontrollierte Releases werden nicht nachträglich ergänzt, sondern aus Architektur und Risiken abgeleitet.

Ein vorhandenes Beispielprojekt wird schrittweise mit Testpyramide, isolierten Testdaten, Build-Prüfungen und einer mehrstufigen Pipeline ausgestattet. Fehlerhafte Builds, inkompatible Schemas und misslungene Deployments dienen als kontrollierte Übungsszenarien.

Inhaltsübersicht

1. Risikoanalyse und Testarchitektur
2. Testbare TypeScript-Architektur
3. Unit-Tests und Fehlerklassen
4. Plattform- und Repository-Integrationstests
5. API- und Vertragstests
6. Schema- und Content-Tests
7. Testdaten, Sandbox und Umgebungen
8. Gradle-Build und Artefakte
9. CI/CD-Pipeline und Qualitätsgates
10. Deployment, Smoke Tests und Rollback

Lernziele

• risikobasierte Teststrategie und Testpyramide entwickeln
• Unit-, Integrations-, API- und Schema-Tests automatisieren
• Testdaten und Sandboxes reproduzierbar verwalten
• Gradle-Build und CI/CD mit Qualitätsgates aufbauen
• Deployment, Smoke Test, Rückfall und Nachweis absichern

Praxisorientierte Lernschritte

1. Risikoanalyse und Testarchitektur

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: kritische Fach-, Daten-, Sicherheits- und Betriebsrisiken priorisieren
2. Schritt 2: passende Teststufe und Verantwortlichkeit pro Risiko festlegen
3. Schritt 3: Testpyramide, Abnahmekriterien und Nachweisformat dokumentieren

2. Testbare TypeScript-Architektur

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Fachlogik von Plattformadaptern und I/O trennen
2. Schritt 2: Abhängigkeiten über kleine Schnittstellen ersetzbar machen
3. Schritt 3: deterministische Zeit-, ID- und Konfigurationsquellen für Tests bereitstellen

3. Unit-Tests und Fehlerklassen

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Normalfall, Randwerte und fachliche Fehler für Services abdecken
2. Schritt 2: Mocks nur an klaren Systemgrenzen einsetzen
3. Schritt 3: Testnamen und Assertions als verständliche Spezifikation gestalten

4. Plattform- und Repository-Integrationstests

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: isolierten Repository- und Branch-Kontext für Testläufe erzeugen
2. Schritt 2: Schreib-, Query-, Berechtigungs- und Parallelitätsfälle prüfen
3. Schritt 3: Testdaten nach jedem Lauf vollständig und nachvollziehbar bereinigen

5. API- und Vertragstests

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Requests, Responses, Statuscodes und Fehlerformate als Vertrag festlegen
2. Schritt 2: Authentifizierung, Autorisierung und Eingabegrenzen mit Negativtests prüfen
3. Schritt 3: kompatible und breaking Änderungen automatisiert erkennen

6. Schema- und Content-Tests

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: YAML-Schemas syntaktisch und fachlich validieren
2. Schritt 2: repräsentative Inhalte gegen Pflichtfelder, Beziehungen und Lokalisierung prüfen
3. Schritt 3: Migrationsbedarf bei Schemaänderungen als Pipelinefehler sichtbar machen

7. Testdaten, Sandbox und Umgebungen

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: kleine, versionierte Referenzdatenbestände erstellen
2. Schritt 2: Sandbox beziehungsweise ephemere Umgebung reproduzierbar provisionieren
3. Schritt 3: Konfiguration und Secrets zwischen lokalen und zentralen Tests sicher trennen

8. Gradle-Build und Artefakte

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Buildschritte für Kompilierung, Tests, Analyse und Paketierung ordnen
2. Schritt 2: Version, Abhängigkeiten und Prüfsummen des Artefakts nachvollziehbar erzeugen
3. Schritt 3: nicht reproduzierbare oder ungeprüfte Artefakte konsequent blockieren

9. CI/CD-Pipeline und Qualitätsgates

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Pipeline-Stufen, Caches und parallele Prüfungen effizient strukturieren
2. Schritt 2: Security-, Lizenz-, Schema- und Performance-Gates risikobasiert setzen
3. Schritt 3: Freigaben und Umgebungsübergänge mit eindeutigen Nachweisen verknüpfen

10. Deployment, Smoke Tests und Rollback

Der Arbeitsblock verbindet fachliche Einordnung, nachvollziehbare Umsetzung und kontrollierte Prüfung. Konfigurationen, Entscheidungen und Prüfergebnisse werden als wiederverwendbare Projektnachweise dokumentiert.

1. Schritt 1: Installation oder Update in einer Zielumgebung automatisieren
2. Schritt 2: Smoke-, Health- und fachliche Kernprüfungen unmittelbar ausführen
3. Schritt 3: fehlgeschlagenes Release zurückrollen und Ursache für den nächsten Lauf dokumentieren

Zielgruppe und Vorkenntnisse

Zielgruppe: Enonic-Entwickler, QA Engineers, Testautomatisierer, DevOps, technische Leads und Teams mit Verantwortung für stabile Releases.

Vorkenntnisse: Sichere Kenntnisse in TypeScript, Git, automatisierten Tests und grundlegenden CI/CD-Konzepten sowie Erfahrung mit Enonic-XP-Anwendungsentwicklung.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurations- oder Implementierungsschritte und kontrollierte Fehlerfälle vertieft. Jede Übung besitzt definierte Ausgangswerte, Prüfpunkte und Dokumentationsanforderungen. Dadurch bleiben die erarbeiteten Abläufe für Projekt- und Betriebsstandards nachvollziehbar.