Contribuer au noyau
Rôles des branches
- Branche principale/de développement : master
- Préproduction (2.26-alpha) : staging-2.26
- Production (2.26): release-2.26
Important: contrairement aux autres dépôts ou la branche master est censé être le code testé et prêt à livrer en production, pour le noyau cette branche est la branche de développement.
Méthodologie :
- Pour toute demande de nouvelle fonctionnalité, il vaut mieux en discuter avec le Framework avant de commencer le développement, afin d’éviter des aller-retours au moment de la PR.
- Créer un ticket Jira sur le portail client du Framework. C’est ici que seront historisées les conversations à propos de la PR et de sa livraison.
- Créer une branche depuis la branche master (mettre le master à jour avant!). La norme pour les noms de branche est la suivante:
{numero-ticket-JIRA}- exemple :
git checkout master
git pull
git checkout -b VOO4-42
- Commiter les changements. La norme pour les messages de commit est la suivante:
VOO4-{numero-issue-JIRA} : {message (EN)}. Par exemple :
git add README.md
git commit -m "VOO4-42 : add README.md"
- Pusher / créer cette branche sur GitHub
git push
- Faire une PR sur la branche master
- le plus simple est d’aller sur l’onglet principal du dépôt, “code”, et de clique sur le bouton qui apparait lorsqu’on vient de mettre à jour une branche
- si la modification n’est pas assez récente, il faut se mettre sur votre branche (cf schéma 2) et cliquer sur “Nouvelle pull-request”
- Notifier le Framework par un mail
- Si nécessaire, modifier/améliorer la documentation Epidocs sur GitHub, en fonction des impacts de votre développement. Par exemple, si modifiez l’interface des listings, il faudrait mettre à jour la documentation sur la création de listings.
- Attention: faites la PR de votre branche vers le master, et non l'inverse!
| Imprimés écran: |
|---|
 |
| Schéma 1: lorsque vous venez de mettre à jour une branche, un bouton apparait et propose de préremplir la création de PR |
 |
| Schéma 2: vous pouvez aussi aller dans “code”, sélectionner votre branche, et cliquer sur “new pull request” |
- Le framework va effectuer une revue de code avec éventuelles corrections (à la charge du developpeur). Cela permet de vérifier le respect de la norme de codage notamment, et de proposer des améliorations du code analysé s’il a des faiblesses
- La QA dure 2 semaines (à la charge du Framework). Eventuellement, des corrections peuvent être demandées au développeurs si des bugs sont identifiés
- Le framework met en production si la QA est validée
Cas des hotfix
Il peut arriver qu’une demande soit urgente et qu’on ne puisse pas attendre le cycle normal de livraison. Dans ce cas là, il faut prévenir le Framework, et les tests seront fait pour assurer une livraison directement en production à la fin du sprint, au lieu de commencer par mettre le debug en préproduction.
Exemple complet (commandes)
git checkout master
git pull
git checkout -b VOO4-42
vi README.md # modification / développement
[...]
git status
git add README.md
git commit -m "VOO4-42 : update README.md"
git push
Comme la branche VOO4-42-widget_bugfix n’existe pas encore chez moi (elle a été crée à l’étape “git checkout -b {branch-name}”), GIT fait une erreur et demande à ce qu’elle soit créée:
fatal: La branche courante VOO4-42-widget_bugfix n'a pas de branche amont.
Pour pousser la branche courante et définir la distante comme amont, utilisez
git push --set-upstream origin VOO4-42
Taper cette commande créera la branche sur GitHub, et poussera les modifications.
Schéma :
──────○─────────────────────○────── master
\ /
○─────○─────○─────○ VOO4-42-widget_bugfix
Merci d’avance pour votre contribution !