Tutorial für kontinuierliche Lieferung - Erstellen einer Pipeline für kontinuierliche Lieferung mit Jenkins

Kontinuierliche Lieferung:

Continuous Delivery ist ein Prozess, bei dem Codeänderungen automatisch erstellt, getestet und für eine Freigabe für die Produktion vorbereitet werden.Ich hoffe du hast meine genossen Hier werde ich über folgende Themen sprechen:

• Was ist kontinuierliche Lieferung?
• Arten von Softwaretests
• Unterschied zwischen kontinuierlicher Integration, Bereitstellung und Bereitstellung
• Was ist die Notwendigkeit einer kontinuierlichen Lieferung?
• Mit Jenkins und Tomcat zum Anfassen

Lassen Sie uns schnell verstehen, wie Continuous Delivery funktioniert.

Was ist kontinuierliche Lieferung?

Es ist ein Prozess, bei dem Sie Software so erstellen, dass sie jederzeit für die Produktion freigegeben werden kann.Betrachten Sie das folgende Diagramm:

Lassen Sie mich das obige Diagramm erklären:

• Automatisierte Build-Skripte erkennen Änderungen im Quellcode-Management (SCM) wie Git.
• Sobald die Änderung erkannt wurde, wird der Quellcode auf einem dedizierten Build-Server bereitgestellt, um sicherzustellen, dass der Build nicht fehlschlägt und alle Testklassen und Integrationstests ordnungsgemäß ausgeführt werden.
• Anschließend wird die Build-Anwendung auf den Testservern (Vorproduktionsservern) für den User Acceptance Test (UAT) bereitgestellt.
• Schließlich wird die Anwendung zur Freigabe manuell auf den Produktionsservern bereitgestellt.

Bevor ich fortfahre, wird es nur fair sein, Ihnen die verschiedenen Arten von Tests zu erklären.

Arten von Softwaretests:

Grundsätzlich gibt es zwei Arten von Tests:

• Blackbox-Tests: Es handelt sich um eine Testtechnik, die den internen Mechanismus des Systems ignoriert und sich auf die Ausgabe konzentriert, die für jede Eingabe und Ausführung des Systems generiert wird. Es wird auch als Funktionstest bezeichnet. Es wird grundsätzlich zur Validierung der Software verwendet.
• Whitebox-Tests: ist eine Testtechnik, die den internen Mechanismus eines Systems berücksichtigt. Es wird auch als Strukturprüfung und Glasboxprüfung bezeichnet. Es wird grundsätzlich zur Überprüfung der Software verwendet.

Whitebox-Tests:

Es gibt zwei Arten von Tests, die unter diese Kategorie fallen.

So finden Sie die Array-Länge in Javascript

• Unit Testing: Es ist das Testen einer einzelnen Einheit oder einer Gruppe verwandter Einheiten. Der Programmierer führt häufig Tests durch, um zu testen, ob die von ihm implementierte Einheit die erwartete Ausgabe gegen die angegebene Eingabe erzeugt.
• Integrationstests: Es ist eine Art von Test, bei dem sich eine Gruppe von Komponenten befindetkombiniert, um die Ausgabe zu erzeugen. Außerdem wird die Interaktion zwischen Software und Hardware getestet, wenn Software- und Hardwarekomponenten eine Beziehung haben. Es kann sowohl unter White-Box-Tests als auch unter Black-Box-Tests fallen.

Blackbox-Tests:

Es gibt mehrere Tests, die unter diese Kategorie fallen. Ich werde mich konzentrierenein paar, die für Sie wichtig sind, um diesen Blog zu verstehen:

• Funktions- / Abnahmetests: Es stellt sicher, dass die in den Systemanforderungen erforderliche Funktionalität funktioniert. Es wird sichergestellt, dass das gelieferte Produkt den Anforderungen entspricht und wie vom Kunden erwartet funktioniert
• Systemtests: Es stellt sicher, dass die Software durch Platzieren in verschiedenen Umgebungen (z. B. Betriebssystemen) weiterhin funktioniert.
• Stresstest: Es wird bewertet, wie sich das System unter ungünstigen Bedingungen verhält.
• Beta-test: Dies wird von Endbenutzern, einem Team außerhalb der Entwicklung oder der öffentlichen Veröffentlichung der vollständigen Vorversion des Produkts durchgeführt, das als bekannt istBetaAusführung. Ziel des Betatests ist es, unerwartete Fehler abzudecken.

