Contribuer au noyau

Edit me

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 une issue dans voozanoo4 à propos de l’évolution ou le débug. C’est ici que seront historisés les conversations à propos de la PR et de sa livraison. Les messages liés à la PRs ne seront plus évident à trouver après le merge, c’est pour cela qu’on garde tout sur l’issue, sauf la revue de code.
  • Créer une branche depuis la branche master (mettre le master à jour avant!)
    • exemple :
git checkout master
git pull
git checkout -b mzz-VOO4-42-widget_bugfix
  • 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:
exemple1
Schéma 1: lorsque vous venez de mettre à jour une branche, un bouton apparait et propose de préremplir la création de PR
exemple2
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 mzz-VOO4-42-widget_bugfix
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 mzz-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 mzz-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 mzz-VOO4-42-widget_bugfix

Taper cette commande créera la branche sur GitHub, et poussera les modifications.

Schéma :

──────○─────────────────────○────── master
       \                   /      
        ○─────○─────○─────○         mzz-VOO4-42-widget_bugfix

Merci d’avance pour votre contribution !