# Workflow GIT

## Fonctionnement général:
l'idée générale est d'avoir trois branches, correspondant chacune a 3 environnements : 
| env | branche gitlab |
|--|--|
| prod |  master|
| preprod | staging |
| recette | devellop |
l'idée c'est qu'on ait des env et des branches qui soient "iso", qu'un changement sur ces branches correspondent a un déploiement dans la même journée
un fonctionnement gitflow classique entre master et staging
#### voir schéma dans le repo

## user stories : 
### nouvelle feature fonctionnement classique

 - on crée une branche depuis staging
 - on dev, on propose la merge request sur devellop
 - on déploie  devellop sur la recette, le client teste
 -  si ça passe pas, on retravaille sur notre branche, et on remerge sur devellop et on redéploie sur recette pour retests
 - quant le dev est validé, on est bon.
 - quant ils demandent de livrer la feature sur preprod, on fait une merge request de la branche sur laquelle est la feature sur la branche staging
 
### livraison prod
- lorsque le client est content de ce qu'il y a sur preprod on merge request staging sur master, on versionne et on annonce le go pour la livraison en prod

### ils veulent livrer sur la prod le contenu de la préprod mais sans une feature
 - si il y a des features sur preprod qui sont pas voulues finalement en prod mais qui sont sur preprod, on git revert les commits de merge sur staging, on versionne, on relivre staging sur preprod, pour qu'ils puissent tester la preprod sans les commits demandés.
 - lorsqu'ils valident, on merge request staging sur master, on versionne et on annonce le go pour la livraison en prod
### bug d'une feature sur la preprod
- si une feature est buggée en preprod, on git revert le commit de merge de la branche de feature, et on le retravaille sur la recette si le temps le permet jusqu’à ce qu'ils soit validé. on refait un cycle complet avec test sur recette
- lorsque la feature a été validée sur recette, on refait la merge request vers staging de la branche de feature, on merge on versionne et on relivre sur preprod la feature qui a subi un cycle complet de correction
### hotfix (correction de bug en prod)
- lorsqu'un bug est trouvé en prod, on branche une branche hotfix depuis master, on corrige, on vient merger cette branche sur staging pour déployer et tester (si conflict, on revert tout les ajouts de nouvelles features présentes sur staging, pour les ré-appliquer après)
- lorsque le correctif est validé, on merge le hotfix sur master, on versionne, et on annonce le go pour livraison en prod. 
- on applique le hotfix aussi à la branche devellop et on livre sur recette
### demandes de livraisons features par features sur preprod
- le client veut les nouvelles features A, B et C  
- elles sont dev sur des branches tirées de staging puis mergées sur devellop et livrées sur recette 
- le client teste  et finalement il veut que la A et la B sur la preprod  
- on merge la branche A et B sur staging  et deployées sur preprod
- le client test  il veut finalement que la A en livraison sur la prod  
- on revert le commit de merge de la B  
- on laisse re-tester  
- on merge preprod sur master puis on annonce le go pour lla livraison en prod
- au besoin on remerge la branche B sur staging 

## problèmes a prévoir
###  conflits sur devellop

les divergences entre devellop et master et entre devellop et staging peuvent faire en sorte qu'on se retrouve avec des conflits de merge et des résolution de conflit pouvant entraîner des bugs. c'est le seul problème avec ce workflow. l'avantage c'est que ces bugs se retrouveront sur environnement le moins critique.
##### pour résoudre
- soit résolution classique, soit, si ça commence a être trop bordélique, on reset la branche devellop avec ce qu'il y a sur staging, on applique notre commit en conflit et on vient re-merger les 4-5 branches en cours de tests
### features abandonnées sur devellop
de temps en temps, on reset la branche devellop avec ce qu'il y a sur staging et on vient re-merger les 4-5 branches avec les features attendues en cours de tests
## mise en place

 - créer une branche staging avec intégration continue
 - faire en sorte qu'on puisse avoir  des builds de cette branche, et une commande cli pour deployer sa dernière version lorsqu'on veut déployer sur preprod
 - dès que c'est le cas, on utilise le workflow decrit précédemment pour les nouvelles features et les hotfixs
 - le features qui arrivent de branches tirées de dev (précedent workflow) continuerons a etre deployées sur preprod via cherry pick comme avant (a la difference qu'on cherry pickera sur staging et non sur master du coup)
