Einführung
Moss & Mallow ist ein fiktiver Geschenkladen in der Nachbarschaft. Bei seiner neuen Kollektion von Saatgutsets sollen der bisherige Mengenrabatt und die bestehenden Versandregeln erhalten bleiben. Der Shop funktioniert bereits, doch die bereitgestellte Jenkins-Pipeline kann eine für die Veröffentlichung vorgesehene Version auch dann veröffentlichen, wenn ein echter Test der Preisberechnung fehlschlägt.
Du liest die tatsächliche Fehlermeldung des Tests, verknüpfst den Jenkins-Buildstatus mit der Entscheidung über die Veröffentlichung und veröffentlichst die funktionierende Version. Dieses Lab setzt grundlegende Kenntnisse der Navigation in Jenkins voraus sowie die Fähigkeit, eine kurze Declarative Pipeline zu erkennen. Es erklärt die neuen Einstellungen für Testberichte und die Freigabebedingung; Anwendungsprogrammierung, Installation, ein Cloudkonto oder ein echter Einkauf sind nicht erforderlich.
Verwende Gift Shop für den Ablauf aus Kundensicht und Jenkins für Konfiguration und Builds. Dies sind zwei Dienste in einer vorbereiteten VM. Die beiden Kandidaten broken und fixed sind bereitgestellte Testversionen. Jede Einheit beginnt unabhängig. Die geschätzte Dauer berücksichtigt das Lesen und gewöhnliche Fehler; sie wurde nicht mit Anfängern gemessen.
Prüfe, was ein fehlgeschlagener Test tatsächlich stoppt
In diesem Schritt vergleichst du die normalen Preise mit einem echten fehlgeschlagenen Test und erfährst, warum ein instabiler Jenkins-Build trotzdem veröffentlichen kann. Beginne in Gift Shop.
Wähle Find a little gift oder Shop in der Navigation. Ein Saatgutset kostet £12. Ab drei Saatgutsets gilt ein Mengenrabatt von 10 %. Der Versand kostet £4 und ist ab einem Warenwert von £40 kostenlos. Die Preise sind Schätzwerte; der Shop nimmt keine Zahlungen entgegen.
Setze Quantity für das Saatgutset auf 3 und wähle Check basket. Der normale Warenwert beträgt £32.40, der Versand £4.00 und die Gesamtsumme £36.40. Kehre über Shop zurück. Prüfe auch zwei Picknickboxen: Der Warenwert beträgt £40.00 und der Versand ist kostenlos. Öffne Visit, lade die Pflegeanleitung für das Saatgut herunter und lies die gespeicherte Textdatei. Diese normalen Funktionen müssen auch am Ende verfügbar sein.
Ein Kandidat ist eine Version, die für eine Veröffentlichung infrage kommt. Ein Build ist eine einzelne Ausführung in Jenkins mit eigener Nummer, eigenen Parametern und eigenem Ergebnis. Wechsle zum Tab Jenkins. Öffne shop-update und wähle dann Build with Parameters. Belasse RELEASE auf broken und wähle Build. Dieser erste Durchlauf veröffentlicht absichtlich einen fehlerhaften Übungskandidaten, damit du das Problem beobachten kannst; echte Kunden sind davon nicht betroffen.
Warte, bis der Build abgeschlossen ist. Öffne seinen nummerierten Eintrag unter Builds und anschließend Console Output. Die Pipeline hat drei Stages: Prepare kopiert den gewählten Kandidaten in das Arbeitsverzeichnis des Builds, Test führt die bereitgestellten Prüfungen der Preisberechnung aus und Publish liefert das Paket an den Shop aus.
Die Konsole sollte diese feststehenden Zeilen enthalten:
Pricing failures: 1
Release received
Finished: UNSTABLE
UNSTABLE bedeutet, dass der Build ein Qualitätsproblem hat, etwa fehlgeschlagene Tests. Dieser Status allein verhindert nicht jede spätere Stage. Release received zeigt, dass diese Pipeline die Veröffentlichung trotzdem ausgeführt hat.
Öffne Tests für diesen Build. Öffne den fehlgeschlagenen Test seed_bundle und lies die Fehlerdetails:
Expected 3240 400; got 2880 400
Die Werte sind in Pence angegeben: Der Test erwartete £32.40 Warenwert und £4 Versand, doch der Kandidat berechnete einen Warenwert von £28.80. Die anderen drei Tests wurden bestanden. Diese Ergebnisse entstehen durch die Ausführung des tatsächlichen Preisberechnungsprogramms des Kandidaten; der XML-Bericht wird aus diesen Vergleichen erzeugt.
Wechsle zu Gift Shop, öffne Shop und prüfe erneut drei Saatgutsets. Lade die Seite bei Bedarf neu. Die fehlerhafte Gesamtsumme beträgt jetzt £32.80. Du hast eine tatsächlich fehlerhafte Veröffentlichung beobachtet, nicht nur eine Warnfarbe. Kehre zum nummerierten Jenkins-Build zurück, bevor du die Prüfung für diesen Schritt verwendest.
Verknüpfe das Testergebnis mit der Veröffentlichung
In diesem Schritt änderst du die Pipeline so, dass ein fehlgeschlagener Test sichtbar bleibt und die Stage Publish verhindert. Beginne in Jenkins und öffne die Jobseite von shop-update über den entsprechenden Link in der Brotkrumennavigation.
Wähle Configure und dann den Abschnitt Pipeline. Sein Editor Script enthält eine Declarative Pipeline. agent any wählt einen verfügbaren Jenkins-Executor aus; in dieser vorbereiteten Einführungsumgebung läuft er innerhalb des Controller-Containers. Ein Workspace ist das Verzeichnis, das diesem Build zugewiesen wird. Unabhängige Agents werden in einem separaten Projekt behandelt.
Lies die Stage Test. Die bereitgestellte Zeile sh returnStatus: true, script: ... führt das Testskript aus und gibt dessen Exitstatus zurück, anstatt sofort einen Pipeline-Fehler auszulösen. Dadurch kann der nachfolgende Schritt junit die Testdetails veröffentlichen. Exitstatus null bedeutet, dass das Skript erfolgreich war; ein anderer Status bedeutet, dass es nicht erfolgreich war. junit liest die XML-Ergebnisdatei, ordnet die Tests diesem Build zu und markiert ihn normalerweise als UNSTABLE, wenn ein Test fehlschlägt.
Eine Pipeline-Option verändert, wie Jenkins die Pipeline ausführt. Füge die folgende Zeile unmittelbar nach agent any hinzu. Die geschweiften Klammern fassen die Option zusammen; behalte sowohl die öffnende als auch die schließende Klammer genau wie gezeigt bei.
options { skipStagesAfterUnstable() }
Der Anfang des Skripts sollte jetzt so aussehen. Behalte alle anderen vorhandenen Zeilen bei, einschließlich der Empfängeradresse und der bereitgestellten Stages Prepare, Test und Publish.
pipeline {
agent any
options { skipStagesAfterUnstable() }
Diese Option überspringt nachfolgende Stages, sobald der Build instabil wird. Sie macht aus einem fehlgeschlagenen Test keinen bestandenen Test. Behalte den standardmäßigen Schritt zur Veröffentlichung des Berichts bei:
junit testResults: 'reports/pricing.xml'
Behalte die bereitgestellten Shellaufrufe zum Kopieren des Kandidaten, zum Ausführen von test-shop.sh und zum Veröffentlichen des Pakets bei. Der Testbericht muss von diesem Testprogramm stammen; ersetze es nicht durch einen Schritt, der einen Bericht schreibt, und füge keine weiteren Shellbefehle hinzu.
Füge nicht skipMarkingBuildUnstable: true hinzu: Diese Einstellung unterdrückt den Buildstatus, auf dem die Freigabebedingung beruht. Entferne keine Tests, ändere nicht ihre erwarteten Preise, verändere weder die bereitgestellten Kandidaten noch den Veröffentlichungsschritt und überspringe die Veröffentlichung nicht für sämtliche Kandidaten.
Wähle Save. Wähle Build with Parameters, belasse den Wert auf broken und wähle Build. Warte, bis der neue nummerierte Build abgeschlossen ist. Öffne Console Output. Diesmal solltest du Folgendes sehen:
Pricing failures: 1
Stage "Publish" skipped due to earlier stage(s) marking the build as unstable
Finished: UNSTABLE
Öffne Tests. Derselbe fehlgeschlagene Test und die drei bestandenen Tests sollten weiterhin vorhanden sein. Der neue Build darf Release received nicht enthalten. Der Shop kann weiterhin die frühere fehlerhafte Veröffentlichung anzeigen: Das Blockieren eines neuen Versuchs setzt eine frühere Veröffentlichung nicht automatisch zurück. Im nächsten Schritt ersetzt du sie durch den funktionierenden Kandidaten.
Falls der Build stattdessen einen Groovy-Syntaxfehler meldet, öffne Configure erneut. Prüfe, ob die hinzugefügte Zeile options innerhalb von pipeline direkt unter agent any steht und alle geschweiften Klammern paarweise zusammenpassen. Korrigiere den Fehler, wähle Save und führe broken erneut aus. Ein Syntaxfehler allein schließt diesen Schritt nicht ab. Jenkins gibt manchmal einen Hinweis des Checks-API-Publishers aus; dieser lokale Kurs verwendet keinen gehosteten Git-Dienst, daher ersetzt dieser Hinweis nicht das tatsächliche Testergebnis.
Veröffentliche den funktionierenden Kandidaten
In diesem Schritt weist du nach, dass dieselbe Pipeline ein korrektes Update ausliefern und den normalen Ablauf für Kunden erhalten kann. Beginne auf der Jobseite von shop-update in Jenkins.
Wähle Build with Parameters. Setze RELEASE auf fixed und wähle dann Build. Damit wählst du den bereitgestellten funktionierenden Kandidaten aus; die gerade getestete Pipeline wird dadurch nicht geändert. Warte auf den Abschluss und öffne Console Output des neuen Builds.
Pricing failures: 0
Release received
Finished: SUCCESS
Öffne Tests. Alle vier Tests der Preisberechnung sollten bestanden sein. Kehre zur Statusseite dieses Builds zurück und suche Build Artifacts. Lade shop-release.tar.gz herunter. Ein Artefakt ist eine Datei, die Jenkins für diesen Build aufbewahrt; dieses komprimierte Archiv enthält das Preisberechnungsprogramm, die Metadaten der Veröffentlichung und die Pflegeanleitung. Das Archiv ist zugleich das tatsächlich an den Shop gesendete Paket und keine separat neu erstellte Kopie.
Wechsle zu Gift Shop, kehre über den Markenlink zur Startseite zurück und lade sie neu. Die Kollektion heißt jetzt Gifts to grow together. Öffne Shop und prüfe drei Saatgutsets: Warenwert £32.40, Versand £4.00, Gesamtsumme £36.40. Für zwei Picknickboxen muss der Versand weiterhin kostenlos sein. Öffne Delivery und Visit, lade die Pflegeanleitung erneut herunter und prüfe, ob sie vollständig ist.
Die abschließende Prüfung verknüpft die tatsächlich fehlgeschlagenen und erfolgreichen Builds mit der aktuell gespeicherten Pipeline und den bereitgestellten Dateiinhalten. Wenn du die Pipeline nach diesen Durchläufen bearbeitest, wiederhole zuerst broken und danach fixed, damit beide Ergebnisse die von dir eingereichte Version beschreiben. Behalte die früheren Builds und die ursprünglichen Shopressourcen bei; du musst weder einen Bericht schreiben noch eine Konsolenausgabe in eine Datei kopieren.
Falls du versehentlich erneut broken gewählt hast, behalte die Freigabebedingung bei und führe fixed aus. Wenn Jenkins noch baut, warte auf das endgültige Ergebnis des nummerierten Builds, anstatt wiederholt weitere Builds zu starten. Eine funktionierende Startseite allein reicht nicht aus: Die Preise im Warenkorb und der Download gehören ebenfalls zum fertigen Ergebnis.
Zusammenfassung
Du hast einen echten fehlgeschlagenen Test der Preisberechnung beobachtet, gesehen, warum ein instabiler Build trotzdem veröffentlicht wurde, und das Jenkins-Testergebnis mit einer Freigabebedingung verknüpft. Anschließend hast du mit derselben Pipeline den funktionierenden Kandidaten ausgeliefert und die tatsächlichen Preise, das archivierte Paket und die normalen Shopfunktionen überprüft.
