Deployments und Rollback
Deployments und Rollback
Der Tab Deployments eines Dienstes ist dessen vollständige Historie: jeder Build wird dort mit seinem Commit, seinem Status, seiner Dauer und seinen Logs aufgeführt.
Lebenszyklus eines Deployments
| Status | Bedeutung |
|---|---|
| Läuft | Der Build läuft, Logs live |
| Erfolg | Image erstellt und deployt |
| Fehler | Der Build oder ein Check ist fehlgeschlagen. Nichts wurde deployt |
| Abgebrochen | Build manuell unterbrochen |
Ein erfolgreiches Deployment ersetzt das alte ohne Unterbrechung: die neue Version startet, und der Traffic wechselt erst, wenn sie bereit ist.
Zurückgehen (Rollback)
Jedes erfolgreiche Deployment behält sein Image in der internen Registry. Um zu einer vorherigen Version zurückzukehren:
- Öffnen Sie den Tab Deployments des Dienstes.
- Finden Sie das Ziel-Deployment in der Historie.
- Klicken Sie auf Rollback. Das damalige Image wird unverändert neu deployt, ohne Rebuild.
Der Rollback ist nahezu sofort, da kein Build erforderlich ist. Die aktuellen Umgebungsvariablen gelten (sie werden nicht auf ihren damaligen Zustand zurückgesetzt).
Einen laufenden Build abbrechen
Ein versehentlich gestarteter (oder blockierter) Build wird über die Zeile des Deployments abgebrochen, Button Abbrechen. Der Dienst läuft weiter auf seiner vorherigen Version.
Build-Logs
Die Logs jedes Builds werden dauerhaft gespeichert: Sie können ein mehrere Wochen altes Deployment erneut öffnen und dessen gesamte Ausgabe nachlesen. Unverzichtbar, um einen funktionierenden Build mit einem fehlschlagenden zu vergleichen.
Automatisches Deployment: Wenn der Dienst einem GitHub-Branch folgt, löst jeder Push einen Build aus (Continuous Deployment). Die kx712.yml-Checks ermöglichen es, das Deployment zu blockieren, wenn Ihre Tests fehlschlagen.