Jetzt ist der richtige Zeitpunkt für mich, um den Unterschied zwischen kontinuierlicher Integration, Bereitstellung und Bereitstellung zu erklären.

Unterschiede zwischen kontinuierlicher Integration, Bereitstellung und Bereitstellung:

Visuelle Inhalte erreichen das Gehirn eines Menschen schneller und verständlicher als Textinformationen. Ich beginne also mit einem Diagramm, das den Unterschied klar erklärt:

Bei der kontinuierlichen Integration wird jedes Code-Commit erstellt und getestet, kann jedoch nicht freigegeben werden. Ich meine, die Build-Anwendung wird nicht automatisch auf den Testservern bereitgestellt, um sie mithilfe verschiedener Arten von Blackbox-Tests wie - User Acceptance Testing (UAT) - zu validieren.

In Continuous Delivery wird die Anwendung kontinuierlich auf den Testservern für UAT bereitgestellt. Sie können auch sagen, dass die Anwendung jederzeit für die Produktion freigegeben werden kann. Daher ist für die kontinuierliche Bereitstellung offensichtlich eine kontinuierliche Integration erforderlich.

Die kontinuierliche Bereitstellung ist der nächste Schritt nach der kontinuierlichen Bereitstellung, bei dem Sie nicht nur ein bereitstellbares Paket erstellen, sondern es tatsächlich automatisiert bereitstellen.

Lassen Sie mich die Unterschiede anhand einer Tabelle zusammenfassen:

In einfachen Worten ist die kontinuierliche Integration sowohl Teil der kontinuierlichen Bereitstellung als auch der kontinuierlichen Bereitstellung. Die kontinuierliche Bereitstellung entspricht der kontinuierlichen Bereitstellung, mit der Ausnahme, dass Releases automatisch erfolgen.

Erfahren Sie, wie Sie CI / CD-Pipelines mit Jenkins On Cloud erstellen

Die Frage ist aber, ob kontinuierliche Integration ausreicht.

Warum brauchen wir eine kontinuierliche Lieferung?

Lassen Sie uns dies anhand eines Beispiels verstehen.

Stellen Sie sich vor, 80 Entwickler arbeiten an einem großen Projekt. Sie verwenden Continuous Integration-Pipelines, um automatisierte Builds zu ermöglichen. Wir wissen, dass Build auch Unit-Tests umfasst. Eines Tages beschlossen sie, den neuesten Build, der die Komponententests bestanden hatte, in einer Testumgebung bereitzustellen.

Dies muss ein langwieriger, aber kontrollierter Ansatz für die Bereitstellung sein, den ihre Umgebungsspezialisten durchgeführt haben. Das System schien jedoch nicht zu funktionieren.

Was könnte die offensichtliche Ursache für das Versagen sein?

Nun, der erste Grund, den die meisten Leute denken werden, ist, dass es ein Problem mit der Konfiguration gibt. Wie die meisten Leute dachten auch sie das.Sie haben viel Zeit damit verbracht, herauszufinden, was mit der Konfiguration der Umgebung nicht stimmt, aber sie konnten das Problem nicht finden.

Ein aufmerksamer Entwickler verfolgte einen intelligenten Ansatz:

Dann probierte einer der leitenden Entwickler die Anwendung auf seiner Entwicklungsmaschine aus. Dort hat es auch nicht funktioniert.

Er ging immer wieder frühere Versionen durch, bis er feststellte, dass das System drei Wochen zuvor nicht mehr funktionierte. Ein winziger, dunkler Fehler hatte das System daran gehindert, richtig zu starten. Das Projekt hatte jedoch eine gute Abdeckung durch Unit-Tests.Trotzdem sahen 80 Entwickler, die normalerweise nur die Tests und nicht die Anwendung selbst ausführten, das Problem drei Wochen lang nicht.

Problemstellung:

Ohne Akzeptanztests in einer produktionsähnlichen Umgebung auszuführen, wissen sie nichts darüber, ob die Anwendung den Kundenspezifikationen entspricht oder ob sie in der realen Welt bereitgestellt werden und überleben kann. Wenn sie zeitnahes Feedback zu diesen Themen wünschen, müssen sie den Bereich ihres kontinuierlichen Integrationsprozesses erweitern.

