Logo Khaganat

Différences

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

Lien vers cette vue comparative

Prochaine révision
Révision précédente
fr:collabo_pymanager [2017/12/07 22:44] – créée YannKfr:collabo_pymanager [2021/12/03 19:19] (Version actuelle) – modification externe 127.0.0.1
Ligne 1: Ligne 1:
 ====== Collaborer sur le dépôt OpenNeL pyManager ====== ====== Collaborer sur le dépôt OpenNeL pyManager ======
  
-{{:fr:nevraxpillpython2.png|}}+{{  :fr:nevraxpillpython2.png  |}}
  
-Ce dépôt est celui qui contient tout les librairies et utilitaires python mis en place pour générer, manipuler et gérer tous les objets des services et clients d'OpenNeL. Ils serviront à la mise en place d'outils de leveldesign, de monitoring ou de gestion en direct.+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
 + 
 + 
 +===== Le workflow de travail ===== 
 + 
 +==== 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.
  
-<WRAP center round important 60%> 
-Page en cours de création 
-</WRAP> 
  
  
  
 {{tag>Données Ryzom_Core Outils}} {{tag>Données Ryzom_Core Outils}}
CC Attribution-Share Alike 4.0 International Driven by DokuWiki
fr/collabo_pymanager.1512683069.txt.gz · Dernière modification : 2021/12/03 19:18 (modification externe)

Licences Mentions légales Accueil du site Contact