Process de développement

Cette page décrit, rapidement, le processus complet de développement d'un ticket : du dev à la production.

👨🏽‍💻 Développement du ticket

• sur Trello, s'assigner la carte et la déplacer dans la colonne "En cours de développement"
• identifier le numéro de la carte sur Trello :
  • soit en cliquant sur la carte puis en regardant dans l'URL
  • soit via un add-on Firefox/Chrome
• depuis la branche develop, tirer une nouvelle branche nommée issue/XXX (où XXX est le numéro de la carte)
• faire les différents commits sur cette branche en respectant les règles suivantes pour le message de commit :
  • préfixer avec le numéro de la carte entre parenthèses : (XXX) message de commit
  • écrire un message de commit qui tient en moins de 72 caractères (pour qu'il apparaisse en entier sur Github). Le plus simple est d'écrire le message en anglais, qui est souvent plus court que le français.
  • pour les commits "simples" (wording, changements d'images, etc.), ne pas hésiter à se contenter d'un message minimal (ex: (XXX) Wording)
  • pour les commits plus compliqués, ne pas hésiter à bien détailler ce qui est fait et pourquoi dans le corps du commit (en gardant le titre du commit sous les 72 caractères)
• pusher tous les changements

🧐 Review technique de la PR

• sur Trello, déplacer la carte dans la colonne "PR en attente"
• sur Github :
  • créer la pull-request de issue/XXX vers develop :
    • en respectant le template qui apparaît automatiquement dans le formulaire
    • en respectant la nomenclature suivant pour le titre de la PR : #type (XXX) Titre (où #type doit être soit #patch pour une petite fonctionnalité ou un correctif/wording, soit #minor pour une fonctionnalité/évolution notable et où XXX est le numéro de la carte)
  • ajouter le label [en attente de review] à la PR
  • ajouter au moins un(e) autre développeur(euse) à la liste des reviewers
• sur Mattermost, ne pas hésiter à indiquer dans le channel #tech qu'une nouvelle PR est en attente

À partir de là une ou plusieurs personnes feront des retours sur la PR et deux scénarios possibles :

1. la PR est validée :

• le label [en attente de review] est remplacé par [qa]
• la pull-request apparaît comme approved sur Github
• sur Trello, la carte est déplacée dans "PRs validées"

2. la PR n'est pas validée :

• le label [en attente de review] est remplacé par [à corriger]
• sur Trello, la carte est déplacée dans "PRs à corriger"

Dans les deux cas, le ou la reviewer indique sur Mattermost que la PR vient d'avoir une review.

🧑🏻‍🎨 Review fonctionnelle

La review fonctionnelle (ou QA) consiste à valider que la fonctionnalité/correctif qui a été implémentée correspond bien à la demande. C'est le moment où on vérifie que tous les cas fonctionnent, que la UI est correcte, etc. Bref, c'est la validation fonctionnelle.

Il n'y a pas de processus fixe concernant la QA car nous n'avons pas de personne dédiée au sujet, la seule règle est donc que c'est le développeur en charge d'une carte qui est responsable de sa QA.

Cela veut dire que c'est au développeur de tester son travail puis d'évaluer s'il a besoin de la validation de l'équipe produit, et si oui sous quelle forme : parfois le partage d'une simple capture d'écran via Mattermost suffit pour que l'équipe produit valide, parfois il faut déployer la fonctionnalité en préprod pour que l'équipe produit joue avec la fonctionnalité et valide que tout est OK.

Bref, les lignes directrices sont :

• c'est au développeur de tester son code et garantir qu'il est fonctionnel
• la QA par l'équipe produit ne se fait qu'à l'initiative du développeur, et selon la modalité qu'il juge pertinente : partage de capture d'écran, déploiement en préprod, autre...
• les reviewers sont invité(e)s à faire une rapide passe de QA également, à l'occasion de la review technique

Pour ce qui est du process :

• sur Trello, déplacer la carte dans "En QA" (si l'équipe produit doit encore valider la carte) ou dans "QA validée" si la QA est... terminée !
• sur Github, quand la QA est terminée : remplacer le label [qa] par [validé]

🚀 En production !

Quand le temps de la mise en production est venu, la PR est mergée et le code est déployé selon le protocole indiqué ici : https://github.com/MTES-MCT/resorption-bidonvilles/wiki#process-de-mise-en-production