Ausführen von Aufgaben mit Release Phase
Lernziele
Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
- Beschreiben, wie Release Phase-Aufgaben eingerichtet werden
- Beschreiben, wie man Aktivitäten und Protokolle im Zusammenhang mit Releases prüft
Verwenden der Release Phase
Die optionale Release Phase ermöglicht es, Aufgaben auszuführen, bevor Sie eine neue Release bereitstellen.
Anwendungsfälle
Gängige Aufgaben, die in dieser Phase ausgeführt werden, sind:
- Übertragen von CSS-, JS- und anderen Datenbeständen an ein CDN (Content Delivery Network) oder einen AWS S3-Bucket
- Vorbereiten oder Ungültigmachen von Cache-Speichern
- Ausführen von Migrationen des Datenbankschemas
Festlegen von Release Phase-Aufgaben
Ihre Anwendung kann den Release-Prozess nutzen, um Release Phase-Aufgaben in einem einmaligen Dyno auszuführen. Zum Festlegen von Aufgaben fügen Sie diese zur Procfile der Anwendung hinzu. Fügen Sie einen release-Prozesstyp und den auszuführenden Befehl zu der Datei hinzu.
Für eine Django-Anwendung würden Sie eine Datenbankmigration beispielsweise wie folgt in Ihrer Datei angeben:
release: python manage.py migrate
Wenn Sie Docker-Images in Heroku bereitstellen, finden Sie weitere Informationen dazu unter Verwenden der Release Phase mit der Container-Registry.
Wann tritt die Release Phase ein?
Die Release Phase-Aufgaben werden bei jedem neuen Release ausgeführt, es sei denn, das Release wird durch Änderungen an den Konfigurationsvariablen eines Add-Ons verursacht. Bei allen folgenden Ereignissen wird ein Release erstellt:
- Erfolgreiche Anwendungserstellung
- Eine Änderung am Wert einer Konfigurationsvariablen
- Eine Hochstufung in der Pipeline
- Ein Rollback
- Ein Release über die Plattform-API
- Bereitstellen eines neuen Add-Ons
Anwendungs-Dynos werden für ein neues Release erst gestartet, wenn die Release Phase erfolgreich abgeschlossen wurde. Schlägt eine Release Phase-Aufgabe fehl, wird das neue Release nicht bereitgestellt.
Rollback eines Release
Wenn Sie fehlerhaften Code für die Produktionsumgebung bereitgestellt haben, machen Sie die betreffenden Codeänderungen lokal mit git revert rückgängig und stellen den Code erneut bereit.
Falls Sie wegen einer falschen Konfiguration oder anderen, spezifischen Problemen im Zusammenhang mit der Heroku-Plattform ein Release-Rollback durchführen müssen, verwenden Sie dazu den Befehl heroku rollback. Der folgende Befehl führt ein Rollback Ihrer Anwendung auf ein vorhergehendes Release v40 durch:
heroku rollback v40 Rolled back to v40
Wenn Sie keine Release-Nummer angeben, wird Ihre Anwendung um ein einzelnes Release zurückgesetzt.
Der Befehl heroku rollback erstellt ein neues Release. Dieses Release kopiert das kompilierte Slug und die Konfigurationsvariablen des Release, das Sie mit Rollback zurücksetzen.
Warnung:
Die Ausführung eines Rollback-Release ist eine temporäre Lösung für eine fehlerhafte Bereitstellung. Beheben Sie den Fehler, schreiben Sie ihn mit Commit fest und übertragen Sie die Änderung so schnell wie möglich per Push an Heroku.
Prüfen des Release-Status
Um den Status eines Release zu überprüfen, einschließlich fehlgeschlagener Releases und Releases, die aufgrund einer lang dauernden Release Phase noch ausstehen, führen Sie den Befehl heroku releases aus.
heroku releases === example-app Releases - Current: v52 v53 Deploy ad7c527 release command failed example@heroku.com v52 Deploy b41eb7c example@heroku.com v51 Deploy 38352d3 example@heroku.com
Wenn Sie den Befehl heroku releases:output verwenden, wird zudem die Ausgabe einer bestimmten Release Phase-Ausführung angezeigt:
heroku releases:output v40 --- Migrating db --- INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL.
Prüfen der Release-Protokolle
Über die Registerkarte Aktivität Ihrer Anwendung greifen Sie auf die Protokolle zu einem Release zu. Klicken Sie neben dem gewünschten Release auf View release log.
Ressourcen