Lassen Sie mich die Lehren aus den oben genannten Problemen zusammenfassen:

• Unit Tests testen nur die Perspektive eines Entwicklers auf die Lösung eines Problems. Sie können nur begrenzt nachweisen, dass die Anwendung aus Anwendersicht das tut, was sie soll. Sie sind nicht genug dazuIdentifizieren Sie die tatsächlichen Funktionsprobleme.
• Das Bereitstellen der Anwendung in der Testumgebung ist ein komplexer, manuell intensiver Prozess, der sehr fehleranfällig war.Dies bedeutete, dass jeder Bereitstellungsversuch ein neues Experiment war - ein manueller, fehleranfälliger Prozess.

Lösung - Continuous Delivery Pipeline (automatisierter Abnahmetest):

Sie führten die kontinuierliche Integration (Continuous Delivery) zum nächsten Schritt und führten einige einfache, automatisierte Abnahmetests ein, die bewiesen, dass die Anwendung ausgeführt wurde und ihre grundlegendste Funktion erfüllen konnte.Die meisten Tests, die während der Phase des Abnahmetests ausgeführt werden, sind funktionale Abnahmetests.

Grundsätzlich haben sie eine Continuous Delivery-Pipeline erstellt, um sicherzustellen, dass die Anwendung nahtlos in der Produktionsumgebung bereitgestellt wird, indem sichergestellt wird, dass die Anwendung ordnungsgemäß funktioniert, wenn sie auf dem Testserver bereitgestellt wird, der eine Replik des Produktionsservers ist.

Genug der Theorie, ich werde Ihnen jetzt zeigen, wie Sie mit Jenkins eine Continuous Delivery-Pipeline erstellen.

Continuous Delivery Pipeline mit Jenkins:

Hier werde ich Jenkins verwenden, um eine Continuous Delivery-Pipeline zu erstellen, die die folgenden Aufgaben umfasst:

Schritte in der Demo:

• Abrufen des Codes von GitHub
• Quellcode kompilieren
• Unit-Test und Generierung der JUnit-Testberichte
• Packen Sie die Anwendung in eine WAR-Datei und stellen Sie sie auf dem Tomcat-Server bereit

Voraussetzungen:

• CentOS 7 Maschine
• Jenkins 2.121.1
• Docker
• Tomcat 7

Schritt - 1 Kompilieren des Quellcodes:

Beginnen wir mit der Erstellung eines Freestyle-Projekts in Jenkins. Betrachten Sie den folgenden Screenshot:

Geben Sie Ihrem Projekt einen Namen und wählen Sie Freestyle-Projekt:

Wenn Sie nach unten scrollen, finden Sie eine Option zum Hinzufügen eines Quellcode-Repositorys, wählen Sie git aus und fügen Sie die Repository-URL hinzu. In diesem Repository befindet sich eine Geldstrafe von pom.xml, mit der wir unser Projekt erstellen. Betrachten Sie den folgenden Screenshot:

Jetzt fügen wir einen Build-Trigger hinzu. Wählen Sie die Option 'Umfrage-SCM'. Grundsätzlich konfigurieren wir Jenkins so, dass das GitHub-Repository alle 5 Minuten nach Änderungen im Code abgefragt wird. Betrachten Sie den folgenden Screenshot:

Bevor ich fortfahre, möchte ich Ihnen eine kleine Einführung in den Maven Build Cycle geben.

Jeder der Build-Lebenszyklen wird durch eine andere Liste von Build-Phasen definiert, wobei eine Build-Phase eine Phase im Lebenszyklus darstellt.

Es folgt die Liste der Erstellungsphasen:

• validieren - validieren Sie, dass das Projekt korrekt ist und alle erforderlichen Informationen verfügbar sind
• compile - Kompiliert den Quellcode des Projekts
• test - Testen Sie den kompilierten Quellcode mit einem geeigneten Unit-Test-Framework. Für diese Tests sollte nicht erforderlich sein, dass der Code gepackt oder bereitgestellt wird
• package - Nehmen Sie den kompilierten Code und verpacken Sie ihn in seinem verteilbaren Format, z. B. einer JAR.
• überprüfen - Überprüfen Sie die Ergebnisse der Integrationstests, um sicherzustellen, dass die Qualitätskriterien erfüllt sind
• install - Installiert das Paket im lokalen Repository, um es als Abhängigkeit in anderen Projekten lokal zu verwenden
• Bereitstellen - Wird in der Build-Umgebung ausgeführt und kopiert das endgültige Paket in das Remote-Repository, um es für andere Entwickler und Projekte freizugeben.

