Différences

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

--- fr:collabo_khanat_code [2016/07/11 17:11] – [Le dépôt et ses branches] Dremor
+++ fr:collabo_khanat_code [2021/12/03 19:19] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-====== Collaborer sur le dépôt khanat-code ======
+====== Collaborer sur le dépôt OpenNeL Khanat Code ======
 {{ :fr:system.png?nolink |}}
-<WRAP center round important 60%>
+Ce dépôt est celui qui contient tout le code nécessaire à la compilation du serveur, ainsi que des outils du système OpenNeL, appelé un temps [[fr:tag:informatique:ryzom_core:start|Ryzom Core]]. Nous avons cessé d’utiliser le client, remplacé par un client développé sous le [[fr:godot:start|Godot Engine]].
-WIP
-</WRAP>
@@ Ligne 11: / Ligne 9: @@
 ==== Mise en place d'un dépôt personnel (fork) ====
-<WRAP center round important 90%>
-Cet étape n'est pas utile aux développeurs khanat officiels, qui ont directement accès au dépôt, et peuvent créer une branche dédié à leur travail.
-</WRAP>
 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.
@@ Ligne 23: / Ligne 17: @@
 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/khanat-opennel-code|Khanat OpenNeL code ]].
+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 de workflow dit [[fr:gitflow]]. De ce fait, il y a deux types de branches : principales et temporaires.
+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 **Lirria** (aka master) : 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 **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.
@@ Ligne 41: / Ligne 42: @@
   * 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 **Bugfix** : C'est une branche ayant pour objectif de **rapidement corriger un bug affectant Lirria**. De ce fait, elle sera merge vers la branche "lirria", ainsi que "develop".
+  * 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:
@@ Ligne 49: / Ligne 50: @@
   * Branche **Release** : Doit être nommée "release/[futur tag]"
         * Exemple : "release/v0.2.0"
-  * Branche **Bugfix** : Doit être nommée "bugfix/[numéro du/des bug(s)]-[descriptif du/des bug(s) sans espace ni ponctuation]"
+  * Branche **Hotfix** : Doit être nommée "hotfix/[numéro du/des bug(s)]-[descriptif du/des bug(s) sans espace ni ponctuation]"
-        * Exemple : "bugfix/33-empêcher-les-poisson-de-sortir-de-leau"
+        * Exemple : "hotfix/33-empêcher-les-poisson-de-sortir-de-leau"
 ==== Publication d'une feature ====
-==== Merge d'une feature dans Develop ====
-==== Création d'une release ====
+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 :
-==== Finaliser une release ====
+  * Le CI Gitlab doit pourvoir la compiler avec succès.
+  * La feature et son code doivent être documentée.
+  * 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/khanat-opennel-code/issues|Issue sur Khanat OpenNeL code]]
+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}}