Merge request : la checklist

icon Tags de l'article : , ,

Septembre 10, 2019
Hello,

Comme vous le savez peut-être, en plus d'être développeur, je suis le Scrum Master de mon équipe.

Afin d'améliorer la qualité et la stabilité de notre branche de dev principale, j'ai rédigé une petite checklist à utiliser par les développeurs lors des merge requests.

Pourquoi ?
  • Les listes de choses à faire sont souvent oubliées par l'équipe au moment des merge requests. Parfois partiellement (ah mince je n'ai pas testé sur iPhone), et parfois complètement (ah mince, comme c'était un petit dev je pensais que ça n'avait pas d'intérêt de tester).
  • En effet, une checklist a un impact psychologique bien plus puissant qu'une simple liste de choses à faire. Car en cochant, on indique qu'on a, personnellement, bien réalisé la tâche indiquée.
  • Dans l'idéal cette checklist serait à remplacer par un process CI automatisé. Ou en tout cas les étapes automatisables (build, tests, etc.).
  • La checklist peut aussi faire office de code review cheat sheet.
  • La checklist permet d'avoir un historique des merges, et d'en tirer des tendances.
  • Attention cependant : il ne faut pas que la checklist devienne une trop grosse contrainte. Il faut que le rapport besoin de qualité / contraintes soit optimal. Eviter donc d'avoir une liste de 20 étapes de tests avec 20 cases à cocher. Ca servirait juste à gaver votre équipe.
  • Egalement, il faut que l'équipe accepte et valide cette checklist. Vous devez éviter d'imposer ce type de process de force auprès d'une équipe qui n'en voit pas l'intérêt. A vous de sensibiliser votre équipe sur l'importance de la stabilité de vos branches de développement, du temps que ça fera gagner sur le développement, du nombre de bugs que vous éviterez, du fait que ça protégera des builds qui finissent à 21h, etc.

Voici donc cette petite checklist que j'espère avoir suffisamment teasé (à noter que plein d'éléments dans la partie optionnelle ne concernent qu'Angular/Ionic) :

------------------------------- MERGE REQUEST CHECKLIST -------------------------------

Date :
Dev name :
Reviewer name :
Branch :

MANDATORY
☐ It's a product story ? If yes, the PO validated the dev and gave his/her GO.
☐ The target branch (master/dev) was merged into the current branch
☐ No code / lint warnings or errors
☐ It compiles, starts, and was tested on all target devices/browsers
☐ It builds for all target environments (dev, qual, prod)
☐ The CI pipeline is green
☐ The wiki documentation was updated
☐ If the environment changed (global packages, .env file, …), the CI was updated and the team was warned by email

OPTIONAL (code reminders)
☐ PRODUCT : Every complicated choices are explained somewhere (documentation, specifications, comments, etc.)
☐ CODE QUALITY : No //todo or useless logs
☐ CODE QUALITY : No refactoring planned for later
☐ CODE QUALITY : The code is easy to read and understand
☐ COMPONENTS : OnPush on each component
☐ COMPONENTS : Smart/dumb pattern used
☐ PERFORMANCES : takeUntil($onDestroy) pattern applied on subscriptions
☐ PERFORMANCES : the app is fluid to use, no performances drop
☐ ROUTING : the pages routing is consistent and hierarchical
☐ SCSS : Each component is responsible of its look (not its parents)
☐ SCSS : No size calculations in typescript (only CSS for sizes)
☐ TESTS : tested with 360/375/414/768px of width
☐ TESTS : Unit tests written / updated
☐ ACCESSIBILITY : It works with bigger fonts

------------------------------- /MERGE REQUEST CHECKLIST -------------------------------

En espérant que ça vous soit utile,

Bon dev à tous et toutes !

Commentaires fermés

icon Flux RSS des commentaires de cet article

Les commentaires sont fermés pour cet article