Aller au contenu

Traitement des tickets

Il est prévu de présenter ce process sous forme de schéma.

Quel ticket prendre?

Dans le KanBan, on prend le ticket le plus haut et le plus à droite possible (ex : FYT-2198).
Cela correspond aux tickets prioritaires les plus avancés.

En flux normal

1. DEV TODO → DEV DOING

Depuis le ticket, on regarde dans les étiquettes attachées : l'une d'elles correspond à la branche d'origine (ex : fytorio-25-07-001). On clique sur "Créer une branche".

On fait attention à bien renseigner :

  • le bon Repository
  • le type (normalement pré-rempli)
  • la branche d'origine (from branch) en fonction de l'étiquette (ex : fytorio-25-07-001-fromMaster)

Le nom de la branche est normalement pré-rempli avec le nom et le titre du ticket (ex : FYT-2198-structure-daccueil-annuaire), mais on rajoutera en suffixe from[Nom de la branche d'origine].

Une fois la branche créée :

  • Le ticket avance automatiquement dans le KanBan Jira
  • Depuis Webstorm ou Phpstorm, on fait un fetch pour récupérer les branches

On fait notre développement.

Attention

Si on voit que le ticket Fytorio nécessite un ticket ANG, on ajoute une étiquette deploiementAngRequis pour qu'un ticket ANG soit créé en même temps.

Message de commit :

[NUMERO DU TICKET]
On explique nos modifications

Files
On liste les fichiers qu'on a modifié

On fait le commit, puis on retourne sur le ticket dans Jira et on clique sur "Faire une pull request".

Le nom de la branche destinataire est la branche qui nous a servi de base (ex : ang-25-07-001-fromMaster) avec forReview en plus (ex : ang-25-07-001-forReview-fromMaster).

Le titre de la Pull Request est le même que celui du ticket. On vérifie le titre, la description (qui reprend le contenu du message de commit), puis on clique sur "Créer la Pull Request".

Le ticket devrait avancer automatiquement de DEV - DOING à REVIEW - TO DO dans Jira.

2. REVIEW TODO → REVIEW DOING

On passe le ticket de la colonne REVIEW - TO DO à REVIEW - DOING.

On ouvre le ticket, on clique sur "1 pull request".

Deux façons possibles de faire la revue :

On examine le diff directement dans l'interface Bitbucket. On peut mettre des commentaires et proposer des modifications de code.

  1. On checkout sur la branche de destination
  2. On merge la branche du ticket sur la branche de destination pour voir les conflits

On vérifie le code qui a été changé / produit.

Si tout est ok

On clique sur "Approve", puis sur les … à côté pour faire le merge.

On passe le ticket manuellement de REVIEW - DOING à STAGING - TO DO dans le KANBAN

Si tout n'est pas ok

Corrections à apporter
  • On revient dans le kanban et on repasse le ticket à DEV - CORRECTION.
  • La personne qui a traité le ticket fait les modifications nécessaires avant de refaire une Pull Request, et le ticket repasse à REVIEW - TODO.
Conflits à résoudre

On retourne sur le ticket pour repérer sur quelle branche on est censé faire le merge (ex : fytorio-25-08-001-forReview-fromMaster).

Depuis WebStorm :

  1. On checkout sur cette branche
  2. On merge la branche du ticket dessus — WebStorm proposera de résoudre les conflits
  3. En fonction des conflits affichés, on aura peut-être besoin de contacter le développeur chargé du ticket

Une fois les conflits résolus, on push la branche fytorio-25-08-001-forReview-fromMaster.
Cela mettra la PR à jour (merged) et fera avancer le ticket à STAGING - TODO.

3. STAGING TODO → STAGING DOING

Dans le kanban, on passe le ticket de STAGING - TO DO à STAGING - DOING.

On checkout sur la branche staging

On merge la branche du ticket dans la branche staging en local :

  • S'il y a des conflits, on les traite
  • On vérifie que le projet se lance bien en local, on peut faire quelques tests
  • on change l'environnement d'exécution en "Start With StagingMongo" pour faire les tests connecté à la base staging.
  • On commit les changements produits par le merge
  • On push
  • On vérifie sur BitBucket que le build est passé
  • On lance le déploiement, toujours sur BitBucket, on vérifie qu'il se passe bien
  • On teste les différents éléments précisés dans le ticket, normalement sur le site staging en ligne.

Conseil

Plusieurs tickets peuvent se trouver en test en même temps sur staging.
Si les tests se révèlent compliqués du fait de la présence d'autres tickets en test,
Contente-toi de tes tests en local.

S'il y a quelque chose à corriger :

  • On met un commentaire sur le ticket en mentionnant le développeur
  • On passe manuellement le ticket en STAGING - CORRECTION

Si tous les tests sont ok, on passe manuellement le ticket de STAGING - DOING à QUALIF - TODO.

4. QUALIF TODO → QUALIF DOING

Rôle des PO

Les POs ne peuvent pas encore intervenir sur les tickets en QUALIF - TO DO. Ils doivent faire une demande
de "mise en qualif" en créant une release (ex : 1.59.0) et en listant les tickets à intégrer.

La demande est faite dans le canal Teams Agile / Pull request, avec le lien vers la release et les liens des tickets concernés.

Etape du process à valider en équipe

Est-ce que ce sont les développeurs qui crée la release lorsqu'il s'agit de tickets techniques (exemple : tickets de l'API) ou est-ce que c'est aussi les PO qui doivent la créer?

Étapes de mise en qualif :

  1. Depuis les repositories, aller sur les branches du projet.

    Exemple :
    branches

    Vérifier que la branche de release n'existe pas déjà dans Bitbucket (filtrer sur "all branches")

    branches

  2. Créer une branche de type release à partir de master (ex : fytorio-1.59.0-fromMaster)

on n'oublie pas de mettre fromMaster dans le nom de la branche

  1. Dans la release Jira, renseigner la "section name" : bitbucket, coller le lien vers la branche, et mettre son nom en signature Release Jira

  2. Revenir dans ton IDE, faire un fetch, et checkout sur la nouvelle branche

  3. On merge merge la branche de chaque ticket demandé dans la branche de release, on commit et on push
  4. Créer une Pull Request de 1.59.0 vers qualif
  5. S'il y a des conflits, les résoudre en local
  6. Lancer le projet en local pour vérifier que ça tourne
  7. Commit et push si ok
  8. On vérifie sur BitBucket que le build s'est lancé et est passé
  9. On lance le déploiement, toujours sur BitBucket, on vérifie qu'il se passe bien
  10. Coller le lien vers le déploiement dans le canal Teams Agile / Pull requests et signaler la livraison

À partir de là, les PO passeront les tickets concernés de QUALIF - TODO à QUALIF - DOING.

QUALIF - DOING -> QUALIF - CORRECTION

Si les POs constatent des bugs ou ont des retours à faire sur ce qui a été livré, ils passent le ticket en QUALIF - CORRECTION.

QUALIF - CORRECTION -> QUALIF - DOING
  • On fait les corrections sur la branche master ou sur la branche de version qui contenait le problème à résoudre.
  • On fait un cherry pick des corrections sur master ou sur la branche de version, sur qualif, éventuellement sur le ticket (pas obligatoire)..
  • On push les branches corrigées
  • les corrections seront déployées à la mise en prod suivante (cela peut être une mise en prod dédiée à cela si le problème est urgent)
  • une fois les corrections déployées, on passe le ticket en PROD - DOING pour que les POs soient notifiés et puissent tester les corrections.
5. PROD TODO → PROD DOING

Process à détailler

On utilise BitBucket pipelines pour les mises en production.

Quand une branche est proposée en prod, les POs font une publication dans la conversation Teams Agile / Général.

  • Le dev qui prend en charge met un pouce pour signaler qu'il s'en occupe
  • La branche de version de chaque projet concerné est mergée sur master
  • On passe à la phase Déploiement
  • Une fois la mise en production faite, il change l'icône par une checkbox cochée verte
  • Les PO peuvent alors procéder à leurs tests en prod
  • Si tout est ok, ils communiquent à l'opérationnel
  • si il y a des corrections à apporter, ils passent le ticket en PROD - CORRECTION
PROD - DOING -> PROD - CORRECTION
  • Les PO ont détecté un souci avec ce qui a été livré, ils passent le ticket en PROD - CORRECTION
PROD - CORRECTION -> PROD - DOING
  • On fait les corrections sur la branche master ou sur la branche de version qui contenait le problème à résoudre.
  • On fait un cherry pick des corrections sur master ou sur la branche de version, sur qualif, éventuellement sur le ticket (pas obligatoire)..
  • On push les branches corrigées
  • les corrections seront déployées à la mise en prod suivante (cela peut être une mise en prod dédiée à cela si le problème est urgent)
  • une fois les corrections déployées, on passe le ticket en PROD - DOING pour que les POs soient notifiés et puissent tester les corrections.

BugFix

On crée une branche mensuelle avec le numéro d'incrément, on crée la branche `forReview`, 
et ensuite on peut créer notre branche de ticket.

En urgence

1. Correctif sur staging

  • Soit retour après merge
  • Soit avant merge

On fait la correction, ensuite il faut la répercuter sur la branche du ticket (cherry-pick).

2. Correctif sur qualif

Notre ticket est forcément dans une branche de version, donc :

  1. On fait la correction sur la branche qualif
  2. On cherry-pick sur la branche de version
  3. On cherry-pick sur le ticket (non obligatoire)

C'est la branche de version qui sera envoyée en prod.

3. Bug prod urgent

  1. On fait la correction sur master
  2. On cherry-pick sur la branche de version

Début comme le flux normal :

  1. Création d'un ticket par PO ou JN
  2. Création de la branche du ticket, cette fois à partir de master
  3. On corrige, on commit et on push
  4. On retourne sur le ticket pour créer les pull requests :
    • vers qualif → on approuve et merge aussitôt
    • vers le dernier tag (ex : release/fytorio-1.45.0-fromMaster) → on approuve et merge aussitôt
  5. On crée une pull request du dernier tag vers master
Cas particulier — Ticket ANG : Modification de la base de données

Création d'une table

  1. Créer la classe de migration dans data/databases/migrationsMysql/mpec
  2. Créer l'entité correspondante dans module/Application/src/Phinx/Db/Mpec/Table
  3. Lancer la commande de migration :

```bash # Vérifier l'état actuel php vendor\bin\phinx status -e local -c .\phinxMysql.yml

# Lancer la migration php vendor\bin\phinx migrate -e local -c phinxMysql.yml ```

  1. Créer le service
  2. Créer la collection de requêtes correspondantes dans Postman

Ajout d'un champ dans une table

  1. Créer la classe correspondante dans data/databases/migrationsMysql/mpec/
  2. Vérifier si la classe de test pour cette table existe dans Tests/PhpUnit/Hydrator/RegisterVoucher/
    • Si elle existe, ajouter des tests en rapport avec les ajouts, et créer des données dans la méthode getDatabaseData()
  3. Si des contraintes sont à mettre, regarder du côté des Validateurs
  4. Lancer le script de mise à jour de la base

Erreur fréquente

Il se peut qu'on reçoive une erreur du type : Exception: Check configuration for fytorioSync, somethings is missing in C:\dev\src\mpec\nextgen\api-nextgen\module\Library\Mpec\Listeners\FytsyncListener.php:160

On repère alors la migration qui a planté (juste au-dessus dans la console) et on commente la ligne du type : php protected array $syncToLaunch = ["configurationsParamsTranslations"]; On relance la migration. Une fois terminée, on décommente les lignes commentées.

  1. Lancer le test : aller dans les configurations de debug, choisir "Edit", et sélectionner la classe à tester.