Lab 3.2 - Relire et merger la Pull Request d'un contributeur¶

Niveau : 3 Release Manager

Durée : ~25 min

Vous allez : relire le travail de quelqu'un d'autre, trouver ce que le robot n'a pas vu, demander une correction, et merger.

La situation¶

Mariia a une nouvelle story, US-052 - The Installation layout in two columns : les planificateurs font défiler la section Information de chaque installation pendant que sa deuxième colonne reste vide. Sa Pull Request est ouverte, ses contrôles sont verts, et elle vous attend.

Des contrôles verts veulent dire "ça se déploiera". Ils ne veulent pas dire "c'est juste". Décider du second est votre travail désormais, avant le merge, et c'est la part du métier de release manager qu'on ne peut pas automatiser. Une revue après le merge est un audit : la modification est déjà dans integration, et en route vers toutes les orgs qui suivent.

Avant de commencer¶

• Lab 3.1 terminé : quatre branches majeures, et l'authentification JWT sur preprod et main
• Une copie de travail propre

Les étapes¶

1. Recevoir la Pull Request de Mariia¶

Training: Level 3 > Simulate my teammates, depuis la Welcome page, et choisissez US-052 The Installation layout in two columns.

Cela ouvre sa Pull Request vers integration dans votre fork (votre copie personnelle du repository du cours sur GitHub, par exemple github.com/my-username/sfdx-hardis-training). Ouvrez-la depuis Pull requests, et attendez ses deux contrôles.

2. Lire le robot d'abord¶

Lisez le commentaire sfdx-hardis, de haut en bas. Quatre choses, dans cet ordre :

1. Est-ce que ça s'est déployé ? Le commentaire s'ouvre sur une bannière, Validation sur un job de contrôle et Deployment sur un job de merge, puis un verdict : ✅ Ready to merge into integration, ou ❌ Cannot merge into integration suivi de la raison, comme 1 deployment error. L'identifiant de déploiement Salesforce n'est affiché nulle part : il est porté par un marqueur HTML invisible, pour qu'un job de merge puisse réutiliser la validation en Quick Deploy
2. Combien est-ce que ça déploie ? La ligne Metadata du tableau Check | Result sous le verdict compte combien de composants changeraient, répartis en créés, mis à jour et supprimés, et combien ont été validés face à l'org. Plus bas, la section repliée 📋 ... components would change in the org donne ces changements par type de composant. Si les compteurs ne correspondent pas à la taille de la story, c'est votre signal pour aller lire le diff
3. Qu'est-ce que ça supprime ? Un compteur deleted sur cette même ligne, affiché seulement quand quelque chose disparaît, et la colonne 🗑️ Deleted du tableau, qui dit quel genre de composant disparaît : un champ, une classe, une présentation de page. Les Flows y sont comptés comme tout autre composant, et ont droit à une chose de plus : un commentaire de diff à eux, 🔀 Flow suivi de son libellé, publié en dessous pour chaque Flow modifié. Un Flow dont seul le statut change, activé ou désactivé, n'a pas de commentaire de diff et n'est nommé nulle part : lisez le diff pour ceux-là. Une section Flow deletion apparaît quand des versions sont retirées. Le commentaire ne nomme aucun autre composant supprimé : la liste, une ligne par composant, est dans les fichiers que le contrôle a gardés, et la fin de cette étape l'ouvre
4. Tests et couverture. La ligne Apex tests : la couverture face à l'objectif chaque fois qu'elle a été mesurée, ou pourquoi les tests n'ont pas tourné, et un bloc replié 🧪 Apex test classes quand le job a lancé des classes de test nommées. Les échecs seulement quand il y en a

Le lire dans cet ordre prend deux minutes. Sur US-052 il est vert, un petit nombre de composants mis à jour et rien de supprimé, et il a raison sur tout. Les compteurs exacts sont les vôtres, pas ceux du lab : ils comparent votre branche avec ce que contient votre helios-integration aujourd'hui, une story qui touche un fichier peut donc quand même mettre à jour quelques composants quand votre org est en retard. L'absence de deleted dans la ligne Metadata est ce qui compte ici, et c'est ce dont parle l'étape 4. Le commentaire vous dit aussi ce qu'il ne peut pas faire à votre place, et c'est l'étape 3.

La liste des composants, sans quitter VS Code. Le commentaire donne des compteurs, et le contrôle a gardé la liste. Ouvrez le panneau DevOps Pipeline et activez Show feature branches (1) : la branche de Mariia apparaît, avec le numéro de sa Pull Request à côté (2). Cliquez sur le numéro.

La fenêtre de la Pull Request s'ouvre. Sur son onglet Validation, cliquez sur Files (1), puis sur deployment-components.csv (2). Il s'ouvre dans VS Code : une ligne par composant du package, avec son Status, Created, Updated, Deleted ou Unchanged. Un composant supprimé y serait nommé. xls/deployment-components.xlsx, sur la ligne suivante, est la même liste pour un tableur.

