Review Apps
Certains outils d'intégration continue combinés avec des plateformes de déploiement (Cf. GitLab Review Apps & Heroku Review Apps) 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
payinetcashoutà partir de la branchemaster.A chaque changement (ou commit) sur les branches
payinoucashout(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.cometcashout.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
masterpasse automatiquement par les process de "build" et "test" de l'Intégration Continue. Dans le cas du Déploiement Continu : le produit est automatiquement déployé en production. Dans le cas de la Livraison Continue : 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.
Exemple
Pipeline de build, deploy et test de l'Intégration Continue
Validation d'une branche (merge)
Déploiement manuel (promote)
Rollback
Heroku Review Apps
GitLab Review Apps
Last updated