Introduction
Moss & Mallow est une boutique de cadeaux de quartier fictive. Sa nouvelle collection de kits de semences doit conserver la remise par lot et les règles de livraison existantes. La boutique fonctionne déjà, mais le Pipeline Jenkins fourni peut publier une version candidate même lorsqu’un véritable test de calcul des prix échoue.
Vous lirez les détails de cet échec, relierez l’état du build Jenkins à la décision de publication et publierez la version candidate qui fonctionne. Ce lab suppose que vous connaissez la navigation de base dans Jenkins et savez reconnaître un court Pipeline déclaratif. Il explique les nouveaux paramètres du rapport de tests et du contrôle de publication ; aucune programmation applicative, installation, compte cloud ou achat réel n’est nécessaire.
Utilisez Gift Shop pour le parcours client et Jenkins pour la configuration et les builds. Il s’agit de deux services dans une même machine virtuelle préparée. Les deux versions candidates, broken et fixed, sont des versions de test fournies. Chaque unité démarre de manière indépendante. La durée estimée comprend la lecture et les erreurs courantes ; elle n’a pas été mesurée auprès de débutants.
Observer ce qu’un test en échec arrête réellement
Dans cette étape, vous comparerez les prix normaux à un véritable test en échec et découvrirez pourquoi un build Jenkins instable peut tout de même publier une version. Commencez dans Gift Shop.
Choisissez Find a little gift, ou Shop dans la navigation. Un kit de semences coûte £12. À partir de trois kits, une remise par lot de 10 % s’applique. La livraison coûte £4 et devient gratuite lorsque le montant des marchandises atteint au moins £40. Les prix sont des estimations ; la boutique n’accepte aucun paiement.
Réglez la Quantity des kits de semences sur 3 et choisissez Check basket. Le montant normal des marchandises est de £32.40, la livraison de £4.00 et le total de £36.40. Utilisez Shop pour revenir à la boutique. Vérifiez également deux coffrets pique-nique : les marchandises coûtent £40.00 et la livraison est gratuite. Ouvrez Visit, téléchargez la fiche d’entretien des semences et lisez le fichier texte enregistré. Ces fonctionnalités normales doivent rester disponibles à la fin.
Une version candidate est une version dont on envisage la publication. Un build est une exécution de Jenkins, avec son propre numéro, ses paramètres et son résultat. Passez à l’onglet Jenkins. Ouvrez shop-update, puis choisissez Build with Parameters. Laissez RELEASE sur broken et choisissez Build. Cette première exécution publie volontairement une version candidate incorrecte destinée à la formation afin que vous puissiez observer le problème ; aucun véritable client n’est concerné.
Attendez la fin du build. Ouvrez son entrée numérotée sous Builds, puis Console Output. Le Pipeline comporte trois étapes : Prepare copie la version candidate choisie dans l’espace de travail du build, Test exécute les vérifications de prix fournies et Publish transmet le paquet à la boutique.
La console doit contenir les lignes suivantes, dont le texte reste constant :
Pricing failures: 1
Release received
Finished: UNSTABLE
UNSTABLE signifie que le build présente un problème de qualité, par exemple des tests en échec. Cet état n’empêche pas, à lui seul, toutes les étapes suivantes de s’exécuter. Release received montre que ce Pipeline a tout de même effectué la publication.
Ouvrez Tests pour ce build. Ouvrez le test seed_bundle en échec et lisez les détails de son échec :
Expected 3240 400; got 2880 400
Les valeurs sont exprimées en pence : le test attendait £32.40 de marchandises et £4 de livraison, mais la version candidate a calculé £28.80 de marchandises. Les trois autres tests ont réussi. Ces résultats proviennent de l’exécution du véritable programme de calcul des prix de la version candidate ; le rapport XML est généré à partir de ces comparaisons.
Passez à Gift Shop, utilisez Shop et vérifiez à nouveau trois kits de semences. Actualisez la page si nécessaire. Le total incorrect est maintenant de £32.80. Vous avez observé une véritable publication erronée, au-delà d’une simple couleur d’avertissement. Revenez au build Jenkins numéroté avant d’utiliser la vérification de cette étape.
Relier le résultat des tests à la publication
Dans cette étape, vous modifierez le Pipeline afin qu’un test en échec reste visible et empêche l’étape Publish de s’exécuter. Commencez dans Jenkins et ouvrez la page du job shop-update à l’aide de son lien dans le fil d’Ariane.
Choisissez Configure, puis la section Pipeline. Son éditeur Script contient un Pipeline déclaratif. agent any sélectionne un exécuteur Jenkins disponible ; dans cet environnement d’introduction préparé, il s’exécute à l’intérieur du conteneur du contrôleur. Un espace de travail est le répertoire alloué à ce build. Un autre projet enseigne l’utilisation d’agents indépendants.
Lisez l’étape Test. La ligne fournie sh returnStatus: true, script: ... exécute le script de tests et renvoie son code de sortie au lieu de déclencher immédiatement une erreur du Pipeline. Cela permet à l’étape junit suivante de publier les détails des tests. Un code de sortie égal à zéro signifie que le script a réussi ; un code non nul signifie qu’il a échoué. junit lit le fichier XML de résultats, rattache les tests à ce build et lui attribue normalement l’état UNSTABLE lorsqu’un test échoue.
Une option de Pipeline modifie la manière dont Jenkins exécute le Pipeline. Ajoutez la ligne suivante immédiatement après agent any. Les accolades regroupent l’option ; conservez l’accolade ouvrante et l’accolade fermante exactement comme indiqué.
options { skipStagesAfterUnstable() }
Le début du script doit maintenant ressembler à ceci. Conservez toutes les autres lignes existantes, y compris l’adresse du destinataire et les étapes Prepare, Test et Publish fournies.
pipeline {
agent any
options { skipStagesAfterUnstable() }
Cette option ignore les étapes suivantes une fois que le build devient instable. Elle ne transforme pas un test en échec en test réussi. Conservez l’instruction standard de publication du rapport :
junit testResults: 'reports/pricing.xml'
Conservez les appels shell fournis pour copier la version candidate, exécuter test-shop.sh et publier le paquet. Le rapport de tests doit provenir de cet exécuteur de tests ; ne le remplacez pas par une étape qui écrit un rapport et n’ajoutez pas d’autres commandes shell.
N’ajoutez pas skipMarkingBuildUnstable: true : ce paramètre supprime l’état du build sur lequel repose ce contrôle de publication. Ne supprimez pas de tests, ne modifiez pas les prix qu’ils attendent, n’altérez ni les versions candidates fournies ni le mécanisme de publication et ne sautez pas la publication pour toutes les versions candidates.
Choisissez Save. Sélectionnez Build with Parameters, conservez broken et choisissez Build. Attendez la fin du nouveau build numéroté. Ouvrez Console Output. Cette fois, vous devez voir :
Pricing failures: 1
Stage "Publish" skipped due to earlier stage(s) marking the build as unstable
Finished: UNSTABLE
Ouvrez Tests. Le même test en échec et les trois tests réussis doivent toujours être présents. Le nouveau build ne doit pas contenir Release received. La boutique peut encore afficher la mauvaise version publiée précédemment : bloquer une nouvelle tentative ne rétablit pas automatiquement l’état antérieur à une publication précédente. Vous la remplacerez ensuite par la version candidate qui fonctionne.
Si le build signale plutôt une erreur de syntaxe Groovy, ouvrez de nouveau Configure. Vérifiez que la ligne options ajoutée se trouve à l’intérieur de pipeline, juste sous agent any, avec des accolades équilibrées. Corrigez-la, choisissez Save et relancez broken. Une simple erreur de syntaxe ne suffit pas à terminer cette étape. Jenkins affiche parfois un message du composant de publication Checks API ; ce cours local n’utilise pas de service Git hébergé, donc ce message ne remplace pas le véritable résultat des tests.
Publier la version candidate qui fonctionne
Dans cette étape, vous démontrerez que le même Pipeline peut livrer une mise à jour correcte tout en préservant le parcours client normal. Commencez sur la page du job shop-update dans Jenkins.
Choisissez Build with Parameters. Réglez RELEASE sur fixed, puis choisissez Build. Vous sélectionnez ainsi la version candidate fonctionnelle fournie ; cela ne modifie pas le Pipeline que vous venez de tester. Attendez la fin de l’exécution et ouvrez Console Output pour le nouveau build.
Pricing failures: 0
Release received
Finished: SUCCESS
Ouvrez Tests. Les quatre tests de calcul des prix doivent réussir. Revenez à la page d’état de ce build et repérez Build Artifacts. Téléchargez shop-release.tar.gz. Un artefact est un fichier conservé par Jenkins pour ce build ; cette archive compressée contient le programme de calcul des prix, les métadonnées de la version et la fiche d’entretien. Cette archive est aussi le véritable paquet envoyé à la boutique, et non une copie reconstruite séparément.
Passez à Gift Shop, choisissez le lien de la marque pour revenir à l’accueil et actualisez la page. La collection porte maintenant le nom Gifts to grow together. Ouvrez Shop et vérifiez trois kits de semences : marchandises £32.40, livraison £4.00, total £36.40. Deux coffrets pique-nique doivent toujours bénéficier de la livraison gratuite. Ouvrez Delivery et Visit, téléchargez de nouveau la fiche d’entretien et confirmez qu’elle est complète.
La vérification finale relie les véritables builds en échec et réussis au Pipeline actuellement enregistré et aux octets déployés. Si vous modifiez le Pipeline après ces exécutions, relancez broken, puis fixed, afin que les deux résultats correspondent à la version que vous soumettez. Conservez les builds précédents et les ressources d’origine de la boutique ; il n’est pas nécessaire d’écrire un rapport ni de copier la sortie de la console dans un fichier.
Si vous avez de nouveau sélectionné broken par erreur, laissez le contrôle de publication en place et exécutez fixed. Si Jenkins exécute encore le build, attendez le résultat final du build numéroté au lieu d’en soumettre d’autres à répétition. Une page d’accueil fonctionnelle ne suffit pas à elle seule : les prix du panier et le téléchargement font partie du travail à terminer.
Résumé
Vous avez observé un véritable test de calcul des prix en échec, compris pourquoi un build instable publiait tout de même une version et relié le résultat des tests Jenkins à un contrôle de publication. Vous avez ensuite utilisé le même Pipeline pour livrer la version candidate fonctionnelle et vérifié les prix réels, le paquet archivé et les fonctionnalités normales de la boutique.
