> For the complete documentation index, see [llms.txt](https://guide-agile.wishtack.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide-agile.wishtack.io/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps.md).
# Review Apps
Certains outils d'intégration continue combinés avec des plateformes de déploiement *(Cf.* [*GitLab Review Apps*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps.md#gitlab-review-apps) *&* [*Heroku Review Apps*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps.md#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)*.
1. Le code de production est sur la branche `master`.
2. L'équipe crée deux branches `payin` et `cashout` à partir de la branche `master`.
3. 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`**.
4. Les parties prenantes autorisées peuvent **valider 👍*****(ou rejeter 👎)*** le changement et **par simple clic**, le code est **"merged" dans la branche `master`**.
5. La branche `master` passe automatiquement par les process de "**build**" et "**test**" de l'[Intégration Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/integration-continue.md).\
Dans le cas du [Déploiement Continu](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/deploiement-continu.md) : le produit est **automatiquement déployé en production**.\
Dans le cas de la [Livraison Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue.md) : le produit est **automatiquement déployé sur un environnement de validation** *(staging)* et prêt à être déployé en production par **simple clic**.
{% hint style="success" %}
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**.
{% endhint %}
## 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
{% embed url="" %}
Heroku Review Apps
{% endembed %}
## GitLab Review Apps
{% embed url="" %}
GitLab Review Apps
{% endembed %}