Heroku - 13 Heroku Pipelines Tests

Bienvenue dans cette suite sur Heroku. Lorsque vous effectuez vos tests, il est essentiel de s'assurer que le nouveau code ne va pas casser des fonctionnalités existantes. Cette validation passe principalement par des tests automatiques exécutés à chaque arrivée de code nouveau. La solution intégrée d'Heroku qui crée un environnement dédié pour faire passer ces tests automatiquement s'appelle Heroku CI (intégration continue), elle est totalement intégrée aux Pipelines.

Le fonctionnement de Heroku CI

Lorsqu'il y a un changement de code, Heroku CI crée une nouvelle application avec un environnement éphémère pour exécuter les tests. Une fois les tests terminés, tout est détruit. À chaque commit, un environnement neuf est instancié pour exécuter le nouveau code. Vous pouvez également configurer Heroku pour bloquer le déploiement si les tests échouent : c'est une sécurité supplémentaire pour ne jamais déployer de bugs en production.

Environnement de test créé automatiquement à chaque commit
Environnement détruit après l'exécution des tests
Possibilité de bloquer le déploiement en cas d'échec
Configuration des dynos dédiés aux tests (taille, nombre)
Configuration différenciée par application dans un Pipeline

Vous pouvez aussi configurer les dynos utilisés pour lancer les tests. C'est particulièrement utile si votre build est conséquent et demande du temps : vous pouvez accélérer les tests en allouant des dynos plus puissants pour rendre la création du build plus rapide. Heroku CI permet d'avoir des configurations différentes pour chaque application d'un Pipeline : une application peut exiger que tous les tests passent avant déploiement, alors qu'une autre peut être déployée immédiatement sans test.

Heroku CI fonctionne avec pratiquement tous les langages et frameworks. C'est possible parce qu'Heroku suit le Test Anything Protocol (TAP) : à la fin des tests, le programme renvoie 0 si tous les tests sont passés ou 1 si au moins un test échoue. La façon dont votre framework évalue le succès n'a pas réellement d'impact tant qu'il termine par un code de retour 0 ou 1 — Heroku saura quoi faire avec ce résultat. À bientôt pour la prochaine vidéo.

En résumé

Les pipelines Heroku intègrent une validation automatique du code par des tests avant tout déploiement. À chaque changement, Heroku crée un nouvel environnement de test, exécute la suite de tests, puis détruit l'environnement—ce processus garantit qu'aucun code défaillant n'atteint la production. La plateforme supporte tous les langages et frameworks en utilisant le protocole exit code (0 pour succès, 1 pour échec).

Points clés

Les tests automatiques valident que le nouveau code ne casse pas les fonctionnalités existantes
Heroku crée dynamiquement un environnement de test pour chaque changement de code, puis le détruit après exécution
Configuration possible pour bloquer le déploiement tant que tous les tests ne passent pas
Les dynos peuvent être dimensionnés pour accélérer l'exécution des tests
Heroku reconnaît les résultats de tests de tous les langages et frameworks via le protocole exit code (retour 0 = succès, 1 = échec)
Chaque application dans les pipelines peut avoir des exigences de test différentes

Questions fréquentes

Pourquoi faut-il configurer des tests automatiques sur Heroku ?

Pour s'assurer que tout nouveau code ne casse pas les fonctionnalités existantes avant déploiement en production. Cela crée un environnement de test à chaque changement, vérifie l'intégrité du code, puis détruit l'environnement.

Comment Heroku détecte-t-il l'échec ou la réussite des tests ?

Heroku utilise le protocole exit code : le programme retourne 0 si tous les tests passent, 1 s'ils échouent. Cela fonctionne indépendamment du langage ou du framework utilisé.

Est-il possible d'accélérer les tests sur Heroku ?

Oui, en configurant les dynos avec des ressources appropriées. Si votre build nécessite du temps pour les tests, un dimensionnement adéquat des dynos réduit la durée totale du pipeline.