Exécutez des tâches avec Release Phase
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Décrire comment configurer les tâches Release Phase
- Décrire comment vérifier l’activité et les journaux liés aux versions
Utilisation de Release Phase
L’étape Release Phase facultative permet d’exécuter des tâches avant de déployer une nouvelle version.
Cas d’utilisation
Les tâches courantes exécutées au cours de cette phase incluent :
- Envoyer le fichier CSS, le fichier JS et d’autres actifs à un réseau de diffusion de contenu (CDN) ou à un compartiment AWS S3.
- Amorcer ou invalider les magasins de cache.
- Exécuter des migrations de schéma de base de données.
Spécification des tâches Release Phase
Votre application peut utiliser le processus de publication pour exécuter des tâches Release Phase dans un dyno unique. Pour spécifier des tâches, ajoutez-les au procfile de l’application. Ajoutez un type de processus release au fichier, ainsi que la commande à exécuter.
Par exemple, pour une application Django, voici comment spécifier une migration de base de données dans votre fichier :
release: python manage.py migrate
Si vous déployez des images Docker sur Heroku, découvrez l’utilisation de Release Phase avec le registre de conteneurs.
Moment de réalisation de l’étape Release Phase
Les tâches Release Phase s’exécutent lors de chaque nouvelle version, sauf si la version est due à des modifications apportées aux variables de configuration d’un complément. Tous les événements suivants créent une version :
- La création d’une application
- La modification de la valeur d’une variable de configuration
- La promotion d’un pipeline
- Une annulation de version
- Une publication via l’API de la plate-forme
- L’activation d’un nouveau complément
Les dynos d’application ne démarrent pas pour une nouvelle version tant que l’étape Release Phase n’est pas correctement terminée. Si une tâche Release Phase échoue, la nouvelle version n’est pas déployée.
Annulation d’une version
Si vous déployez en production du code qui contient des bogues, annulez localement les modifications du code pertinentes avec git revert, puis effectuez un nouveau déploiement.
Si vous devez annuler une version en raison d’une configuration incorrecte ou d’autres problèmes spécifiques de la plate-forme Heroku, utilisez la commande heroku rollback. Cette commande restaure votre application à une version précédente v40 :
heroku rollback v40 Rolled back to v40
Si vous ne spécifiez aucun numéro de version, votre application est restaurée d’une version en arrière.
La commande heroku rollback crée une autre version. Cette version copie le slug et les variables de configuration compilés de la version restaurée.
Avertissement :
L’exécution sur une version restaurée est une solution temporaire en cas d’erreur de déploiement. Validez un correctif pour votre problème et envoyez-le à Heroku dès que possible.
Vérification du statut de la version
Pour vérifier le statut d’une version, y compris les versions ayant échoué et les versions en attente en raison d’une longue étape Release Phase, exécutez heroku releases.
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
Utilisez la commande heroku releases:output pour afficher la sortie de l’exécution d’une étape Release Phase spécifique :
heroku releases:output v40 --- Migrating db --- INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL.
Vérification des journaux de version
Accédez aux journaux associés à une version à partir de l’onglet Activité de votre application. Cliquez sur Afficher le journal de version en regard de la version que vous souhaitez afficher.
Ressources
