Seite 15 - Mir Admin

Ein Build-Job auf Production ist kein Deployment – er ist ein unkontrolliertes Experiment auf dem Live-System. Artefakte aus isolierten CI-Jobs bringen Reproduzierbarkeit, Geschwindigkeit und Sicherheit gleichzeitig.

Wer in einem größeren Team mit GitLab CI/CD arbeitet, kennt das Phänomen: Jobs landen in der Queue, obwohl die Pipeline schon längst abgeschickt wurde. Die Ursache liegt fast immer in zu niedrig konfigurierten concurrent-Limits, fehlenden Runner-Tags oder unausgewogener Lastverteilung zwischen Build-, Test- und Deploy-Jobs.

Repository-Governance, Build-Artefakte, Release-Verzeichnisse, Symlink-Switch, Verify-Jobs und Rollback als geschlossener, nachvollziehbarer Prozess – alle Bausteine im Zusammenhang erklärt.

Ein Deployment, das ohne Fehler abgeschlossen wird, muss nicht korrekt funktionieren. Der Symlink wurde gesetzt, der Cache geleert — aber lädt die Startseite? Antwortet der Checkout? Ist der Cache-Status grün? Smoke Tests schließen diese Lücke und geben dem Deployment-Prozess einen fachlichen Abschluss statt nur einen technischen.

Ein Backup, das nie getestet wurde, ist eine Hypothese. Bash-Backup-Skripte, die rsync für inkrementelle Sicherungen und tar für archivierte Snapshots kombinieren, rotierende Sicherungen nach konfigurierbarer Retention aufräumen und Restore-Tests automatisch ausführen, machen den Unterschied zwischen einer Datensicherungs-Routine und einem verifizierten Wiederherstellungsprozess.