Ich kann den folgenden Befehl ausführen, um den Quellcode zu kompilieren, Unit-Tests durchzuführen und sogar die Anwendung in eine War-Datei zu packen:

MVN sauberes Paket

Sie können Ihren Build-Job auch in mehrere Build-Schritte unterteilen. Dies erleichtert das Organisieren von Builds in sauberen, separaten Phasen.

Wir beginnen also mit dem Kompilieren des Quellcodes. Klicken Sie auf der Registerkarte 'Erstellen' auf 'Maven-Ziele der obersten Ebene aufrufen' und geben Sie den folgenden Befehl ein:

kompilieren

Betrachten Sie den folgenden Screenshot:

Dadurch wird der Quellcode aus dem GitHub-Repository abgerufen und auch kompiliert (Maven Compile Phase).

Klicken Sie auf Speichern und führen Sie das Projekt aus.

Klicken Sie nun auf die Konsolenausgabe, um das Ergebnis anzuzeigen.

Schritt - 2 Unit Testing:

Jetzt werden wir ein weiteres Freestyle-Projekt für Unit-Tests erstellen.

Fügen Sie auf der Registerkarte Quellcodeverwaltung dieselbe Repository-URL hinzu wie im vorherigen Job.

Klicken Sie nun auf der Registerkarte 'Buid Trigger' auf 'Nach anderen Projekten erstellen'. Geben Sie dort den Namen des vorherigen Projekts ein, in dem wir den Quellcode kompilieren, und Sie können eine der folgenden Optionen auswählen:

• Wird nur ausgelöst, wenn der Build stabil ist
• Wird ausgelöst, auch wenn der Build instabil ist
• Wird auch dann ausgelöst, wenn der Build fehlschlägt

Ich denke, die oben genannten Optionen sind ziemlich selbsterklärend, wählen Sie also eine aus. Betrachten Sie den folgenden Screenshot:

Klicken Sie auf der Registerkarte Erstellen auf Maven-Ziele der obersten Ebene aufrufen und verwenden Sie den folgenden Befehl:

Prüfung

Jenkins hilft Ihnen auch hervorragend dabei, Ihre Testergebnisse und Testergebnis-Trends anzuzeigen.

Der De-facto-Standard für Testberichte in der Java-Welt ist ein von JUnit verwendetes XML-Format. Dieses Format wird auch von vielen anderen Java-Testtools wie TestNG, Spock und Easyb verwendet. Jenkins versteht dieses Format. Wenn Ihr Build also JUnit XML-Testergebnisse liefert, kann Jenkins schöne grafische Testberichte und Statistiken zu Testergebnissen im Laufe der Zeit erstellen und Sie können auch die Details aller Testfehler anzeigen. Jenkins verfolgt auch, wie lange die Ausführung Ihrer Tests sowohl global als auch pro Test dauert. Dies kann nützlich sein, wenn Sie Leistungsprobleme aufspüren müssen.

Das nächste, was wir tun müssen, ist, Jenkins dazu zu bringen, unsere Unit-Tests im Auge zu behalten.

Gehen Sie zum Abschnitt Aktionen nach dem Erstellen und aktivieren Sie das Kontrollkästchen 'JUnit-Testergebnisbericht veröffentlichen'. Wenn Maven Komponententests in einem Projekt ausführt, werden die XML-Testberichte automatisch in einem Verzeichnis namens 'todsichere Berichte' generiert. Geben Sie also '** / target / surefire-reports / *. Xml' in das Feld 'Testbericht-XMLs' ein. Die beiden Sternchen am Anfang des Pfads („**“) sind eine bewährte Methode, um die Konfiguration etwas robuster zu gestalten: Sie ermöglichen es Jenkins, das Zielverzeichnis zu finden, unabhängig davon, wie wir Jenkins zum Auschecken des Quellcodes konfiguriert haben.

wie man die Länge des Arrays in Javascript erhält

** / target / surefire-reports / *. xml

