Relire ce qui est revenu

Le batch a tourné. De retour sur la Roadmap du workshop, les versions qu'il a construites sont terminées, et la dernière est en attente de revue : l'agent a fini et attend après vous.

C'est l'étape que les gens sautent, et c'est celle qui décide si le tour suivant sera court ou pénible. Relire, ce n'est pas lire un diff. C'est utiliser l'app et enregistrer ce qui cloche là où ça cloche.

Deux suites possibles, et on choisit exprès. Soit vous corrigez dans la version encore ouverte, soit vous clôturez la version et vous faites une vraie recette sur l'app entière.

Ouvrez la version qui attend

Cliquez sur la version en attente de revue dans la roadmap. Vous arrivez à l'intérieur, à l'étape Development, avec la conversation de l'agent à gauche et l'espace de travail à droite.

L'aperçu de cet espace, c'est votre app telle que cette version l'a construite. Parcourez les écrans que la version devait livrer, connectez-vous avec un compte de test, chargez les données d'exemple, et comportez-vous comme la personne à qui l'app est destinée.

Enregistrez ce qui cloche, depuis l'app

Le bouton flottant M dans l'aperçu est tout l'intérêt de l'exercice.

Démarrez une session et le widget capture la page, l'élément cliqué et les erreurs vues par le navigateur : le rapport porte son propre contexte. Une note qui dit le champ IBAN accepte un format invalide avec l'écran joint vaut dix notes écrites de mémoire une heure plus tard. Voir Utiliser le widget Maleus dans la preview.

Chemin un : corriger dans la version ouverte

Tout ce que vous venez d'enregistrer est déjà rattaché à cette version. L'onglet Reviews, en haut à droite de la version à côté de Preview, est l'endroit où vous le relisez.

Choisissez une revue, lisez les notes et la trace, puis passez-la avec Process with agent. L'agent est toujours dans la version, il en a encore le contexte, et il corrige sur place. Rien n'est remis en file, rien n'est reconstruit depuis zéro.

C'est le bon chemin tant que la version est ouverte et que les problèmes sont circonscrits : un mauvais libellé, une validation cassée, une mise en page qui saute sous la ligne de flottaison.

Chemin deux : clôturer, puis faire la recette

Quand la version vous convient, marquez-la Done. Elle passe dans Ready to Deploy sur la liste des versions.

Testez maintenant l'app entière, pas seulement le périmètre d'une version. App Preview, dans la sidebar du projet, fait tourner votre app en dehors de toute version : le même navigateur d'aperçu, sans agent ni étape rattachés. C'est la façon honnête de regarder, parce que vous utilisez la chose au lieu de la regarder se construire. Voir Ouvrir votre app sans version.

Enregistrez ce que vous trouvez avec le même widget. Ces revues atterrissent dans App Reviews au niveau du projet, rattachées à aucune version.

Lisez-les, puis décidez, avec les deux boutons de l'en-tête :

Create workshop transforme la recette en travail : la session s'ouvre avec ces revues en entrée, vous en discutez, et vous en ressortez avec un nouveau pipeline de versions. Maleus le suggère de lui-même quand la pile monte : cela fait beaucoup de revues pour une seule version, un workshop peut répartir les corrections sur plusieurs versions.

C'est comme ça que démarre le tour deux, et c'est la même étape deux que vous avez déjà faite. Voir Trier les revues d'app.

Promouvez ce qui est bon

Une version qui vous convient avance. Depuis Versions, celles qui sont sous Ready to Deploy portent une action Promote to : choisissez une target de déploiement et leur code est poussé sur cette branche. Surveillez-la ensuite depuis la page Deployments. Voir Déployer une version.

C'est la boucle

Projet, workshop, batch, revue, et retour au workshop. Vous en avez fait un tour.

À partir d'ici, le reste de la documentation entre dans le détail de chaque surface : ce qui se passe dans une version, les scores d'audit, et les réglages qui survivent aux versions.