-
Notifications
You must be signed in to change notification settings - Fork 1
Utilisation de GitHub
Pour notre projet, nous suivons une approche de gestion de versions basée sur deux branches principales : develop et main. Voici comment nous utilisons ces branches :
La branche develop est notre branche principale de développement. Toutes les fonctionnalités en cours de développement sont fusionnées dans cette branche. Voici comment utiliser la branche develop :
-
Création de fonctionnalités : Les fonctionnalités sont développées dans des branches de fonctionnalités distinctes à partir de
develop. -
Intégration continue : Toutes les fonctionnalités terminées sont fusionnées dans
developvia des pull requests. - Tests et validation : Avant la fusion, les fonctionnalités sont testées et validées pour garantir leur bon fonctionnement.
La branche main est notre branche de déploiement. Une fois que les fonctionnalités sont testées et validées dans develop, elles sont fusionnées dans main pour le déploiement. Voici comment utiliser la branche main :
-
Déploiement : La branche
mainest utilisée pour déployer les versions stables de notre application. -
Versionnement : Chaque fusion dans
mainest associée à un numéro de version, suivant les principes de gestion de versions sémantiques.
Dans notre projet, nous utilisons une convention de nommage des branches qui reflète les types définis dans notre liste de labels. Chaque nom de branche commence par un type spécifique suivi d'un "/". Voici comment nous structurons nos branches :
-
Type/nom_pertinent : Nous utilisons le type pour catégoriser les branches en fonction de leur objectif ou de leur domaine. Le nom pertinent décrit brièvement la fonction ou la tâche associée à la branche. Voici quelques exemples de branches conformes à cette convention :
-
feature/nouveau_bouton: Cette branche serait utilisée pour développer une nouvelle fonctionnalité, comme indiqué par le label "Feature". -
bug/correction_formulaire: Cette branche serait utilisée pour corriger un bug spécifique, comme indiqué par le label "Bug". -
devops/integration_continue: Cette branche serait utilisée pour les tâches liées à l'intégration continue ou à l'automatisation, comme indiqué par le label "DevOps".
-
En utilisant cette convention, nous maintenons une structure claire et cohérente pour nos branches, ce qui facilite la navigation dans le dépôt et la compréhension de leur objectif. De plus, cela permet une synchronisation plus directe avec nos labels, assurant une meilleure traçabilité entre les branches et les tâches associées.
Nous utilisons des labels pour organiser et prioriser nos issues et pull requests, en nous inspirant des principes du "Cynefin Framework: Best practice". Voici les labels que nous utilisons et leur signification :
- Effort : suite de fibonacci : : Ces labels indiquent l'effort estimé nécessaire pour accomplir la tâche. Cela aide à prioriser le travail et à allouer efficacement les ressources.
- Priorité : 1 - Haute / 5 - Basse : Ces labels indiquent la priorité de la tâche par rapport aux autres. Cela aide à identifier les tâches critiques et à s'assurer que les efforts sont dirigés vers les éléments les plus importants.
- État : Innactif / En cours / Approuvé / Terminé : Ces labels suivent le cycle de vie de la tâche, de sa création à son achèvement. Cela permet à l'équipe de suivre facilement le statut des tâches et de savoir quelles sont les prochaines actions à prendre.
- Type : Bug / Fix / Configuration / Documentation / etc... : Ces labels indiquent le type de la tâche à accomplir. Cela aide à catégoriser les tâches et à assigner les bonnes personnes en fonction de leurs compétences et de leur domaine d'expertise.
- Cynefin : Simple / Complicated / Complex / Chaotic : Ces labels classent les tâches en fonction de leur nature selon le "Cynefin Framework". Cela aide à choisir les approches et les méthodes appropriées pour résoudre les problèmes, en reconnaissant que différentes situations nécessitent différentes approches.