Einführung
Cedar & Common plant einen Nachbarschaftstag. Das offizielle Programm ist bereits verfügbar, und zwei mögliche Pläne benötigen separate Vorschauen. Jenkins kann beide Branches bauen, doch ihre aktuellen Pipelines veröffentlichen am selben Ort. Ein erfolgreicher Build allein hält nicht beide Ideen verfügbar.
Du wirst die Branches ermitteln, diese Kollision beobachten, ihre Jenkinsfiles ändern und zwei nutzbare Vorschauen veröffentlichen. Anschließend änderst du eine Treffzeit und prüfst, ob sich deren Vorschau aktualisiert, während der andere Plan unverändert erhalten bleibt.
Vorausgesetzt werden grundlegende Terminaleingaben und Pfadkenntnisse, die Navigation auf Jenkins-Seiten und das Erkennen einer kurzen Declarative Pipeline. Git-Branches, Commits, Push, Indexierung und die neuen Pipeline-Einstellungen werden vor ihrer Verwendung erklärt. Das Repository, das Java-Erstellungsprogramm, der Veröffentlichungsschritt und die Jenkins-Plugins sind vorbereitet; du installierst sie nicht und schreibst auch nicht die Website. Dies ist ein lokaler Übungsdienst für Quellcode und Vorschauen auf einer VM, weder GitHub noch eine produktive Bereitstellungsplattform. Die Dauer ist eine Schätzung des Autors, keine mit Anfängern gemessene Zeit.
Entdecke die Pläne und ihre Branch-Builds
In diesem Schritt untersuchst du die normalen Programme und die Quellen der Kandidaten, ermittelst anschließend ihre Branch-Jobs und beobachtest die Kollision in der gemeinsamen Vorschau. Beginne in Preview Desk.
Wähle Open the official program. Prüfe Common Ground Day und 09:30. Wähle Explore this plan und prüfe die drei Aktivitäten und die Routenillustration. Wähle Download the activities für eine echte CSV-Datei und Read visitor notes für den vollständigen Text. Kehre mit der Browseraktion Back zur Übersicht zurück und dann mit Back erneut zum Desk. Öffne auch Read the courtyard notes und prüfe Courtyard Stories. Beide vorhandenen Programme müssen während deiner gesamten Arbeit verfügbar bleiben.
Wechsle zu Source. Dieses Terminal ist eine Git-Arbeitskopie: Die bearbeitbaren Dateien gehören jeweils zu einem ausgewählten Branch. Ein Branch ist eine benannte Entwicklungslinie des Quellverlaufs. Beim Branchwechsel werden die Arbeitsdateien auf die Version dieses Branches umgestellt; der andere Branch wird dabei nicht geändert. Ein Commit ist eine aufgezeichnete Version des Repository-Inhalts, die durch einen Hash identifiziert wird; diese Kennung wird einen Jenkins-Build mit seiner Quelle verknüpfen.
Das Terminal öffnet sich in /home/labex/project/community-site. pwd gibt das aktuelle Verzeichnis aus. git --no-pager branch --list listet lokale Branches auf, wobei * den ausgewählten kennzeichnet. --no-pager hält das Ergebnis direkt im Terminal. Ohne diese Option öffnet Git möglicherweise einen interaktiven Betrachter; wenn du (END) statt einer Shell-Eingabeaufforderung siehst, drücke q, um den Betrachter zu verlassen. Führe Folgendes aus:
pwd
git --no-pager branch --list
Die Liste enthält main, courtyard-notes, garden-plan und river-plan. Vorausgewählt ist garden-plan. Falls du versehentlich das Verzeichnis wechselst, kehre vor dem Fortfahren mit cd /home/labex/project/community-site zurück.
cat gibt eine Datei aus, ohne sie zu ändern. event.properties speichert pro Zeile eine Einstellung im Format key=value für Titel, Treffpunktdetails und Aktivitäten. Lies diese kleine Datendatei:
cat event.properties
Sie beschreibt Garden Gathering mit einem Treffen um 10:00 bei Glasshouse gate. Die Zeile meeting_time enthält Daten für das bereitgestellte Erstellungsprogramm, das Seiten, CSV-Datei und Hinweise gemeinsam erzeugt.
git switch wählt einen Branch in dieser Arbeitskopie aus. Vergleiche den zweiten Kandidaten und kehre dann zurück:
git switch river-plan
cat event.properties
git switch garden-plan
Der zweite Plan ist Riverside Picnic mit einem Treffen um 14:00 bei River steps. Dies sind tatsächlich unterschiedliche Quelldateien, nicht eine einzelne Seite mit einem anderen Branch-Abzeichen.
Dein bearbeitbarer Umfang beschränkt sich auf das Jenkinsfile der Kandidatenbranches und die später angeforderte Änderung von meeting_time in event.properties. Behalte die Vorlagen, das Routenbild, das Erstellungsprogramm und den Veröffentlichungsschritt unverändert bei. Bearbeite, lösche oder benenne das vorbereitete Jenkins-Projekt und die Branch-Jobs nicht um und erstelle sie nicht neu. Erhalte den gesamten Git- und Jenkins-Verlauf und jedes aufbewahrte Vorschauarchiv, die Branches main und courtyard-notes, das offizielle Programm und die Courtyard-Vorschau. Diese Übung erfordert weder Docker noch Administratorbefehle.
Bestimme an dieser Stelle, welcher Kandidat um 10:00 und welcher um 14:00 beginnt. Noch wurde keine Kandidatenvorschau veröffentlicht.
Führe nun die systemeigene Branch-Erkennung von Jenkins aus und vergleiche erfolgreiche Builds mit ihrem tatsächlichen Veröffentlichungsergebnis. Wechsle zu Jenkins und öffne community-previews über Dashboard.
Dieses vorbereitete übergeordnete Projekt ist eine Multibranch Pipeline. Sie durchsucht ein Git-Repository nach Branches mit einem Jenkinsfile und erstellt für jeden einen untergeordneten Pipeline-Job. Die Quelle verwendet einen kleinen schreibgeschützten Git-Dienst innerhalb dieser Übungsumgebung; das vorbereitete origin der Arbeitskopie ist das Ziel, an dem deine späteren Pushes Quelländerungen veröffentlichen. Ein externes Konto oder Zugangsdaten sind nicht erforderlich.
Warte, bis die Jenkins-Seite vollständig geladen ist, und wähle dann Scan Multibranch Pipeline Now. Öffne Scan Multibranch Pipeline Log und warte auf Finished: SUCCESS. Der Scan entdeckt garden-plan und river-plan; main und courtyard-notes enthalten kein Jenkinsfile und sind keine Kandidatenjobs. Kehre über den Brotkrumenlink community-previews zurück. Warte, bis beide untergeordneten Builds abgeschlossen sind.
Öffne garden-plan, dann seinen nummerierten Build und Console Output. Seine Ausgabe sollte Garden Gathering, 10:00 und die ausgecheckte Quellrevision angeben. Kehre über community-previews zurück, öffne river-plan und untersuche die Konsole seines nummerierten Builds. Sie sollte Riverside Picnic, 14:00 und seine eigene Quellrevision angeben. Beide sollten mit SUCCESS enden. In dieser vorbereiteten Umgebung kann vor einem erfolgreichen Checkout eine Git-Werkzeugmeldung Using Default erscheinen; beurteile anhand der tatsächlichen Revision und des Endergebnisses, ob der Checkout abgeschlossen wurde.
Wechsle zu Source. Lies die bereitgestellte Pipeline:
cat Jenkinsfile
options { skipDefaultCheckout() } schaltet den impliziten Quell-Checkout der Declarative Pipeline ab, damit die sichtbare Stage Check out this branch ihn ausdrücklich ausführt. checkout scm verwendet die bestimmte Branch-Revision, aus der dieses Jenkinsfile stammt. Ersetze dies nicht durch einen Checkout eines fest vorgegebenen Branches.
Die bereitgestellte Stage Build preview erstellt aus dieser ausgecheckten Quelle echte Besucherdateien. Archive preview bewahrt preview.zip in Jenkins auf, bevor Publish preview dieselben Bytes an den lokalen Desk sendet. Der abschließende Block post verwendet deleteDir(), um das Arbeitsverzeichnis dieses Builds zu leeren. Behalte diese Stages und die Bereinigung bei.
Ein Block environment stellt den Stages Werte bereit. Beide Branches enthalten derzeit dieselbe Einstellung:
PREVIEW_KEY = 'shared'
PREVIEW_KEY wählt die Veröffentlichungsadresse des Desks. Die wörtliche Zeichenkette 'shared' sendet beide Builds an einen Ort, obwohl ihre Quell-Checkouts unterschiedlich sind. Kehre zu Preview Desk zurück und lade die Seite neu. Es gibt eine Kandidatenkarte shared, die den Branch zeigt, der zuletzt veröffentlicht hat. Wähle ihren Link Open preview und vergleiche ihren Titel mit den beiden erfolgreichen Quellbuilds. Von dieser einen Adresse aus kannst du keine zwei unabhängigen Vorschauen teilen.
Kehre mit der Browseraktion Back zum Desk zurück. Das offizielle Programm und die Courtyard-Hinweise müssen weiterhin funktionieren. Du hast jetzt beobachtet, warum separate Branch-Jobs nicht automatisch separate veröffentlichte Ergebnisse bedeuten.
Gib jedem Branch eine eigene Vorschau
In diesem Schritt änderst und veröffentlichst du das Jenkinsfile jedes Branches und baust anschließend beide unabhängigen Vorschauen. Beginne in Source, in /home/labex/project/community-site.
Jenkins stellt in einem Multibranch-Build env.BRANCH_NAME bereit. Dies ist der aktuelle Branchname, etwa garden-plan. Ersetze den gemeinsamen Wert durch diese systemeigene Branch-Identität:
PREVIEW_KEY = "${env.BRANCH_NAME}"
Doppelte Anführungszeichen in Groovy ermöglichen es, mit ${...} den Wert der Variablen einzusetzen. Einfache Anführungszeichen um diesen Ausdruck würden stattdessen seine Zeichen wörtlich beibehalten. Die Branchnamen dieser Übung verwenden bereits einfache Kleinbuchstaben und Bindestriche, die sich für Vorschauadressen eignen; dies ist keine allgemeine Bereinigungsregel für beliebige Branchnamen.
Wähle zuerst den Garden-Kandidaten aus. git status --short zeigt nicht committete Änderungen kompakt an; M bedeutet eine geänderte Datei, und keine Ausgabe bedeutet eine saubere Arbeitskopie. nano ist ein Terminaleditor für die angegebene Datei; er behält die Kontrolle über dieses Terminal, bis du speicherst und ihn verlässt.
git switch garden-plan
git status --short
nano Jenkinsfile
nano bearbeitet die angegebene Datei in diesem Terminal. Gehe mit den Pfeiltasten zur Zeile PREVIEW_KEY. Drücke Home, um an ihren Anfang zu gelangen, und dann einmal Ctrl+K, um diese eine Zeile auszuschneiden. Tippe die vollständige oben gezeigte Ersatzzeile einschließlich ihrer Einrückung und drücke Enter, damit die folgende Zeile RECEIVER_URL getrennt bleibt. Schneide keine weiteren Zeilen aus. Speichere mit Ctrl+O, drücke Enter, um Jenkinsfile zu bestätigen, und verlasse den Editor dann mit Ctrl+X. Ctrl bedeutet hier, die Control-Taste gedrückt zu halten, auch unter macOS.
Prüfe deine Bearbeitung, bevor du sie im Git-Verlauf speicherst. git diff vergleicht die Arbeitsdatei mit ihrer committeten Version. Wie zuvor gibt --no-pager direkt im Terminal aus; -- trennt Optionen vom Dateipfad. Führe Folgendes aus:
git --no-pager diff -- Jenkinsfile
Der Diff sollte nur die entfernte alte Zeile PREVIEW_KEY und die hinzugefügte neue Zeile zeigen. Die Präfixe - und + beschreiben entfernten und hinzugefügten Text; du tippst diese Zeichen nicht in die Datei. Falls der Diff eine unbeabsichtigte Änderung enthält, öffne nano Jenkinsfile erneut, korrigiere sie, speichere, verlasse den Editor und prüfe erneut. Falls du einen Fehler wegen einer nicht gefundenen Datei siehst, führe pwd aus und kehre zum oben angegebenen Arbeitsverzeichnis zurück.
Ein Commit zeichnet die vorgemerkte Quelländerung auf dem ausgewählten Branch auf. git add merkt diese Datei vor; git commit -m zeichnet sie mit der angegebenen Nachricht auf; git push origin garden-plan veröffentlicht diesen Branch im vorbereiteten Origin-Repository, damit Jenkins den neuen Commit entdecken kann. In diesen Commitbefehlen halten doppelte Anführungszeichen die aus mehreren Wörtern bestehende Nachricht als ein Argument zusammen. Diese Befehle ändern den Quellverlauf, nicht unmittelbar die laufende Vorschau:
git add Jenkinsfile
git commit -m "Give the garden plan its own preview"
git push origin garden-plan
Wende nun dieselbe Einstellung auf den anderen Kandidaten an:
git switch river-plan
git status --short
nano Jenkinsfile
Ersetze nur dessen Zeile PREVIEW_KEY mit derselben nano-Bedienung und dem exakten Ausdruck in doppelten Anführungszeichen. Speichere und verlasse den Editor. Prüfe diesen Branch, erstelle den Commit und pushe ihn:
git --no-pager diff -- Jenkinsfile
git add Jenkinsfile
git commit -m "Give the river plan its own preview"
git push origin river-plan
Falls Git den Wechsel wegen nicht committeter Änderungen verweigert, führe git status --short aus und untersuche zuerst den Diff auf dem aktuellen Branch. Schließe diese beabsichtigte Bearbeitung vor dem Wechsel ab oder korrigiere sie; verwirf keine Dateien und setze das Repository nicht zurück. Falls git commit meldet, dass es nichts zu committen gibt, nachdem du die beabsichtigte Bearbeitung bereits committet hast, prüfe git --no-pager log -1 --oneline und fahre mit dem Push des Branches fort. -1 begrenzt diese Ansicht auf einen Commit; --oneline zeigt seine kurze Kennung und Nachricht.
Wechsle zu Jenkins, kehre über die Brotkrumennavigation zu community-previews zurück und wähle erneut Scan Multibranch Pipeline Now. In dieser lokalen Übung gibt es keinen Webhook; ein Push der Quelle allein fordert daher keinen Scan an. Warte, bis der Scan und beide neuen untergeordneten Builds erfolgreich abgeschlossen sind. Jede Konsole muss ihren eigenen Branch-Vorschauschlüssel zeigen. Falls ein Build einen Groovy-Syntaxfehler meldet, korrigiere die Anführungszeichen und geschweiften Klammern seines Jenkinsfiles in Source, committe und pushe die Korrektur auf diesem Branch und scanne dann erneut. Bearbeite nicht einen erzeugten untergeordneten Job anstelle seiner Quelle.
Wechsle zu Preview Desk und lade die Seite neu. Es muss jetzt separate Karten garden-plan und river-plan geben. Die alte gemeinsame Karte kann als zuvor beobachtetes Ergebnis erhalten bleiben. Öffne den Link Open preview jedes Kandidaten und prüfe seinen korrekten Titel, seine Treffzeit, drei Aktivitäten, das Routenbild, die CSV-Datei und die Besucherhinweise. Kehre nach dem Erkunden eines Plans mit der Browseraktion Back zu seiner Übersicht zurück und dann mit Back erneut zum Desk, bevor du die andere Karte öffnest. Die beiden Vorschauadressen müssen unterschiedlich sein und gleichzeitig nutzbar bleiben.
Achte auf die Schlüssel garden-plan und river-plan über ihren jeweiligen Titeln und ursprünglichen Treffzeiten. Die aufbewahrte Karte shared zeigt die frühere Kollision; sie ist kein Ersatz für eine der unabhängigen Vorschauen.
Öffne in Jenkins die Statusseite des jeweils neuesten erfolgreichen Branch-Builds und lade preview.zip unter Build Artifacts herunter. Entpacke jede ZIP-Datei in einen anderen neuen Ordner und öffne index.html. Behalte alle sieben Dateien zusammen. Die Seiten und Anhänge müssen lokal funktionieren; ein Textanhang öffnet sich möglicherweise direkt, statt einen weiteren Download auszulösen. build.json bezeichnet den tatsächlichen Quellbranch und Commit. Diese vollständigen Vorschauen sind das Ergebnis; zwei grüne Buildanzeigen allein reichen nicht aus.
Aktualisiere einen Plan und erhalte den anderen
In diesem Schritt änderst du die Garden-Treffzeit und aktualisierst mit einem weiteren Scan nur die Vorschau dieses Branches. Beginne in Jenkins und notiere die neueste erfolgreiche Buildnummer von river-plan. Halte seine Vorschau zum Vergleich geöffnet.
Wechsle zu Source. Wähle den Garden-Branch aus und bearbeite seine kleine Datendatei:
git switch garden-plan
git status --short
nano event.properties
Ändere nur die vollständige Zeile meeting_time von meeting_time=10:00 in:
meeting_time=10:30
Verwende dieselben Pfeiltasten und dieselbe Bedienfolge mit Home, einmal Ctrl+K, Ersatztext und Enter wie bei der Pipeline-Zeile. Speichere mit Ctrl+O, Enter, und verlasse den Editor mit Ctrl+X. Das Erstellungsprogramm liest diesen einen Wert, damit Seite, CSV-Datei und Hinweise übereinstimmen; du bearbeitest keine erzeugten Besucherdateien.
Prüfe und veröffentliche diese Quellaktualisierung:
git --no-pager diff -- event.properties
git add event.properties
git commit -m "Move the garden meeting to 10:30"
git push origin garden-plan
Der Diff sollte nur diese Treffzeit ändern. Falls das nicht der Fall ist, korrigiere die Datei vor dem Commit. Der River-Branch erhält keine Quelländerung.
Wechsle zu Jenkins, kehre zu community-previews zurück und wähle Scan Multibranch Pipeline Now. Nach der Indexierung sollte der Garden-Job einen neuen Build für seine geänderte Revision ausführen; der unveränderte River-Branch sollte die notierte Buildnummer behalten. Warte, bis der Garden-Build mit SUCCESS abgeschlossen ist. Öffne seine Console Output und stelle den Zusammenhang zwischen dem neuen Commit, 10:30 und der Quelländerung her.
Falls der Scan keine Änderungen meldet und die Garden-Vorschau alt bleibt, kehre zu Source zurück. Prüfe git status --short und git --no-pager log -1 --oneline, bestätige, dass die beabsichtigte Änderung auf garden-plan committet wurde, und pushe diesen Branch vor dem erneuten Scan. Eine lokale Dateibearbeitung oder ein Commit, der Origin noch nicht erreicht hat, ist noch keine Quelle, die Jenkins entdecken kann. Falls ein Build fehlschlägt, lies seine Konsole und korrigiere den angezeigten Quellfehler durch einen weiteren Commit und Push. Setze die VM nicht zurück und ersetze nicht das bereitgestellte Erstellungsprogramm.
Wechsle zu Preview Desk und lade die Seite neu. Öffne garden-plan: Garden Gathering muss sich jetzt um 10:30 treffen. Prüfe Explore this plan, die heruntergeladene Aktivitäten-CSV und die vollständigen Besucherhinweise; die Treffzeit muss überall übereinstimmen. Öffne river-plan: Riverside Picnic muss sich weiterhin um 14:00 treffen, mit seinen ursprünglichen Aktivitäten und funktionierenden Anhängen. Seine build.json muss den vorherigen Quellcommit und die systemeigene Buildnummer beibehalten. Führe diesen unveränderten untergeordneten Job während dieser abschließenden Aktualisierung nicht erneut aus.
Kehre zu Jenkins zurück und lade die neueste Garden-Datei preview.zip herunter. Entpacke sie in einen weiteren neuen Ordner und wiederhole die lokalen Prüfungen von Seite, Bild, CSV-Datei und Hinweisen. Sie muss den neuen Garden-Commit bezeichnen; das zuvor heruntergeladene River-Paket sollte weiterhin unabhängig nutzbar sein.
Kehre abschließend zu Preview Desk zurück, öffne Open the official program und Read the courtyard notes und prüfe, ob beide vollständigen Programme unverändert erhalten sind. Bewahre die ursprünglichen Branch- und Buildverläufe auf. Falls du weitere Quelländerungen vornimmst, committe und pushe sie und schließe den zugehörigen Jenkins-Build ab, bevor du die Fertigstellung prüfst. Du hast zwei laufende Vorschauen und den Nachweis, dass die Aktualisierung einer Vorschau ihre Nachbarvorschau weder überschrieben noch neu gebaut hat.
Zusammenfassung
Du hast die systemeigene Multibranch-Erkennung und die Quellrevision hinter jedem Jenkinsfile verwendet und anschließend die Veröffentlichung anhand der Branch-Identität von Jenkins getrennt. Beide Pläne haben jetzt nutzbare Seiten, Bilder und Anhänge unter unabhängigen Adressen. Ein späterer Garden-Commit hat nur seine eigene Vorschau aktualisiert, während der River-Build, das offizielle Programm und die Courtyard-Vorschau unverändert erhalten blieben.
