Seminar Dogu-Entwicklung: Intensivseminar Entwicklung, Integration und Release

Der Intensivpfad bildet den vollständigen Entwicklungslebenszyklus eines Dogu ab. Architekturentscheidungen werden in Code, Metadaten, Tests und Releasekriterien übersetzt.

Die Inhalte fassen die Einzelthemen Entwicklungsgrundlagen, dogu.json, Integration sowie Build, Test und Release in einer durchgängigen Entwicklungswoche zusammen.

Inhaltsübersicht

1. Zielgruppe
2. Lernziele
3. Seminarinhalte
4. Praxisübungen
5. Arbeitsweise

Zielgruppe

Softwareentwicklung, DevOps Engineering, Plattformentwicklung, Build- und Release Engineering

Lernziele

• Teilnehmende können ein eigenes Dogu von Grund auf entwickeln und integrieren.
• Teilnehmende können Konfiguration, Abhängigkeiten und Lifecycle robust modellieren.
• Teilnehmende können CAS, LDAP, Warp-Menü und Dienstkommunikation korrekt anbinden.
• Teilnehmende können Build, Tests, CI und Release vollständig automatisieren.

Seminarinhalte

1. Entwicklungsumgebung und Arbeitsstruktur

Eine reproduzierbare Dogu-Entwicklung benötigt definierte Werkzeuge, Verzeichnisse und eine geeignete Testinstanz.

1. Quellstruktur, Build-Werkzeuge, Containerlaufzeit und Zugänge zur Entwicklungsinstanz prüfen.
2. Dogu-Verzeichnis mit Versionsverwaltung und klarer Trennung von Quellcode und Artefakten anlegen.
3. Lokalen Namespace beziehungsweise Entwicklungsbereich festlegen.
4. Build-, Installations- und Diagnosebefehle in einer Projektanleitung dokumentieren.

2. Dockerfile, startup.sh, dogu.json und Ressourcen

Die Kernartefakte eines Dogu werden mit eindeutigen Verantwortlichkeiten aufgebaut. Einmalige Build-Schritte und wiederkehrende Startlogik bleiben getrennt.

1. Dockerfile für Basisimage, Pakete, Anwendung und unveränderliche Ressourcen erstellen.
2. startup.sh für Konfiguration, Migration, Rechteprüfung und Anwendungsstart strukturieren.
3. dogu.json als zentrale Metadaten- und Integrationsbeschreibung anlegen.
4. Zusätzliche Ressourcen versionieren und mit minimalen Rechten in das Image übernehmen.

3. Basisimage, Image-Aufbau und Laufzeitprinzipien

Das Image bleibt klein, nachvollziehbar und updatefähig. Build-Zeit und Laufzeit werden technisch sauber getrennt.

1. Passendes Cloudogu-Basisimage nach Laufzeit und Anwendungstyp auswählen.
2. Pakete versioniert installieren und temporäre Build-Daten entfernen.
3. Nicht privilegierte Ausführung, Dateirechte und schreibbare Pfade festlegen.
4. Image lokal bauen und auf Größe, Schichten, Startbarkeit und offensichtliche Geheimnisse prüfen.

4. dogu.json: Metadaten, Versionen und Schnittstellen

Die dogu.json beschreibt Identität, Version, Abhängigkeiten und technische Eigenschaften. Änderungen werden schemaorientiert vorgenommen.

1. Name, Namespace, Version, Anzeigeinformationen und Tags konsistent festlegen.
2. Abhängigkeiten mit zulässigen Versionen und optionalem Charakter beschreiben.
3. Ports, Volumes, Healthcheck, Konfiguration und Dienste vollständig modellieren.
4. Datei syntaktisch und semantisch validieren und gegen den vorgesehenen Lifecycle testen.

5. Konfigurationsschlüssel, Defaults und Geheimnisse

Konfiguration wird nach Gültigkeitsbereich, Sensibilität und Änderungswirkung strukturiert. Sichere Defaults reduzieren Fehlkonfigurationen.

1. Globale, Dogu-spezifische und umgebungsabhängige Einstellungen voneinander trennen.
2. Schlüssel mit Datentyp, Default, Pflichtstatus und Validierungsregel definieren.
3. Geheimnisse kennzeichnen und Ausgabe in Logs oder Diagnosepaketen verhindern.
4. Änderung, Rekonfiguration, Neustart und Rücksetzung für jeden Schlüssel testen.

6. Abhängigkeiten, Dienste und Versionsverträglichkeit

Abhängigkeiten werden so eng wie nötig und so flexibel wie möglich beschrieben. Zyklische und nur implizite Kopplungen werden vermieden.

1. Benötigte Plattformdienste, Datenbanken und andere Dogus identifizieren.
2. Kompatible Versionsbereiche und Startreihenfolge festlegen.
3. Verhalten bei fehlender, veralteter oder vorübergehend nicht erreichbarer Abhängigkeit definieren.
4. Installations-, Upgrade- und Ausfallszenarien mit den Abhängigkeiten testen.

7. Startlogik, Migrationen und Gesundheitsprüfung

Der Startprozess bleibt idempotent und diagnostizierbar. Datenmigrationen, Konfigurationsübernahme und Anwendungsstart werden kontrolliert verkettet.

