====== Collaborer sur le dépôt bpyNel workbench - OpenNeL legacy ====== Cette page n’est conservée que pour des raisons historiques. Il n’y a plus lieu de collaborer à ce dépôt. {{ :fr:bpynel_workbench.png?nolink 200 |}} Ce dépôt est celui qui contient le(s) plugin(s) qui feront de Blender 2.8 notre éditeur de jeu. Il se sert de la bibliothèque de composants développée dans [[fr:collabo_py_nel]]. L’interface du plugin doit se faire en suivant les indications données pour Blender 2.8 : [[https://developer.blender.org/T55407|2.8: Addons UI]] ===== Plugins ===== ==== NeL Object Import - io_nel_import ==== * {{:fr:blender-plain-logo-32.png?nolink|blender.org}}[[fr:py_nel_workbench/io_nel_import | NeL files import ]] * {{:fr:blender-plain-logo-32.png?nolink|blender.org}}[[fr:py_nel_workbench/io_nel_export | NeLfiles export ]] * {{:fr:blender-plain-logo-32.png?nolink|blender.org}}[[fr:py_nel_workbench_add_nel_shader | NeL Shader ]] * {{:fr:blender-plain-logo-32.png?nolink|blender.org}}[[fr:py_nel_workbench/scene_nel_workspace | NeL Workspace ]] ===== 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 modifications sans interférer avec le dépôt principal. Pour cela, il vous suffit de cliquer sur le bouton suivant sur la page d’accueil du projet. {{:fr:fork.png}} Vous serez alors redirigée vers votre copie du dépôt. ==== Travailler directement sur le dépôt principal ==== Si vous êtes une développeuse "officielle" (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>py_nel_project/bpy_nel_workbench|bpyNel workbench]]. 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** : Branche **stable**, où seuls les hotfix et les nouvelles releases sont autorisées à être mergées. Cette branche garantit une expérience sans (trop de) bugs, dans la mesure du possible. * Branche **Develop** : Branche de développement, dans laquelle les features terminées sont mergées, en vue des futures releases. À cela s'ajoutent des branches temporaires, ouvertes et fermées suivant les besoins: * Branche **Feature** : C'est **une nouvelle addition** au code, développée dans une branche séparée afin de réduire les risques d'introduction de bugs dans ''develop''. Elle sera à merger 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 features prévues dans une nouvelle release ont été mergées dans develop. Une fois cette branche créée, seuls les bugfix y sont autorisés, jusqu'à ce qu'elle soit mergée dans Master, 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 Master**. De ce fait, elle sera mergée vers la branche ''Master'', ainsi que ''develop''. Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommées 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ée, vous pouvez créer une Merge Request, à destination de **Develop**. Cette requête doit respecter ces impératifs : * Le CI Gitlab doit pourvoir la compiler avec succès. * La feature et son code doivent être documentées. * La Merge Request doit clairement expliquer la feature (son utilisation, les tests à effectuer, etc). ==== Publication d'une release ==== Une fois un certain nombre de features mergé avec Develop, nous créons une nouvelle branche release. À partir de ce moment, seuls les bugfix sont acceptés (code freeze). Une fois le nouveau code testé, et les bugs corrigés, la release est taguée, et publiée dans master. ==== Créer un HotFix ==== Il arrive que des bugs critiques passent à 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 à [[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ées en se servant du système d'//Issues// de ce dépôt : [[gitlab>py_nel_project/bpy_nel_workbench/issues|Issue sur bpyNel workbench]] 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 Blender}}