Heroku - 12 Heroku Pipelines et Git et Fusions

Bienvenue dans cette suite sur Heroku. Nous avons vu plusieurs applications représentant différentes étapes du développement (dev, staging, production) et les Review Apps jetables. Toutes partagent la même base de code, mais sont indépendantes. La question est donc : comment gérer ce code commun à des applications séparées ? C'est ici qu'entre en jeu Git, l'un des prérequis de ce cours.

Branches Git et applications Heroku

Git permet de créer des branches : des copies du code modifiables indépendamment. Imaginons trois branches : dev, master et staging. Si vous faites un commit sur dev, seule l'application de développement est impactée ; un commit sur master n'affecte que la production ; un commit sur staging ne touche que l'application staging. Quand votre travail est prêt en dev, vous le promouvez en production via une fusion (git merge) : les deux branches partageront alors le même code. Aucune application ne disparaît, elles se synchronisent simplement. C'est cette corrélation entre Git et Heroku Pipelines qui vous évite de gérer manuellement l'infrastructure.

Pour partager aussi les configurations (add-ons, variables d'environnement) entre applications, Heroku utilise un fichier app.json placé à la racine du projet. Ce fichier décrit l'application : nom, description, repository, logo, add-ons à installer, variables à pré-configurer, etc. La plupart des champs (description, website, success) sont informatifs et n'impactent pas la configuration, mais ils permettent de tout automatiser sans copier-coller manuel d'une application à l'autre.

2 couches : dev + production (équipe de 1-2 personnes)
3 couches : Review Apps + staging + production (équipe moyenne)
4 couches : ajoute un environnement intermédiaire pour les grandes équipes

Côté architecture, Heroku propose plusieurs options selon la taille de votre équipe. L'architecture à 2 couches (staging + production) suffit pour 1 ou 2 développeurs : la branche master alimente la production, et vous testez sur staging avant fusion. L'architecture à 3 couches ajoute les Review Apps : chaque développeur travaille sur sa propre Review App à partir d'une Pull Request, puis suggère le passage en staging quand le code est prêt, et enfin en production si les tests passent. L'architecture à 4 couches est utilisée par les grandes équipes : pendant que du code est en cours de test sur staging, le déploiement suivant peut déjà être préparé. Ces architectures dépendent uniquement de votre équipe ; choisissez celle qui correspond à votre organisation. À bientôt pour la prochaine vidéo.

En résumé

Cette leçon explique comment utiliser les Heroku Pipelines avec Git pour gérer plusieurs environnements de déploiement (development, staging, production). Chaque branche Git correspond directement à un environnement Heroku spécifique, et les merges permettent de promouvoir le code entre les étapes. Le fichier App.json/Procfile facilite la configuration automatique de toutes les applications sans manipulation manuelle, tandis que les review apps permettent de tester les changements de manière isolée avant leur fusion en production.

Points clés

Les Heroku Pipelines gèrent plusieurs applications indépendantes (develop, staging, production, review apps) partageant la même base de code source
Chaque branche Git (develop, staging, master) correspond à un environnement Heroku distinct, et les merges synchronisent automatiquement le code entre applications
Le fichier App.json permet de configurer les add-ons et variables d'environnement une seule fois, que Heroku reproduit sur toutes les applications sans recopie manuelle
L'architecture du pipeline s'adapte à la taille de l'équipe : 2 couches (1-2 devs), 3 couches (2-3 devs), ou 4 couches (grandes équipes) pour éviter les conflits
Les review apps sont jetables et créées automatiquement pour chaque pull request, permettant de tester le code en isolation avant fusion en production

Questions fréquentes

Qu'est-ce qu'une Heroku Pipeline et comment fonctionne-t-elle avec Git ?

Une Heroku Pipeline gère plusieurs applications représentant différentes étapes du développement. Chaque branche Git (develop, staging, master) correspond à un environnement Heroku spécifique. Quand vous fusionnez une branche dans Git, le code de l'application correspondante est automatiquement mis à jour.

Comment configurer plusieurs applications Heroku sans les recopier manuellement ?

Utilisez le fichier App.json à la racine du projet. Il contient tous les add-ons et variables de configuration. Heroku lit ce fichier et applique automatiquement la même configuration à toutes les applications du pipeline, sans intervention manuelle.

Quelle architecture de pipeline dois-je utiliser pour mon équipe ?

Le choix dépend de la taille de l'équipe. Pour 1-2 développeurs, une architecture 2 couches (develop + production) suffit. Pour 2-3 personnes, préférez 3 couches (develop + staging + production). Pour les grandes équipes, utilisez 4 couches avec staging comme zone de regroupement du code avant les tests finaux.