Lernbegriff
Semantic versioning — Builds, Tests und Releases
Semantic Versioning kennzeichnet inkompatible, kompatible und korrigierende Änderungen als Major, Minor und Patch. Die Lernkarte zeigt die Rolle im Modul „Builds, Tests und Releases“ und einen sicheren Diagnoseweg.
Orientierung
Semantic Versioning kennzeichnet inkompatible, kompatible und korrigierende Änderungen als Major, Minor und Patch. Auf dieser Stufe trennst du Zweck, Eingabe und sichtbares Ergebnis. Ordne Semantic versioning als Teil des Moduls Builds, Tests und Releases ein, bevor du Einstellungen oder Dateien veränderst.
Praktische Anwendung
Ein neues Artefakt verhält sich anders als der vorige Build. Prüfe für Semantic versioning Quellrevision, Lockfile, Build-Log, Testresultate und Prüfsumme; baue in einer sauberen Umgebung erneut und vergleiche das Ergebnis, bevor du veröffentlichst. Arbeite zunächst in einer Testumgebung mit neutralen Beispielen. Notiere den Sollzustand, führe genau eine kontrollierte Änderung aus und vergleiche danach Status, Ausgabe und Logmeldungen.
Technisches Verständnis
Semantic Versioning kennzeichnet inkompatible, kompatible und korrigierende Änderungen als Major, Minor und Patch. Technisch ist Semantic versioning über Schnittstellen, Konfiguration, Zustand oder Abhängigkeiten eingebunden. Verfolge den Datenfluss von der Eingabe bis zur Ausgabe und prüfe Versionen, Rechte, Netzwerk, Speicher und Ressourcen getrennt.
Betrieb und Debugging
Ein neues Artefakt verhält sich anders als der vorige Build. Prüfe für Semantic versioning Quellrevision, Lockfile, Build-Log, Testresultate und Prüfsumme; baue in einer sauberen Umgebung erneut und vergleiche das Ergebnis, bevor du veröffentlichst. Im produktionsnahen Betrieb helfen messbare Signale, Least Privilege, reproduzierbare Konfiguration und ein dokumentierter Rollback. Sichere zuerst Belege, grenze die Ursache ein und verifiziere die Korrektur mit demselben Test.
Übung
Sicher ausprobieren
Ein neues Artefakt verhält sich anders als der vorige Build. Prüfe für Semantic versioning Quellrevision, Lockfile, Build-Log, Testresultate und Prüfsumme; baue in einer sauberen Umgebung erneut und vergleiche das Ergebnis, bevor du veröffentlichst. Öffne eine isolierte Testumgebung und führe „git status --short && git log -1 --oneline“ aus. Beschreibe die erwartete Ausgabe vorab, ändere keine produktiven Daten und notiere einen sicheren nächsten Diagnoseschritt.
git status --short && git log -1 --onelineQuick-Check
Kannst du Zweck, beobachtbaren Zustand und häufigste Fehlerquelle von Semantic versioning — Builds, Tests und Releases jeweils in einem Satz erklären? Welche Ausgabe würdest du zuerst sichern, bevor du etwas änderst, und welcher Test beweist anschließend, dass deine Korrektur wirklich wirksam war?