Votre numéro n'est pas #64. Si la fenêtre n'a pas de bouton Files, votre sfdx-hardis est plus ancien que la fonctionnalité : Open job mène aux mêmes fichiers sur GitHub, dans le Summary de l'exécution, sous Artifacts, sfdx-hardis reports.

3. Lire le diff, en cherchant ce que le robot ne peut pas voir¶

Le robot vérifie que le déploiement fonctionne. Il ne peut pas vérifier que le déploiement est une bonne idée.

Cliquez sur Files changed (1). L'arbre de fichiers à gauche liste ce que la story a touché : un fichier, la présentation de page (2). Une ligne supprimée est marquée (3) : laissez-la pour l'instant, l'étape 4 en parle.

Parcourez le diff avec quatre questions :

4. Trouver ce que le robot a manqué¶

Le diff de la présentation de page a trois modifications. Deux vont ensemble : Crew_Capacity_Cap__c quitte la première colonne, et revient dans la seconde. C'est la story.

La troisième est un bloc supprimé (3) sur l'image de l'étape 3, et rien ne le remet : Total_Capacity_kW__c. À lire vite, cela ressemble à une partie du déplacement. Relisez : la capacité installée n'a pas été déplacée dans la deuxième colonne, elle a quitté la présentation de page.

Rien n'échoue. Le champ existe toujours, le contrôle de déploiement est vert. Mais une fois cela mergé, plus personne ne voit de capacité sur un enregistrement d'installation, et la première personne à le remarquer sera celle qui lit ce nombre un lundi matin.

Comparez ensuite avec ce qu'a écrit Mariia. La description dit the crew capacity cap moves to the second column. Elle ne dit rien d'un champ qui s'en va. C'est l'écart auquel sert une revue : le diff dit une chose, la description une autre, et une seule des deux est ce qui sera déployé.

Rien dans la pipeline ne peut attraper cela. Une présentation de page avec un champ de moins est un déploiement valide, la ligne Metadata compte la présentation comme un composant updated de plus, et seul quelqu'un qui connaît l'org peut voir ce qui manque.

5. Demander la correction, sur la ligne¶

Survolez la ligne où Total_Capacity_kW__c est supprimé, cliquez sur le + bleu qui apparaît, et commentez :

Total_Capacity_kW__c comes off the layout with this change, and the description does not say so. I think it went missing with the move: can you put it back in the second column, under the cap, read only?

Puis Review changes en haut à droite de l'onglet, Comment, Submit review. Sur un vrai projet vous choisiriez Request changes, qui maintient le bouton Merge honnête jusqu'à ce que l'auteur réponde. GitHub le cache ici parce que les Pull Requests de collègues de ce cours sont ouvertes depuis votre propre compte, et que personne ne demande de corrections à soi-même.

Deux choses à copier dans ce commentaire :

• Il dit pourquoi, pour que le lecteur puisse juger plutôt que de vous croire sur parole
• Il dit ce qui se passe ensuite, pour que personne n'ait à demander

Ne mergez pas. Le bouton Merge est vert, et il a tort.

6. Relire la correction, puis merger¶

La correction revient à Mariia : un release manager relit et merge les Pull Requests des contributeurs, et n'écrit pas leurs fonctionnalités. Elle répond le lendemain matin, sur la même branche. Training: Level 3 > Simulate my teammates, et choisissez US-052 Mariia puts Total Capacity back, beside the cap.

Cela ajoute un commit à sa branche, la même Pull Request se met donc à jour, et ses contrôles retournent. Rouvrez Files changed : GitHub propose de n'afficher que les modifications depuis votre revue, et il y en a une, Total_Capacity_kW__c ajouté dans la deuxième colonne, en lecture seule, sous le plafond. Le diff entier de la Pull Request déplace maintenant deux champs dans la deuxième colonne, le plafond et la capacité installée, désormais en lecture seule, et n'en retire aucun.

Quand les contrôles sont verts, mergez avec Squash and merge, comme pour toute Pull Request de feature (Lab 1.6) : les deux commits deviennent une ligne dans l'historique d'integration, titrée comme la Pull Request. Sur un vrai projet, c'est ici que vous cliquez d'abord sur Approve.

7. Voir la branche disparaître¶

La ligne sous le merge dit que la branche a été supprimée : votre fork le fait pour chaque Pull Request mergée, et votre vrai projet devrait en faire autant (Settings > General > Automatically delete head branches). Les branches majeures ne risquent rien, parce qu'une branche protégée ne peut pas être supprimée.

sf hardis:project:deploy:smart --check

Ce que vous devez voir¶

• Votre commentaire de revue sur la Pull Request de Mariia, sur la ligne qui supprimait Total_Capacity_kW__c
• Sa correction dans la même Pull Request, et la Pull Request mergée en squash dans integration
• La présentation de page Installation dans integration avec le plafond et Total_Capacity_kW__c dans la deuxième colonne

Vérifiez votre travail¶

Welcome page > Training: Level 3 > Check my work, puis choisissez le Lab 3.2.

Pour aller plus loin¶

• Relire et merger les Pull Requests
• Lire les résultats de la Pull Request

Suite : Lab 3.3 - Lire le log de déploiement, et ce que .forceignore lui cache

Questions and comments