@@ -10,7 +10,7 @@ Quand les projet abritent des fichiers non textuels (audio, fmw, zip etc..) des
Dans ce cas il est possible d'utiliser 100% des capacités de Git et c'est ce que nous allons faire en appliquant la procédure suivante.
Sur la branche **master** nous appliquerons uniquement les correctifs, cette branche **doit absolument être stable** à tout moment car elle permettra de générer un correctif quand on le souhaite.
Sur la branche **master** nous appliquerons uniquement les correctifs, cette branche **doit absolument être stable** à tout moment car elle permettra de générer un correctif si on le souhaite.
Une deuxième branche **next_version** permettra quand à elle à appliquer les évolutions, quand des correctifs sont appliqués à master, il faudra les merger sur cette branche de manière à avoir les dernières évolutions ainsi que les derniers correctifs.
...
...
@@ -23,7 +23,7 @@ Quand l'environnement de pré-production est validé, il est alors mergé sur ne
## 2. Faire un correctif
*Cette section est réservée aux projet de développement*
*Cette section est réservée aux projets de développement*
Un correctif est un bug remonté sur l'application en cours de production qui doit être corrigé pour publier une nouvelle version mineure, pour ce faire on créera une branche **à partir de master** qui se nommera bug/[intitulé du bug].
...
...
@@ -35,7 +35,7 @@ Chaque correctif doit être fait à travers une issue (documenté plus bas)
## 3. Faire une évolution
*Cette section est réservée aux projet de développement*
*Cette section est réservée aux projets de développement*
Les évolutions ne sont pas intégrées sur master qu'après la phase de pré-production, c'est pour cela qu'elles seront faites **à partir de next_version** et se nommeront evolution/[intidulé de l'évolution].
...
...
@@ -43,7 +43,7 @@ Une fois terminée, la branche sera rapatriée sur next_version.
Chaque évolution doit être fait à travers une issue (documenté plus bas)
Chaque évolution doit être faite à travers une issue (documenté plus bas)
## 4. Créer un correctif/évolution dans GitLab
...
...
@@ -57,10 +57,11 @@ Pas besoin de fournir de milestone car ce dernier sera décidé par le responsab
Parmi les labels disponibles il faudra spécifier si il s'agit d'un bug ou d'une évolution.
Lorsqu'un responsable produit va accepter une issue il voudra si c'est un bug créer une branche ainsi qu'une merge request, pour cela plusieurs étapes sont nécessaires.
#### 4.1. Assigner la demande
...
...
@@ -72,7 +73,7 @@ Le milestone permettra de connaître l'avancement du projet dans sa globalité,
Les labels permettront de filtrer les issues, les deux labels bug et evolution sont toujours présents car ils appartiennent au groupe, sur les applications vitis on retrouve autant de labels que de modules pour savoir rapidement à quel module correspond cette issue.
Les labels permettront de filtrer les issues, les deux labels bug et evolution sont toujours présents, sur les applications vitis on retrouve autant de labels que de modules pour savoir rapidement à quel module correspond chaque issue.
@@ -14,8 +14,6 @@ Chaque dépôt doit contenir un fichier README.md contenant une description du p
Une fois le dépôt crée il faudra éditer les paramètres comme détaillé ci-arpès dans la section [paramètres depot](depot_gitlab.html#)
## 2. Paramétrer le dépôt
Une fois le dépôt crée on accède à la page suivante, on peut déjà le cloner pour alimenter ses fichiers mais nous allons tout d'abord le paramétrer. Pour cela il suffit de se rendre dans la section **Settings**
