Review Apps
Last updated
Last updated
Certains outils d'intégration continue combinés avec des plateformes de déploiement (Cf. & ) permettent de créer dynamiquement des environnements de déploiement.
Cela permet d'adopter l'approche de développement décrite ci-dessous.
Supposons que l'équipe de développement travaille sur deux fonctionnalités en parallèle payin (pour le crowdfunding) et cashout (pour la récupération de la cagnotte).
Le code de production est sur la branche master.
L'équipe crée deux branches payin et cashout à partir de la branche master.
A chaque changement (ou commit) sur les branches payin ou cashout (et si tout se passe bien), le produit est déployé automatiquement sur un environnement créé dynamiquement et accessible depuis une URL (ou plusieurs) créée dynamiquement ; par exemple, payin.review.wishtack.com et cashout.review.wishtack.com.
Les parties prenantes autorisées peuvent valider 👍(ou rejeter 👎) le changement et par simple clic, le code est "merged" dans la branche master.
La branche master passe automatiquement par les process de "build" et "test" de l'.
Dans le cas du : le produit est automatiquement déployé en production.
Dans le cas de la : le produit est automatiquement déployé sur un environnement de validation (staging) et prêt à être déployé en production par simple clic.
De la même façon qu'il est idéal de définir les User Stories les plus granulaires possibles, il est recommandé de réduire au minimum la durée de vie d'une branche et la quantité de changements.
Il est intéressant de ne pas dépasser une durée de vie d'un jour pour chaque branche. Quitte à en recréer une nouvelle avec le même nom pour apporter de nouveaux changements.
Cela permet d'éviter le git spaghetti et les conflits de merge.
