Réunion octobre CI

CI/CD

Évolution des méthodes

Suivant >

>

>

// Rappel

nov

oct

26 juil

Août

2 sept

19 juil

Mise en place des protections

core & common

Prise en main des méthodes

Prise en main des nouvelles méthodes

Procédures de test et validation

Coordination / mise en place Pierre

>

<Pourquoi tester ?>

Plus une anomalie est détectée tôt, moins les impacts financiers sont importants

Un regard extérieur est toujours plus efficace sur des développements qui peuvent être longs

Confiance et crédibilité : détecter les anomalies avant la mise en production permet de minimiser l'insatisfaction client

Le testeur est garant de la qualité du produit livré : moins de responsabilité sur le développeur

Utilisation d'un logiciel de test permet d'avoir un périmètre de test défini et de produire des livrables

>

>

// Tests automatisés et manuels

Tests automatisés : Scripts sans humain, exécutables à l'infini Tests manuels : Étapes prédéfinies suivies par un testeur qui interagit avec l'application

Définition

Tests automatisés : Rapides en exécution mais lents en rédaction Tests manuels : Lents en exécution mais rapides en rédaction

Rapidité

Tests automatisés : Plus coûteux initialement, rentable à long termeTests manuels : Moins coûteux à court terme, moins rentable à long terme

Coût

>

// Fonctionnement actuel

Remontée d'anomalies par le client

MR/PR

Livraison

DEV

Réunion

>

// Fonctionnement prévu

Remontée d'anomalies

MR/PR

DEV

Livraison

Tests

Cahier des charges

Rédaction des tests

>

// DISCLAIMER

HOTFIX

Les problèmes bloquants gardent leur procédure spécifique simplifiée et ne sont pas totalement concernés par les procédures suivantes.

// Workflow de travail

1. Rédaction du cahier des charges
2. Définition des impacts/risques que peuvent causer cette fonctionnalité
3. Création d'une branche à partir de preprod => Développeur/Intégrateur
4. Développement et commits sur cette branche
5. Pull ou rebase à partir de preprod
6. Ouverture de la MR/PR
7. Code review => Responsable dev.
8. Tests manuels et/ou automatisés => Testeur
9. Déploiement sur preprod => Responsable dev.
10. Planification
11. Déploiement en production

>

// Workflow YouTrack

>

Prêt audéploiement

Création ticket

DEV.

CODE REVIEW

TESTS

Déploiement

A TESTER @acourciere

OUVERT @acourciere

A TESTER @pmoirez

EN COURS @dev/inté

VÉRIFiÉ @acourciere

TERMINÉ

>

>

<Bonnes pratiques de développement>

Chaque ticket YouTrack doit avoir un périmètre de test : chaque développeur doit indiquer clairement ce qui peut être impacté par ses modifications et ce qu'il faut tester Chaque développeur doit tester un minimum le code produit Rédaction des MR : il faut être rigoureux dans leur rédaction. Le but n'étant pas de perdre du temps à relire l'intégralité des (longs) tickets pour comprendre de quoi on parle. Tout ce qui n'est pas indiqué dans la MR ne sera pas pris en compte (tests, vérifications, etc). Nomenclature des commits : [change] [ME-152] Modification du pictogramme d'envoi FTP

>

>

<Bonnes pratiques de tests>

La version à tester doit être identifiée (versionning via les numéros de commit des versions de core/common/default et du site testé) La version à livrer au client doit être la dernière testée Ce sont des tests itératifs, ce qui est déjà passé en OK ne sera pas re-testé, à part pour le sanity Création d'un sanity qui retrace un parcours utilisateur classique et qui sera passé en dernière itération (peut être remplacé par les tests auto) Rédactionnel/traduction : les procédures de validation ne sont pas garantes des textes et des éventuelles fautes d'orthographe. Si elles sont détectées, elles sont bien sûr remontées Tout ne peut pas être testé à 100% : il y aura forcément des choses hors périmètre. Il faut trouver le bon ratio entre tests manuels et tests automatisés

>

// Bilan

>

Planification et tests : plus de qualité, moins de clients impactés Une branche = une fonctionnalité/un bug/un changement Tous les tickets de développement entrants assignés au Resp Dev. pour planification Tous les tickets de développement terminés assignés au Resp Dev. pour revue + planif des tests Une planification efficace évite les retards de livraison et préserve une bonne qualité La qualité de la V3 se joue dès maintenant sur l'adoption de ces bonnes pratiques

>

>

On a besoin de vous pour une meilleure qualité !

Des Questions ?