Lab 1.3 - Démarrer une User Story sur sa propre branche Git¶

Niveau : 1 Contributeur, les bases

Durée : ~10 min

Vous allez : prendre votre premier ticket et atterrir sur une branche propre, pointée vers votre org de dev.

La situation¶

Le backlog est dans BACKLOG.md. Votre première story est tout en haut :

US-014 - Show the crew how many panels a job needs

As a delivery crew member, I want to see the number of panels required on the installation record, so that I load the right quantity on the van.

Critères d'acceptation :

• Un champ Panels Required existe sur Installation
• Il est visible pour le permission set de l'équipe de pose
• Les planificateurs peuvent le renseigner
• Il apparaît sur la page d'enregistrement Installation

Petite exprès. Ce qui compte dans ce lab n'est pas le champ, c'est la boucle que vous êtes sur le point d'apprendre et de répéter pendant tout le reste de votre carrière sur ce projet.

Avant de commencer¶

• Lab 1.2 terminé : votre fork (votre copie personnelle du repository du cours sur GitHub, par exemple github.com/my-username/sfdx-hardis-training) est cloné, et integration et uat nomment leurs orgs
• helios-dev listée comme Connected dans Orgs Manager

Les étapes¶

1. Démarrer la User Story¶

Sur la Welcome page, ouvrez le panneau DevOps Pipeline et faites défiler au-delà du diagramme jusqu'au Project Contribution Workflow (1). Cliquez sur la carte New User Story (2).

L'extension pose quatre questions, un écran à la fois. Chacune apparaît dans son propre panneau, et chaque réponse que vous donnez reste visible au-dessus de la question suivante : vous voyez donc toujours ce que vous lui avez dit. Avant la première, elle vous dit quelque chose au lieu de demander.

2. Où va le travail¶

La première ligne sous l'en-tête indique Automatically selected target branch is integration (1). Ce n'est pas une question, parce qu'il n'y a rien à choisir : ce projet déclare integration comme seule branche qu'un contributeur a le droit de cibler, dans availableTargetBranches. Le Lab 3.1 ajoute preprod, là où démarrent les correctifs urgents, et à partir de là la commande demande, en proposant les deux. Sous cette ligne, la première vraie question attend déjà. Deux de ses réponses, (2) et (3), sont celles entre lesquelles vous choisissez : l'étape suivante parle d'elles.

Vous ne devinez jamais où va votre travail : la commande le dit d'abord, l'écrit, et chaque étape suivante le relit.

3. De quel genre de travail il s'agit¶

What type of User Story do you want to create? Prenez Feature: a new capability or an improvement (2) : US-014 ajoute quelque chose qui n'était pas là. Fix: correct something that is broken (3) sert à corriger quelque chose de déjà livré. Les deux réponses sont formulées par ce projet, dans branchPrefixChoices.

La troisième réponse, Retrofit, est celle du release manager. Elle fait redescendre un hotfix de production dans la pipeline, et le Lab 3.7 est l'endroit où elle sert. Ici, n'y touchez pas.

La réponse devient la première partie du nom de votre branche, features/ ou fix/, pour que quiconque regarde la liste des branches voie d'un coup d'œil quel genre de travail est en cours.

4. Comment l'appeler¶

What is the name of your new User Story? Tapez-le dans la zone (1) et cliquez sur Validate (2) :

US-014-panels-required

L'exemple grisé à l'intérieur de la zone n'est pas de la décoration : ce projet déclare un motif auquel les noms doivent correspondre, et l'exemple est un nom qui y correspond. Tapez autre chose, Panels Required par exemple, et la commande vous dit ce qu'elle attendait et redemande.

5. L'org dans laquelle vous allez construire¶

Which Salesforce org do you want to work in? Prenez Scratch org (1) : helios-dev en est une, créée au Lab 1.2.

Les autres réponses sont pour d'autres projets. Sandbox org with source tracking (2) est ce qu'utilisent la plupart des équipes, une sandbox de développeur distribuée par le release manager. Le source tracking veut dire que l'org tient à jour une note de ce qui y a changé depuis votre dernière synchronisation, ce qui vous évite de chercher. Current org (3) désigne l'org vers laquelle votre projet pointe, par son adresse : c'est helios-dev aujourd'hui, mais une adresse ne vous dit rien, ne comptez donc pas dessus. La dernière réponse sert à éditer directement les fichiers du projet, sans org du tout.

Puis la liste des orgs qu'elle pourrait attacher. Prenez Reuse scratch org helios-dev (1).

C'est l'org que le Lab 1.2 a remplie avec l'application Helios, et celle que vous allez modifier à la main dans Setup. La liste ne propose ni helios-integration ni helios-uat : la commande sait que ces deux-là appartiennent à des branches majeures, et construire directement dans une org partagée est exactement ce que toute cette façon de travailler existe pour empêcher.

La réponse du milieu, Reuse current org, atterrirait sur la même org ici, par son adresse plutôt que par son nom. Prenez celle qui est nommée : une adresse ne vous dit rien sur l'org dont il s'agit.

6. Lire ce qu'elle vous dit à la fin¶

La commande ouvre helios-dev dans votre navigateur : vous pouvez laisser cet onglet pour le Lab 1.4. Puis elle se termine et affiche ce qu'elle a fait. Lisez-le plutôt que de le fermer.

• la branche qu'elle a créée et sur laquelle elle vous a basculé (1)
• la confirmation que vous êtes prêt à travailler dessus (2)
• l'org qu'elle a attachée à cette User Story, par nom d'utilisateur et par URL (3)

Ces trois lignes méritent un coup d'œil à chaque fois. Un nom de branche qui n'est pas celui que vous attendiez, ou une org qui n'est pas celle que vous vouliez, c'est un problème qui coûte trente secondes maintenant et un après-midi plus tard.

sf hardis:work:new

branchPrefixChoices:
  - value: features
    title: "Feature: a new capability or an improvement"
  - value: fix
    title: "Fix: correct something that is broken"
newTaskNameRegex: '^US-\d{3}-[a-z0-9-]+$'

Ce que vous devez voir¶

Trois choses, toutes visibles sans quitter VS Code :

1. En bas à gauche de la barre d'état : la branche est maintenant features/US-014-panels-required
2. Le panneau sfdx-hardis, section Status : Current Org nomme la scratch org que vous avez choisie. Il affiche le nom propre de l'org, celui que Salesforce a inventé, et non l'alias helios-dev : vérifiez donc le nom d'utilisateur plutôt que de chercher l'alias que vous connaissez
3. Le panneau DevOps Pipeline : integration et uat, inchangés. Votre nouvelle branche n'y est pas, et c'est normal. Le diagramme dessine les branches majeures et les Pull Requests ouvertes vers elles, et votre branche n'a encore ni Pull Request ni org à elle. Elle apparaîtra au Lab 1.6, au moment où vous ouvrirez la Pull Request

Si les deux premières se contredisent, arrêtez-vous et corrigez-le maintenant plutôt qu'après avoir construit quelque chose.

Vérifiez votre travail¶

Welcome page > Training: Level 1 > Check my work, puis choisissez le Lab 1.3.

Il cherche votre branche de story, features/US-014-..., la seule chose que ce lab laisse derrière lui. Votre travail n'a pas encore atteint integration, et rien ici ne s'y attend : c'est le Lab 1.6.

Pour aller plus loin¶

• Démarrer une User Story
• La boucle du contributeur en une page

Suite : Lab 1.4 - Construire un champ personnalisé dans votre org Salesforce

Questions and comments