diff --git a/gitlab/correctifs_evolutions.md b/gitlab/correctifs_evolutions.md index 7d14ecfdfb845c0069fa912b524fb77e0218b1cd..7dbb0b223854fc38141c2be40438e84651472c01 100644 --- a/gitlab/correctifs_evolutions.md +++ b/gitlab/correctifs_evolutions.md @@ -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.  diff --git a/gitlab/depot_gitlab.md b/gitlab/depot_gitlab.md index 7461e2c27f729039ee23bd922d54514f5460f99a..65213f9bf2b31ee2f7e0eefa747a543fa5e57057 100644 --- a/gitlab/depot_gitlab.md +++ b/gitlab/depot_gitlab.md @@ -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**