1. Vorbedingungen und verfügbare Abhängigkeiten zu Beginn prüfen.
2. Konfiguration aus der Registry lesen, validieren und in Anwendungsform überführen.
3. Datenmigrationen versioniert, wiederholbar und mit Abbruchschutz ausführen.
4. Anwendung starten und Healthcheck erst nach tatsächlicher Betriebsbereitschaft erfolgreich melden.

8. Webanwendung, Reverse Proxy und Warp-Menü

Web-Dogus werden über den zentralen Zugangsweg erreichbar. Pfade, Header, Weiterleitungen und Navigation müssen zusammenpassen.

1. Webdienst intern eindeutig bereitstellen und passende Service-Tags setzen.
2. Kontextpfad, Proxy-Header und öffentliche Basisadresse der Anwendung konfigurieren.
3. Eintrag im Warp-Menü mit verständlichem Namen, Kategorie und Berechtigung prüfen.
4. Direktzugriff, Navigation, Weiterleitungen und große Requests mit repräsentativen Tests validieren.

9. CAS-Anbindung und Benutzerkontext

Die Anwendung übernimmt die zentrale Identität, ohne lokale Schattenkonten unkontrolliert zu vermehren. Anmeldefluss und Rollenübergabe werden getestet.

1. CAS-Client der Anwendung mit korrekter öffentlicher Serviceadresse konfigurieren.
2. Benutzerattribute und gegebenenfalls Gruppeninformationen eindeutig abbilden.
3. Erstanlage, erneute Anmeldung, Abmeldung und gesperrte Konten testen.
4. Fehlerfälle bei ungültigem Ticket, Zeitabweichung und falscher Rücksprungadresse diagnostizieren.

10. LDAP, Service Discovery und Dogu-zu-Dogu-Kommunikation

Technische Integrationen nutzen definierte Dienste und Konfigurationen statt fest codierter Adressen. Berechtigungen und Ausfallverhalten bleiben nachvollziehbar.

1. Benötigte Benutzer-, Gruppen- und Dienstinformationen festlegen.
2. Dienstendpunkte aus der Plattformkonfiguration beziehen und TLS-Vertrauen herstellen.
3. Technische Identität mit minimalen Rechten und geregelter Rotation einrichten.
4. Timeout, Wiederholung, Nichtverfügbarkeit und Versionsabweichung in Integrationstests abdecken.

11. Dogu bauen, paketieren und in einen Namespace übertragen

Der Build erzeugt ein reproduzierbares Image und passende Metadaten. Lokale Artefakte werden klar von freigegebenen Ständen getrennt.

1. Versionsstand und sauberen Arbeitsbaum vor dem Build prüfen.
2. Dogu mit dem vorgesehenen Build-Werkzeug erstellen und Fehler früh abbrechen lassen.
3. Image, Metadaten und Prüfsummen im Entwicklungsnamespace bereitstellen.
4. Artefaktbestand und Version anschließend unabhängig verifizieren.

12. Goss-, Integrations- und Lifecycle-Tests

Tests prüfen nicht nur, ob ein Prozess läuft. Konfiguration, Ports, Dateien, Anmeldung, Persistenz und Upgradepfade werden abgedeckt.

1. Statische und containerinterne Prüfungen für Dateien, Prozesse, Ports und Benutzer definieren.
2. Installation in einer frischen Testinstanz automatisiert durchführen.
3. Anmeldung, Navigation, Konfiguration, Datenpersistenz und Abhängigkeiten testen.
4. Upgrade, Neustart, Rekonfiguration und Wiederherstellung als Lifecycle-Szenarien ergänzen.

13. CI-Pipeline, Versionierung und Releasefreigabe

Ein Release entsteht aus einem geprüften Commit mit eindeutiger Version. Build, Tests, Sicherheitsprüfung und Veröffentlichung sind nachvollziehbar verkettet.

1. Branch- und Versionsmodell einschließlich Vorabständen und Korrekturreleases festlegen.
2. Pipeline für Build, Tests, Analyse, Prüfsummen und Artefaktablage aufbauen.
3. Freigabekriterien, Vier-Augen-Prinzip und Änderungsdokumentation integrieren.
4. Freigegebenes Dogu in den vorgesehenen Namespace übertragen und Installationsprüfung ausführen.

14. Fehleranalyse bei Build, Start und Integration

Entwicklungsfehler werden anhand der Phase eingegrenzt. Buildfehler, Startfehler, Konfigurationsfehler und Integrationsfehler benötigen unterschiedliche Beweise.

1. Fehler reproduzieren und Phase, Version, Umgebung sowie Eingabedaten festhalten.
2. Buildausgabe, Containerlogs, Registry-Werte und Healthcheck getrennt untersuchen.
3. Minimalen Korrekturversuch erstellen und Nebenwirkungen mit automatisierten Tests prüfen.
4. Ursache, Korrektur und Präventionsmaßnahme im Projekt festhalten.

Praxisübungen

• Entwicklung eines vollständigen Beispiel-Dogu
• Anbindung an zentrale Anmeldung und Navigation
• Integration eines Plattformdienstes mit technischer Identität
• Aufbau von Goss-, Integrations- und Upgrade-Tests
• Erstellung einer CI-Pipeline und Freigabe eines Releasekandidaten

Arbeitsweise

Die gesamte Woche arbeitet an einem gemeinsamen Dogu. Tägliche Qualitätsprüfungen verhindern, dass Fehler bis zum Release weitergetragen werden.