Seminar Dogu-Entwicklung: Build, Test und Release

Ein lokal startender Container ist noch kein freigabefähiges Dogu. Erst automatisierte Tests der Plattformintegration und des Lifecycles schaffen einen belastbaren Releasekandidaten.

Der dreitägige Umfang ermöglicht den Aufbau einer vollständigen Pipeline mit Fehlerfällen, nicht nur die Demonstration einzelner Build-Befehle.

Inhaltsübersicht

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

Zielgruppe

Dogu-Entwicklung, DevOps Engineering, Build- und Release Engineering, technische Qualitätssicherung

Lernziele

• Teilnehmende können Dogus reproduzierbar bauen und in Entwicklungsnamespaces bereitstellen.
• Teilnehmende können Goss-, Integrations- und Lifecycle-Tests entwerfen.
• Teilnehmende können eine CI-Pipeline mit Freigabekriterien aufbauen.
• Teilnehmende können Versionen und Releases nachvollziehbar veröffentlichen.

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. 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.

3. 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.

4. 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.

5. 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.

6. Upgrades, Wartungsmodus und Rückfallplanung

Upgrades werden als geplante Änderungen behandelt. Vorprüfung, Sicherung, Durchführung und Nachtest bilden eine untrennbare Einheit.

1. Verfügbare Updates, Abhängigkeiten, Änderungsumfang und bekannte Risiken bewerten.
2. Sicherung, Wartungsfenster, Kommunikationsweg und Abbruchkriterien vorbereiten.
3. Upgrade ausführen und Fortschritt sowie Meldungen lückenlos beobachten.
4. Funktionstest durchführen und bei Grenzwertverletzung den vorbereiteten Rückfallweg einsetzen.

7. 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

• Build eines Beispiel-Dogu mit überprüfbaren Artefakten
• Erstellung von Goss-Prüfungen und einem Integrationstest
• Aufbau einer Pipelinefolge von Build bis Freigabe
• Simulation eines fehlerhaften Releases mit Rücknahmeentscheidung

Arbeitsweise

Der Kurs arbeitet durchgehend an einem Beispiel-Dogu und führt jeden Stand durch Build, Test und Releaseprüfung.