Orbit
Ein Deployment zurückrollen
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
Wenn eine Bereitstellung die Produktion beschädigt, können Sie in Sekunden einen früheren Build wieder vor den Traffic stellen, ohne irgendwelche Wiederaufbauten durchzuführen. Diese Anleitung behandelt, wie Rollback funktioniert, wie Sie die richtige Bereitstellung auswählen, die automatischen Rollbacks, die Orbit für Sie durchführen kann, und was Sie nach einem Rollback tun sollten.
Wie Rollback funktioniert
Orbit speichert das gepackte Artefakt jedes erfolgreichen Builds. Ein Rollback führt weder Ihren Install noch Ihren Build-Befehl erneut aus: Es bewirbt ein Artefakt, das bereits existiert und bereits bereitgestellt wurde, daher wird es in Sekunden abgeschlossen und kann aus keinem der Gründe fehlschlagen, aus denen ein Build fehlschlagen kann.
Das ist der ganze Grund, es zuerst zu verwenden. Rollback ist schneller und weit vorhersehbarer, als zu versuchen, vorwärts zu korrigieren, während Ihre Website kaputt ist.
Rollback zu einer früheren Bereitstellung
- Öffnen Sie Ihr Projekt in Orbit.
- Öffnen Sie die Registerkarte Deployments.
- Finden Sie die letzte Bereitstellung, von der Sie wissen, dass sie gut war.
- Klicken Sie in dieser Reihe auf Roll back und bestätigen Sie.
Die Bestätigung zeigt genau, was passiert: Traffic wird sofort aus dem älteren Build bereitgestellt, und die aktuelle Bereitstellung wird ersetzt.
Sie können auch von der Detailseite einer Bereitstellung aus rollback durchführen, wo die Schaltfläche Rollback to den kurzen Commit-Hash liest.
Die wiederhergestellte Bereitstellung erhält das Badge CURRENT. Die Bereitstellung, von der Sie zurück gewechselt haben, bleibt in der Verlaufsanzeige mit dem Status Rolled back.
Rollback ist nicht destruktiv und muss nicht rückgängig gemacht werden. Nichts wird gelöscht, keine Historie wird umgeschrieben, und Ihr Repository bleibt unverändert. Ihr nächster erfolgreicher Push zur Produktionsverzweigung wird auf normale Weise zur neuen Live-Version.
Die richtige Bereitstellung identifizieren
Jede Zeile auf der Registerkarte „Deployments" zeigt die Commit-Nachricht und kurzen Hash, die Verzweigung, den Status, wann sie bereitgestellt wurde und wer sie gepusht hat. Die Live-Version trägt das Badge CURRENT.
Normalerweise möchten Sie die Bereitstellung unmittelbar vor der, die das Problem verursacht hat. Zwei Dinge helfen Ihnen, sicher zu sein:
- Vergleichen. Öffnen Sie die verdächtige Bereitstellung und klicken Sie auf Compare, um sie gegen die vorherige zu vergleichen: Build-Zeit, Artefaktgröße, Cache-Status, Framework und der Unterschied auf Dateiebene.
- Deployment-Notizen. Jede Bereitstellung kann eine Notiz von bis zu 500 Zeichen tragen. Das Hinzufügen von „Hotfix für Zahlungsfehler" oder „Feature-Flag X aktiviert" zum Zeitpunkt der Bereitstellung kostet nichts und macht die Geschichte Monate später lesbar, wenn Sie sie brauchen.
Ein Rollback zu einem Artefakt macht nicht ein Rollback Ihrer Umgebungsvariablen, Umleitungsregeln oder Response-Header. Diese werden zum Zeitpunkt der Anfrage oder des Builds gelesen, nicht in das Artefakt gebacken. Wenn der Vorfall durch eine Konfigurationsänderung und nicht durch eine Codeänderung verursacht wurde, wird das Rollback des Codes das Problem nicht beheben. Die Detailseite der Bereitstellung zeigt einen Diff der Variablen, die zum Zeitpunkt des Builds eingefügt wurden, gegen Ihre aktuelle Konfiguration, was die schnellste Methode ist, die beiden auseinanderzuhalten.
Automatisches Rollback
Orbit kann das für Sie tun, bevor Sie es überhaupt bemerkt haben. Alle drei Einstellungen befinden sich in Settings.
Auto-Rollback bei Fehler
Unter Runtime schalten Sie Auto-rollback on failure ein. Wenn eine Produktion-Bereitstellung fehlschlägt, wird die letzte fehlerfreie Bereitstellung automatisch wiederhergestellt und Besucher sehen keine Ausfallzeit. Staging hat einen eigenen entsprechenden Schalter.
Health Check
Unter Health check legen Sie einen Health check path fest, zum Beispiel / oder /api/health. Nach jeder Produktionsbereitstellung ruft Orbit diesen Pfad ab. Wenn er innerhalb von 15 Sekunden keine 2xx-Antwort zurückgibt, wird die vorherige fehlerfreie Bereitstellung wiederhergestellt.
Smoke Tests
Unter Smoke tests listen Sie bis zu 10 durch Kommas getrennte Pfade auf, zum Beispiel /,/blog,/api/health. Nach jeder erfolgreichen Bereitstellung sendet Orbit ein GET an jeden und zeichnet Erfolg oder Fehler auf. Wenn einer fehlschlägt und Auto-Rollback aktiviert ist, wird die vorherige Bereitstellung wiederhergestellt. Das Ergebnis wird auf der Bereitstellungsseite als Smoke tests passed oder Fehleranzahl angezeigt und sagt Triggered rollback, wenn es eins verursacht hat.
Ein Health Check auf einer Route, die tatsächlich Ihre Datenbank nutzt, ist weitaus wertvoller als einer auf der Startseite. Eine fehlerhafte Bereitstellung, die noch eine zwischengespeicherte Startseite bereitstellt, besteht einen /-Check und schlägt bei einem echten fehl.
Rollback versus Deploy-Sperre
Wenn Sie nicht bereit sind, ein Rollback durchzuführen, aber verhindern möchten, dass etwas Neues live geht, während Sie untersuchen, sperren Sie stattdessen Bereitstellungen:
- Öffnen Sie das Projekt.
- Klicken Sie auf Lock deploys.
- Fügen Sie einen Grund hinzu, zum Beispiel „investigating production issue".
Push-ausgelöste Bereitstellungen werden dann stillschweigend übersprungen, und ein Banner zeigt Production deploys are locked mit Ihrem Grund. Manuelle Bereitstellungen funktionieren immer noch, was beabsichtigt ist: Die Sperre stoppt versehentliche Bereitstellungen, nicht die Korrektur, die Sie bereitstellen. Klicken Sie auf Unlock deploys, um sie zu heben.
Eine Sperre und ein Rollback funktionieren gut zusammen. Machen Sie zuerst einen Rollback, um den Service wiederherzustellen, dann sperren Sie, damit niemandes routinemäßiges Merge es rückgängig macht, während Sie diagnostizieren.
Staging zu Produktion bewerbungsgerichtung
Wenn Sie eine Staging-Umgebung ausführen, können Sie einen getesteten Staging-Build in die Produktion bringen, ohne etwas zu pushen.
- Öffnen Sie die Projektübersicht und finden Sie den Abschnitt Staging.
- Wenn Staging vor Produktion liegt, wird Promote to production angezeigt.
- Klicken Sie darauf und bestätigen Sie.
Lesen Sie die Bestätigung sorgfältig durch, da es zwei verschiedene Bewerbungsverhalten in Orbit gibt und sie sind nicht austauschbar. Die Bewerbung aus der Projektübersicht löst einen Fresh-Produktions-Build mit demselben Commit aus, unter Verwendung von Produktionsumgebungsvariablen und Produktions-Build-Befehlen. Das Staging-Artefakt wird nicht wiederverwendet. Die Bewerbung einer bestimmten Staging-Bereitstellung von ihrer Detailseite besagt deutlich, dass der Staging-Build sofort ohne Wiederaufbau live geht. Wenn sich Ihre Staging- und Produktions-Umgebungsvariablen unterscheiden, erzeugt der erste Pfad ein anderes Artefakt als das, das Sie getestet haben.
Orbit kann auch für Sie fördern. Auto-promote staging in Settings bewirbt Staging zu Produktion nach mehreren Stunden mit gesundem Staging und bestandenen Smoke Tests, überprüft alle 15 Minuten.
Nach einem Rollback
Beheben Sie das zugrunde liegende Problem in Ihrem Repository und pushen Sie einen neuen Commit. Das löst einen normalen Build aus, der zur neuen Live-Version wird. Wenn Sie Bereitstellungen gesperrt haben, entsperren Sie sie zuerst, oder der Push wird übersprungen.
Die Registerkarte Activity des Projekts zeichnet das Rollback zusammen mit allem anderen auf, das passiert ist, daher gibt es ein Audit-Trail, wer was wann zurück gerollt hat.
Was begrenzt, wie weit zurück Sie gehen können
Rollback braucht das Artefakt, um noch zu existieren. Zwei Einstellungen kontrollieren das:
- Das Bereitstellungsverlauf-Fenster Ihres Plans: 7 Tage bei Launch, 30 bei Liftoff, 90 bei Apex.
- Die Einstellung Artifact retention des Projekts, die eine Reihe erfolgreicher Artefakte pro Umgebung beibehält, von 10 bis 500, Standard ist 50.
Das Artefakt der aktuell Live-Bereitstellung wird unabhängig von beiden immer beibehalten.
Wenn Sie viele Male pro Tag bereitstellen, ist die Artefaktanzahl die Grenze, auf die Sie zuerst stoßen, nicht die Tagesanzahl. Fünfzig Bereitstellungen können eine einzelne Woche sein. Erhöhen Sie Artifact retention, statt die Grenze während eines Vorfalls zu entdecken.