Speichern Sie es erneut und klicken Sie auf Jetzt erstellen.

Jetzt wird der JUnit-Bericht in / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-Verhalten geschrieben.

Im Jenkins-DashboardSie können auch die Testergebnisse feststellen:

Schritt - 3 Erstellen einer WAR-Datei und Bereitstellen auf dem Tomcat-Server:

Der nächste Schritt besteht nun darin, unsere Anwendung in eine WAR-Datei zu packen und diese auf dem Tomcat-Server für den Benutzerakzeptanztest bereitzustellen.

Erstellen Sie ein weiteres Freestyle-Projekt und fügen Sie die URL des Quellcode-Repositorys hinzu.

Wählen Sie dann auf der Registerkarte Build-Trigger Build aus, wenn andere Projekte erstellt werden. Beachten Sie den folgenden Screenshot:

Grundsätzlich wird nach dem Testjob die Bereitstellungsphase automatisch gestartet.

Wählen Sie auf der Registerkarte 'Erstellen' das Shell-Skript aus. Geben Sie den folgenden Befehl ein, um die Anwendung in eine WAR-Datei zu packen:

MVN-Paket

Der nächste Schritt besteht darin, diese WAR-Datei auf dem Tomcat bereitzustellenServer. Wählen Sie auf der Registerkarte 'Aktionen nach dem Erstellen' die Option 'Krieg / Ohr für einen Container bereitstellen'. Geben Sie hier den Pfad zur Kriegsdatei und den Kontextpfad an. Betrachten Sie den folgenden Screenshot:

Wählen Sie die Tomcat-Anmeldeinformationen aus und beachten Sie den obigen Screenshot. Außerdem müssen Sie die URL Ihres Tomcat-Servers angeben.

Um Anmeldeinformationen in Jenkins hinzuzufügen, klicken Sie im Jenkins-Dashboard auf die Option Anmeldeinformationen.

Klicken Sie auf System und wählen Sie globale Anmeldeinformationen aus.

Dann finden Sie eine Option zum Hinzufügen der Anmeldeinformationen. Klicken Sie darauf und fügen Sie Anmeldeinformationen hinzu.

Fügen Sie die Tomcat-Anmeldeinformationen hinzu. Beachten Sie den folgenden Screenshot.

Klicken Sie auf OK.

Fügen Sie nun in Ihrer Projektkonfiguration die Tomcat-Anmeldeinformationen hinzu, die Sie im vorherigen Schritt eingegeben haben.

Klicken Sie auf Speichern und wählen Sie dann Jetzt erstellen.

Gehen Sie zu Ihrer Tomcat-URL mit dem Kontextpfad, in meinem Fall http: // localhost: 8081. Fügen Sie nun am Ende den Kontextpfad hinzu. Beachten Sie den folgenden Screenshot:

Link - http: // localhost: 8081 / gof

Ich hoffe, Sie haben die Bedeutung des Kontextpfads verstanden.

Erstellen Sie nun eine Pipeline-Ansicht. Betrachten Sie den folgenden Screenshot:

Klicken Sie auf das Plus-Symbol, um eine neue Ansicht zu erstellen.

Konfigurieren Sie die Pipeline wie gewünscht. Beachten Sie den folgenden Screenshot:

Ich habe nichts außer der Auswahl des ersten Jobs geändert. Meine Pipeline beginnt also mit dem Kompilieren. Basierend auf der Art und Weise, wie ich andere Jobs konfiguriert habe, werden nach dem Kompilieren Tests und die Bereitstellung erfolgen.

Schließlich können Sie die Pipeline testen, indem Sie auf RUN klicken. Wenn sich der Quellcode alle fünf Minuten ändert, wird die gesamte Pipeline ausgeführt.

So können wir unsere Anwendung kontinuierlich auf dem Testserver für den User Acceptance Test (UAT) bereitstellen.

Ich hoffe, Ihnen hat das Lesen dieses Beitrags zu Continuous Delivery gefallen. Wenn Sie irgendwelche Zweifel haben, können Sie diese gerne in den Kommentarbereich unten einfügen. Ich werde Ihnen frühestens eine Antwort geben.

Um CI / CD-Pipelines zu erstellen, müssen Sie eine Vielzahl von Fähigkeiten beherrschen Meistern Sie jetzt die erforderlichen DevOps-Fähigkeiten