Kapitel 1 Was ist Jenkins?
Jenkins ist eine skalierbare, kontinuierliche Integrations-Engine.
Verwendet hauptsächlich für:
- Kontinuierlich und automatisch Softwareprojekte bauen/testen.
- Ich Beobachte einige Aufgaben, die regelmäßig ausgeführt werden.
Zu den Merkmalen, die Jenkins besitzt, gehören:
- Einfach zu installieren – einfach jenkins.war auf einen Servlet-Container ohne Datenbankunterstützung bereitstellen.
- L Einfach zu konfigurieren – alle Konfigurationen werden über die von ihm bereitgestellte Weboberfläche erreicht.
- l Integriertes RSS/E-Mail veröffentlicht Build-Ergebnisse per RSS oder Benachrichtigungen per E-Mail, wenn der Build abgeschlossen ist.
- Ich erstelle JUnit/TestNG-Testberichte.
- l Distributed Build-Unterstützung Jenkins ermöglicht es mehreren Maschinen, gemeinsam zu bauen/testen.
- l Dateierkennung: Jenkins kann verfolgen, welche jars von welchem Build generiert werden, welche JAR-Version von welchem Build verwendet wird usw.
- l Plugin-Unterstützung: Erweiterungen werden unterstützt, sodass du Tools entwickeln kannst, die auf die Nutzung deines Teams zugeschnitten sind.
1 Ursprung von Jenkins
Kontinuierliche Integration (CI) ist für viele Softwareentwicklungsteams zu einer gängigen Praxis geworden, die sich darauf konzentrieren, die Codequalität während des gesamten Softwareentwicklungslebenszyklus sicherzustellen. Es handelt sich um eine Praxis, die darauf ausgelegt ist, den Softwarebauprozess zu erleichtern und zu festigen. Und es kann Ihrem Entwicklungsteam helfen, Herausforderungen wie Folgendes zu meistern:
- l Software-Build-Automatisierung: Nach Abschluss der Konfiguration baut das CI-System die Zielsoftware gemäß dem vorgegebenen Zeitplan oder für ein bestimmtes Ereignis.
- l Nachhaltige automatisierte Überprüfungen aufbauen: Das CI-System kann kontinuierlich neuen oder modifizierten Check-in-Quellcode abrufen, das heißt, wenn das Softwareentwicklungsteam den neuen oder modifizierten Code regelmäßig überprüfen muss, bestätigt das CI-System ständig, ob der neue Code den erfolgreichen Aufbau der Originalsoftware gestört hat. Das reduziert die Zeit und den Aufwand, die Entwickler aufwenden, um Änderungen in ihrem voneinander abhängigen Code zu überprüfen (um es klar zu sagen, hehe).
- l Nachhaltige automatisierte Tests bauen: Erstellen Sie einen erweiterten Teil der Überprüfung, führen Sie nach der Erstellung einen vordefinierten Satz von Testregeln aus und lösen nach Abschluss Benachrichtigungen (E-Mail, RSS usw.) an die relevanten Parteien aus.
- l Automatisierung nachfolgender Prozesse nach der Erzeugung: Wenn automatisierte Prüfungen und Tests erfolgreich abgeschlossen wurden, können zusätzliche Aufgaben im Software-Build-Zyklus erforderlich sein, wie das Erstellen von Dokumentation, das Paketieren von Software und das Bereitstellen von Komponenten in einem Laufzeit- oder Softwarerepository. Dadurch können die Komponenten den Nutzern schneller zur Verfügung gestellt werden.
- Die Mindestanforderungen für die Bereitstellung eines CI-Systems sind ein Repository mit verfügbarem Quellcode und ein Projekt mit Build-Skripten.
Das folgende Diagramm fasst die Grundstruktur eines CI-Systems zusammen:
Die Komponenten des Systems funktionieren in folgender Reihenfolge:
1. Der Entwickler checkt den Code in das Quellcode-Repository ein.
2. Das CI-System erstellt für jedes Projekt einen separaten Arbeitsbereich. Wenn ein neuer Build voreingestellt oder angefordert wird, speichert er den Quellcode aus dem Quellcode-Repository im entsprechenden Arbeitsbereich.
3. Das CI-System führt den Build-Prozess im entsprechenden Arbeitsbereich aus.
4. (Wenn eine Konfiguration existiert) Sobald der Build abgeschlossen ist, führt das CI-System eine definierte Reihe von Tests in einem neuen Artefakt durch. Lösen Sie Benachrichtigungen (E-Mail, RSS usw.) an die zuständigen Parteien nach Abschluss aus.
5. (Konfiguration, falls vorhanden) Wenn der Build erfolgreich ist, wird dieses Artefakt paketiert und an ein Deployment-Ziel (z. B. Anwendungsserver) übertragen oder als neue Version im Software-Repository gespeichert. Ein Software-Repository kann Teil eines CI-Systems oder eines externen Repositorys sein, wie zum Beispiel ein Dateiserver oder eine Website wie Java.net, SourceForge usw.
6. Das CI-System initiiert in der Regel entsprechende Aktionen basierend auf Anfragen, wie sofortige Builds, das Erstellen von Berichten oder das Abrufen einiger gebauter Artefakte.
Jenkins ist eines dieser CI-Systeme. Früher bekannt als Hudson.
Hier sind einige Gründe, Jenkins zu verwenden:
- Es ist am einfachsten zu installieren und zu konfigurieren unter allen CI-Produkten.
- l Basierend auf Webzugang ist die Benutzeroberfläche sehr freundlich, intuitiv und flexibel und liefert in vielen Fällen sofortiges Feedback von AJAX.
- l Jenkins wird auf Java entwickelt (was sehr nützlich ist, wenn man Java-Entwickler ist), beschränkt sich aber nicht auf den Bau von Java-basierter Software.
- Jenkins hat eine große Anzahl von Plugins. Diese Plugins erweitern die Funktionalität von Jenkins erheblich; Sie sind alle Open Source und können direkt über die Weboberfläche installiert und verwaltet werden.
1.1 Jenkins' Ziele
Jenkins' Hauptziel ist es, den Softwareentwicklungsprozess zu überwachen und Probleme schnell aufzudecken. Dadurch kann sichergestellt werden, dass Entwickler und entsprechendes Personal Zeit und Aufwand sparen und die Entwicklungseffizienz verbessern.
Die Hauptaufgabe des CI-Systems während des gesamten Entwicklungsprozesses ist die Kontrolle: Wenn das System eine Änderung im Code-Repository erkennt, delegiert es die Aufgabe, den Build auszuführen, an den Build-Prozess selbst. Wenn der Build fehlschlägt, informiert das CI-System die betreffende Person und überwacht anschließend weiterhin das Repository. Seine Figuren wirken als passiv; Aber es spiegelt das Problem schnell wider.
Insbesondere hat sie folgende Vorteile:
- L Jenkins Alle Konfigurationen können über die Weboberfläche durchgeführt werden. Einige Konfigurationen wie MAVEN_HOME und E-Mail müssen nur einmal konfiguriert werden, und alle Projekte können genutzt werden. Natürlich kann sie auch durch Modifikation des XML konfiguriert werden.
- l Module, die Maven unterstützen, Jenkins hat Maven optimiert, sodass es Module automatisch erkennt und jedes Modul als Job konfiguriert werden kann. Ziemlich flexibel.
- l Aggregation von Testberichten, die Testberichte aller Module werden zusammengefasst, und die Ergebnisse sind auf einen Blick mit anderen CIs klar, was eine nahezu unmögliche Aufgabe ist.
- Im Artefakt-Fingerabdruck wird das Ergebnis jedes Builds gut automatisch verwaltet und kann problemlos durchsucht und heruntergeladen werden, ohne jegliche Konfiguration.
|
Veröffentlicht am 22.11.2018 09:59:36
|
|
|
|
