Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:collabo_pymanager [2017/12/09 21:28] – YannK
+++ fr:collabo_pymanager [2021/12/03 19:19] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 5: / Ligne 5: @@
 Ce dépôt est celui qui contient tout les librairies et utilitaires python mis en place pour gérer tous les objets des services et clients d'OpenNeL. Ils serviront à la mise en place d'outils de de monitoring ou de gestion en direct.
-<WRAP center round important 60%>
-Page en cours de création
+===== Le workflow de travail =====
-</WRAP>
+==== Mise en place d'un dépôt personnel (fork) ====
+Pour commencer, il vous faudra forker le dépôt principal. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.
+Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet.
+{{:fr:fork.png}}
+Vous serrez alors redirigé vers votre copie du dépôt.
+==== Travailler directement sur le dépôt principal ====
+Si vous êtes un développeur "officiel" (avec une autorisation d'accès dans le groupe Khaganat ) chez nous, vous aurez accès au dépôt principal sur notre GitLab : [[gitlab>khaganat/mmorpg_khanat/opennel-pymanager|OpenNeL pyManager]].
+Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.
+==== Le dépôt et ses branches ====
+Khanat utilise un workflow inspiré de [[fr:gitflow]]. De ce fait, il y a deux types de branches : principales et temporaires.
+Les branches principales sont :
+  * Branche **Master** (aka Lirria) : Branche **stable**, où seul les hotfix et les nouvelles release sont autorisés à être mergés. Cette branche garantie une expérience sans (trop de) bugs, dans la mesure du possible.
+  * Branche **Develop** : Branche de dévellopement, dans laquelle les features terminés sont mergés, en vu des futures releases.
+A cela s'ajoute des branches temporaires, ouvertes et fermés suivants les besoins:
+  * Branche **Feature** : C'est **une nouvelle addition** au code de Khanat, développée dans une branche séparé afin de réduire les risque d'introduction de bugs dans develop. Elle sera à merge sur la branche "develop".
+  * Branche **Release** : Ce type de branche est **spécifique au dépôt principal**, et est crée quand toutes les feature prévu dans une nouvelle release ont été merge dans develop. Une fois cette branche créer, seul les bugfix y sont autorisés, jusqu'à ce qu'elle soit merge dans "lirria", une fois considéré comme suffisamment stable pour la "production".
+  * Branche **Hotfix** : C'est une branche ayant pour objectif de **rapidement corriger un bug critique affectant Lirria**. De ce fait, elle sera merge vers la branche "lirria", ainsi que "develop".
+Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommé de la façon suivante:
+  * Branche **Feature** : Doit être nommée "feature/[numéro(s) de(s) (l')issue][nom de la feature sans espaces ni ponctuation]"
+        * Exemple : "feature/57-69-75-nouveau-fichier-dintegration-continue"
+  * Branche **Release** : Doit être nommée "release/[futur tag]"
+        * Exemple : "release/v0.2.0"
+  * Branche **Hotfix** : Doit être nommée "hotfix/[numéro du/des bug(s)]-[descriptif du/des bug(s) sans espace ni ponctuation]"
+        * Exemple : "hotfix/33-empêcher-les-poisson-de-sortir-de-leau"
+==== Publication d'une feature ====
+Une fois que vous considérez la feature que vous avez développé terminé, vous pouvez créer une Merge Request, à destination de **Develop**. Cette requête doit respecter ces impératifs :
+  * La feature et son code doivent être documentés ;
+  * La Merge Request doit clairement expliquer la feature (son utilisation, les test à effectuer, etc.).
+==== Publication d'une release ====
+Une fois un certain nombre de features sont mergés avec Develop, nous créons une nouvelle branche release. A partir de ce moment, seul les bugfix sont acceptés (code freeze).
+Une fois le nouveau code testé, et les bugs corrigés, la release est tagué, et publié dans master.
+==== Créer un HotFix ====
+Il arrive que des bugs critiques passe à travers les maillons du filet de la QA, c'est pourquoi il est parfois nécessaire de faire des "hotfix" (correction à chaud).
+Pour cela, il faut faire une branche "hotfix" depuis master, y corriger le bug, puis le publier dans master.
+===== Gestion des Merge Request =====
+Lorsqu'on a terminé une //Feature//, il faut faire une demande de //Merge Request// en expliquant en quoi la tâche est terminée et l'affecter à une autre personne même si on a la capacité de merger directement.
+Cela permettra d'avoir un contrôle, ne serait-ce que formel, sur l'ajout.
+**On ne merge jamais soi-même directement sur Master**.
+===== Gestion des Issues =====
+De préférence à la [[taf>fr:start|la base TAF]], créez les demandes d'ajout de features sur le système Gitlab de ce dépôt. Bien évidement, les //Bugs// liés à la programmation sont à signaler ici également.
+De même, avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça vous pouvez numéroter la branche correctement et on sait que quelqu'un a commencé à travailler sur ce sujet.
+Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'//Issues// de ce dépôt : [[gitlab>khaganat/mmorpg_khanat/opennel-pymanager/issues|Issue sur OpenNeL pyManager]]
+Il suffit de cliquer sur : {{ :fr:new_issue2.jpg?nolink |}}
+Vous renseignez ensuite les différents champs.
+Le titre doit être concis et le plus explicite possible.
+\\ Par contre, n'hésitez pas à être le plus précis possible dans la zone //Description//.
+Il y a ensuite 3 zones de champs à renseigner :
+  * //Assignee// pour indiquer la personne à qui affecter la tâche ;
+  * //Milestone// qui désigne la version du projet pour laquelle ce travail devra être fait ;
+  * //Labels// permet de choisir des tags pour déterminer le genre de tâche ;
+  * //Select due date// propose de fixer une date de remise des travaux.
+Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.
+===== Gestion des Milestones =====
+On se servira des mêmes //milestones// que pour les autres dépôts et secteurs de développement du projet, présentés sur la page [[fr:milestones]].
+===== Gestion des Tags =====
+Nous n'utilisons pas de //Tags// sur ce dépôt Git pour le moment.
+===== Gestion des Labels =====
+Les //Labels// doivent être génériques et permettre ainsi de regrouper par genre de compétence. Il est possible d'en créer lors de la génération d'une //Issue// si aucune ne convient mais cela peut être fait par la suite, surtout quand on est indécis.
 {{tag>Données Ryzom_Core Outils}}