Das ultimative Toolkit für die kontinuierliche Bereitstellung (Deployment)

Die Einführung von Software in die Produktion kann eine Herausforderung sein. Oft ist die Häufigkeit der Einführung in die Produktion gering und die Anzahl der Änderungen/Features hoch. Dies führt in der Regel zu einem langen und mühsamen Einführungsprozess. Die Version enthält wahrscheinlich so viele Änderungen wie möglich, denn wenn Sie Ihre Änderung/Funktion in dieser Version nicht erhalten, kann die nächste Version durchaus in 6 - 12 Monaten erscheinen. Um die Illusion zu erwecken, dies verhindern zu können und mehr Kontrolle zu haben, wird die Bereitstellungsabteilung oft mit riesigen, mehr als 100-seitigen Bereitstellungsleitfäden konfrontiert, in denen der Bereitstellungsprozess in zahlreichen, meist manuellen Schritten beschrieben wird. In der neu installierten Software treten Zwischenfälle auf. Da es in der neuen Version so viele Änderungen gab, wie sollen wir da herausfinden, welcher Teil der neu installierten Software das Problem verursacht.

Wenn es weh tut, machen Sie es öfter.

Seit kurzem gibt es ein Phänomen namens Continuous Delivery, das verspricht, sich um die in der Einleitung beschriebenen Problembereiche zu kümmern. Eine häufig gehörte Aussage in der Continuous-Delivery-Szene lautet : "Wenn es weh tut, mach es öfter". Mit anderen Worten: Continuous Delivery kann auf folgende Weise erreicht werden: # Update apache website every 10 minutes */10 * * * * cd /wwwroot/www.myFancyWebSite.com && git pull && service apache restart Erledigt! Das war doch ganz einfach, oder? Nun, wahrscheinlich nicht ganz das, wonach Sie gesucht haben. Die Aussage bezieht sich darauf, die Anzahl der Änderungen in einer Version auf ein absolutes Minimum zu reduzieren und so oft wie möglich automatisiert zu veröffentlichen. Mit anderen Worten: "Code versenden, sobald er fertig ist". Die nächste Frage ist natürlich: Wann ist eine Software bereit, in Produktion zu gehen? Der Schlüssel dazu ist: Kurze Rückkopplungsschleifen und nur bei Bedarf testen.

• Kurze Rückkopplungsschleifen
  • Geben Sie dem Entwickler so schnell wie möglich Feedback zu dem Code, den er eingecheckt hat, z.B. indem Sie einen regelmäßigen Build durchführen, der alle x Stunden bis hin zu jedem Commit laufen kann.
• Nur bei Bedarf testen
  • Wenn der Code, der übergeben wurde, nicht dem Standard X entspricht (z.B. Standard-Codeprüfung oder der Code lässt sich nicht kompilieren), brauchen Sie den Test Y nicht durchzuführen.
• Organisieren Sie Ihre Tests so, dass die billigen (in Bezug auf den Zeitaufwand für den Test oder die eingesetzten Ressourcen) Tests zuerst durchgeführt werden und dann die teureren Tests folgen. Zum Beispiel:
  • Wenn der Code nicht kompiliert werden kann, brauchen Sie die Unit-Tests nicht auszuführen.
  • Wenn die Unit-Tests fehlschlagen, brauchen Sie die Funktionstests nicht auszuführen.
  • Wenn die funktionalen Tests fehlschlagen, brauchen Sie die Integrationstests nicht durchzuführen.
  • Wenn die Integrationstests fehlschlagen, brauchen Sie die Lasttests nicht durchzuführen.

Das bringt uns zu einer wichtigen Frage: Wann ist die Software bereit, in Betrieb zu gehen? Organisieren Sie Ihren kontinuierlichen Bereitstellungsprozess so, dass die Software, wenn sie alle Tests bestanden hat, bereit ist, in die Produktion zu gehen. Dies führt zu einer Vielzahl von Go-Live-Momenten mit Vorteilen wie:

• Nur eine kleine Anzahl von Änderungen geht gleichzeitig in die Produktion. Im Falle von Problemen schränkt dies Ihre Möglichkeiten zur Fehlersuche ein.
• Wenn Sie mehrmals mit kleinen Änderungen live gehen, können Ihre Kunden die Fortschritte besser nachvollziehen.

Es gibt einige Unternehmen, die ihren Softwarebereitstellungsprozess in eine kontinuierliche Bereitstellung umgewandelt haben. Ein Unternehmen, das ich besonders hervorheben möchte, ist flickr. Sie haben sogar eine Website, auf der sie ihre jüngsten Bereitstellungsaktivitäten zeigen

Werkzeuge des Handwerks

Im Moment sind meine bevorzugten Tools für die Einrichtung einer kontinuierlichen Bereitstellung:

• git
• jenkins
• maven
• Sonar
• nexus
• Deployit

Cool, ich will das auch!

Für das obige Setup habe ich das folgende Kochbuch kompiliert, das nach Fertigstellung zu einem 64-Bit CentOS 5.8 vm führt, auf dem die folgenden Dienste laufen:

• git
• jenkins
• maven
• Sonar
• jbossas

Die Komponenten werden nach diesem Schema verdrahtet

Voraussetzungen

Erstellen Sie eine vm mit den folgenden Spezifikationen:

• 2 GB Arbeitsspeicher
• 5 GB Festplatte

HINWEIS: Dieser Blogpost setzt voraus, dass der vm über einen Internetzugang verfügt.

Die VM zum Laufen bringen

Da ich es vorziehe, die Dinge kurz und bündig zu halten, wird für diesen Blogpost ein minimales 64-Bit CentOS 5.8 mit dem net-installer installiert. In den folgenden neun Schritten erhalten Sie eine vm, die Sie in diesem Kochbuch verwenden können.

1. Starten Sie Ihren leeren vm, indem Sie von der angehängten CentOS net installer iso booten.
2. Für Sprache und/oder Tastaturtyp: Akzeptieren Sie die Standardeinstellungen oder ändern Sie sie so, wie es Ihrer Umgebung entspricht.
3. Die Installationsmethode ist natürlich http.
4. tcp/ip-Konfiguration: je nach den Bedürfnissen Ihres lokalen Netzwerks für den Internetzugang.
5. Wählen Sie einen Mirror-Dienst von der CentOS-Website.
   • Geben Sie den Namen der Website an: my.fast.mirror.com
   • CentOS-Verzeichnis: path/to/5.8/os/x86_64
6. Klicken Sie auf dem Willkommensbildschirm auf Weiter und wählen Sie eine Neuinstallation von CentOS.
7. Partitionieren Sie Ihre Festplatte nach Ihren Bedürfnissen. Dieses Kochbuch geht von einer Gesamtgröße der Festplatte von 5 GB aus, aufgeteilt in 1 GB für den Swap-Bereich und 4 GB für den Speicherbereich.
8. Netzwerkeinrichtung: Stellen Sie sicher, dass Sie einen Hostnamen festlegen und die nötigen Konfigurationen vornehmen, damit Ihr vm in Ihr Netzwerk passt und eine Internetverbindung besteht.
9. Schließen Sie die Installation ab, indem Sie Ihre Zeitzone auswählen, Ihr Root-Passwort eingeben und alle Installationsaufgaben abwählen, einschließlich der Standardauswahl "Desktop - Gnome".

Lassen Sie das Installationsprogramm seine Arbeit machen. Sobald das System neu gestartet ist, haben Sie eine frische 64-Bit-Centos 5.8-VM zur Verfügung.

Aktionen nach der Installation

• Aktualisieren Sie Ihr System: Installieren Sie ausstehende CentOS-Updates, indem Sie: "yum update"
• Konfiguration der Hosts-Datei: Stellen Sie sicher, dass Ihre /etc/hosts-Datei einen separaten Eintrag für Ihren Hostnamen und Ihre aktuelle IP-Adresse enthält (vergessen Sie nicht, den aktuellen Hostnamen aus dem Eintrag für den lokalen Loopback-Adapter (localhost) zu entfernen). Grundsätzlich sollte Ihre /etc/hosts-Datei die folgenden beiden Zeilen enthalten
  • 127.0.0.1 localhost
  • [yourLocalIp] [yourHostname]
• Neustart

Verfahren zur Installation

Aufgrund eines bekannten Kompatibilitätsproblems mit dem Paket jpackage-utils zwischen dem Standard-Centos-Repository und dem jpackage-Repository ist es wichtig, dass Sie die folgenden Schritte in der beschriebenen Reihenfolge durchführen. yum install jpackage-utils java-devel Um die restlichen Pakete installieren zu können, müssen wir die folgenden Repositories hinzufügen:

• jpackage (benötigt für jboss)
• epel (benötigt für git und git-daemon)
• jenkins
• Sonar

Sie können die oben genannten Repositories hinzufügen, indem Sie eine Datei namens /etc/yum.repos.d/cicd.repo mit folgendem Inhalt erstellen: [jpackage-generic] name=JPackage generic mirrorlist=https://www.jpackage.org/mirrorlist.php?dist=generic&type=free&release=5.0 gpgcheck=0 [jpackage-generic-updates] name=JPackage generic - updates mirrorlist=https://www.jpackage.org/mirrorlist.php?dist=generic&type=free&release=5.0-updates gpgcheck=0 [epel] name=Extra Packages for Enterprise Linux 5 - $basearch mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch gpgcheck=0 [jenkins] name=Jenkins baseurl=https://pkg.jenkins-ci.org/redhat gpgcheck=0 [sonar] name=Sonar baseurl=https://downloads.sourceforge.net/project/sonar-pkg/rpm gpgcheck=0 Nach dem Hinzufügen neuer Repositories habe ich die Angewohnheit, den Cache des yum-Repositories zu bereinigen yum clean all Der nächste Schritt ist die Installation von jboss mit dem folgenden Befehl (der Parameter disablerepo wird verwendet, um das bereits erwähnte Kompatibilitätsproblem zu umgehen): yum install --disablerepo=base,updates,extras jbossas Jetzt, wo der Anwendungsserver (jboss) installiert ist, können wir den Rest des Toolkits mit folgendem Befehl installieren: yum install git git-daemon jenkins sonar subversion.x86_64 Um sicherzustellen, dass jboss sich an die richtige Schnittstelle bindet (um den Zugriff von außerhalb der VM zu ermöglichen), führen Sie Folgendes aus echo "JBOSS_IP=`hostname`" >> /etc/sysconfig/jbossas Um Portkonflikte im weiteren Verlauf dieses Kochbuchs zu vermeiden, ändern Sie die Konfiguration des jenkins-Netzwerkports wie folgt Ändern Sie den Listenport: sed -i 's/JENKINS_PORT="8080"/JENKINS_PORT="8180"/g' /etc/sysconfig/jenkins Ändern Sie den AJP-Port: sed -i 's/JENKINS_AJP_PORT="8009"/JENKINS_AJP_PORT="8109"/g' /etc/sysconfig/jenkins Um sicherzustellen, dass der git-daemon mit xinetd startet, müssen wir ipv6 für den git-daemon wie folgt deaktivieren: sed -i 's/flags/#flags/g' /etc/xinetd.d/git Um sicherzustellen, dass der Git-Daemon Pushes vom Client erhält, müssen wir receive-pack wie folgt aktivieren: sed -i 's/export-all/export-all --enable=receive-pack/g' /etc/xinetd.d/git Stellen Sie nun sicher, dass der git-Daemon mit xinetd gestartet wird: chkconfig git on chkconfig jbossas on Starten Sie den Git-Daemon, Jenkins und Sonar service jbossas start service xinetd start service jenkins start service sonar start Fügen Sie Firewall-Regeln für die laufenden Dienste hinzu iptables -I INPUT -p tcp --dport 8080 -j ACCEPT iptables -I INPUT -p tcp --dport 8180 -j ACCEPT iptables -I INPUT -p tcp --dport 9000 -j ACCEPT iptables -I INPUT -p tcp --dport 9418 -j ACCEPT

Git-Repository erstellen

Dieses Kochbuch setzt ein Git-Repository mit dem Namen petclinic voraus. Um dieses Git-Repository auf dem Git-Server auf unserem vm zu erstellen, gehen Sie wie folgt vor cd /var/lib/git/ git init --bare petclinic chown -R nobody:nobody petclinic Nach der Ausführung des Befehls "git init" sollte der Server mit der folgenden Meldung geantwortet haben: "Initialisiertes leeres Git-Repository in /var/lib/git/petclinic/"

Entwickler-Setup

In unserem Anwendungsfall haben wir einen Serverteil und einen Entwicklerteil. Wir sind nun bereit, den Entwicklerarbeitsbereich zu konfigurieren. Dazu klonen wir ein Git-Repository, füllen es mit Quellcode und übertragen diesen zurück auf den Git-Server. In diesem Kochbuch wird davon ausgegangen, dass sich der Entwickler mit einem separaten Entwicklerkonto auf der vm anmeldet (in diesem Blogpost wird der Benutzername dev verwendet). Wenn das Entwicklerkonto (dev) noch nicht existiert, erstellen Sie es bitte jetzt. Melden Sie sich als Benutzer dev an und erstellen Sie ein Arbeitsverzeichnis, von dem aus der Entwickler seine Arbeit am Git-Repository verrichten kann, in diesem Blogpost heißt das Arbeitsverzeichnis mywork. Klonen Sie aus dem Verzeichnis mywork das leere Git-Repository wie folgt: git clone git://localhost/petclinic Sie erhalten wahrscheinlich eine Warnung wie "Warnung: Sie scheinen ein leeres Repository geklont zu haben.". In diesem Fall können Sie diese Warnung getrost ignorieren. Wechseln Sie nun in das Repository-Verzeichnis und vergewissern Sie sich, dass es nur ein .git-Verzeichnis im petclinic-Verzeichnis gibt. Unsere Demonstrationsanwendung ist die bekannte petclinic-Anwendung, die wir aus dem Subversion-Repository von springframework.org beziehen. Führen Sie im petclinic-Verzeichnis (dem Verzeichnis mit dem .git-Verzeichnis) den folgenden Befehl aus: svn export https://src.springframework.org/svn/spring-samples/petclinic/trunk petclinic-web Da sich die petclinic-Anwendung nun in unserem Repository befindet, müssen wir ein root-pom erstellen, um den Build-Prozess in Gang zu setzen. In diesem Root-Pom verweisen wir auf die pom.xml im Verzeichnis petclininc-web und fügen das jboss-Plugin und seine Konfiguration für die direkte Bereitstellung auf unserem Anwendungsserver hinzu. Gehen Sie zum Verzeichnis mywork/petclinic und fügen Sie eine Root-pom.xml mit dem folgenden Inhalt hinzu: <project> <modelVersion>4.0.0</modelVersion> <groupId>org.springframework.samples</groupId> <artifactId>org.springframework.samples.petclinic-root</artifactId> <name>petclinic-root</name> <version>1</version> <packaging>pom</packaging> <modules> <module>petclinic-web</module> </modules> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jboss-maven-plugin</artifactId> <version>1.5.0</version> <configuration> <hostName>cicd</hostName> <port>8080</port> <fileNames> <fileName>${project.basedir}/petclinic-web/target/petclinic.war</fileName> </fileNames> </configuration> </plugin> </plugins> </build> </project> Als nächstes fügen Sie den gesamten Code zum Repository hinzu, übertragen den Code und pushen ihn auf den Git-Server git add . git commit -m "Initial commit" git push origin master

Jenkins Konfiguration

Installieren Sie zunächst die entsprechenden Jenkins-Plugins java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s https://xebia.com/blog:8180 install-plugin git java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s https://xebia.com/blog:8180 install-plugin sonar Starten Sie Jenkins neu, um die Plugins zu aktivieren service jenkins stop service jenkins start Öffnen Sie die Jenkins-Konsole. In diesem Kochbuch gehen wir davon aus, dass die Jenkins-Konsole auf Port 8180 lauscht. Gehen Sie zu "Jenkins verwalten" -> "System konfigurieren". Im Abschnitt JDK:

• Klicken Sie auf "JDK hinzufügen".
• Geben Sie einen JDK-Namen ein, zum Beispiel: jdk16
• Deaktivieren Sie "Automatisch installieren".
• Geben Sie als JAVA_HOME ein: /usr/lib/jvm/java-1.6.0-openjdk.x86_64

Im Abschnitt Maven:

• Klicken Sie auf die Schaltfläche "Maven hinzufügen".
• Geben Sie einen Maven-Namen ein, zum Beispiel: mvn3
• Lassen Sie "Automatisch installieren" aktiviert
• Wählen Sie die aktuellste Version aus dem Dropdown-Feld "Von Apache installieren".

In der Sektion Sonar:

• Klicken Sie auf "Sonar hinzufügen".
• Geben Sie einen Namen ein, zum Beispiel: sonar

Klicken Sie auf "Speichern" am unteren Rand des Bildschirms, um Ihre Änderungen zu bestätigen. Erstellen Sie einen neuen (petclinic) Bauauftrag

• Geben Sie einen Namen für den Bauauftrag an, zum Beispiel: petclinic
• Wählen Sie "Ein Maven 2/3 Projekt erstellen".
• Drücken Sie OK
• Im Abschnitt "Quellcodeverwaltung" wählen Sie Git
• Geben Sie die Repository-URL ein, zum Beispiel: git://localhost/petclinic
• Im Abschnitt "Build" geben Sie in das Feld "Ziel und Optionen" "clean install jboss:redeploy" ein.
• Klicken Sie im Abschnitt "Erstellen" auf die Schaltfläche "Erweitert". Fügen Sie "-Dmaven.test.failure.ignore=false" zum Feld "MAVEN_OPTS" hinzu (damit wird der Erstellungsprozess angehalten, wenn ein Unit-Test fehlschlägt)
• Wählen Sie im Abschnitt "Post-Build-Aktionen" aus dem Dropdown-Feld "Post-Build-Aktion hinzufügen" die Option "Sonar".
• Klicken Sie auf "Speichern".
• Starten Sie die Erstellung, indem Sie auf "Jetzt erstellen" klicken.
• Im Abschnitt "Build History" erscheint der neu geplante Build, klicken Sie ihn an
• Klicken Sie auf "Konsolenausgabe", um den Fortschritt des Build-Prozesses zu überwachen

Konfigurieren Sie den Git-Server so, dass er einen Jenkins-Auftrag startet, nachdem eine Änderung auf den Server übertragen wurde echo "curl -s https://cicd:8180/job/petclinic/build" > /var/lib/git/petclinic/hooks/post-receive chmod +x /var/lib/git/petclinic/hooks/post-receive chown nobody:nobody /var/lib/git/petclinic/hooks/post-receive

Aktualisieren Sie Ihren Quellcode

Jetzt können Sie selbst sehen, wie das funktioniert. Ein guter Test für den Anfang ist es, etwas zu aktualisieren, das vom Webbrowser aus sofort zu sehen ist. Zum Beispiel den Titel in der Titelleiste. Um diesen zu aktualisieren, aktualisieren Sie die Datei petclinic-web/src/main/webapp/WEB-INF/jsp/header.jsp vi petclinic-web/src/main/webapp/WEB-INF/jsp/header.jsp git add petclinic-web/src/main/webapp/WEB-INF/jsp/header.jsp git commit -m "Updated version number" git push Der Befehl "git push" sollte den Jenkins-Build-Prozess auslösen, der wiederum Maven startet, das die Anwendung (nach erfolgreicher Erstellung und Prüfung) in der Entwicklungsumgebung bereitstellt. Dies dauert in der Regel etwa vier Minuten. Öffnen Sie die Jenkins-Konsole (dieses Kochbuch geht davon aus, dass Jenkins auf Port 8180 läuft), um den Build-Prozess zu überwachen. Um zu sehen, was genau passiert, zoomen Sie einfach auf einen laufenden Job und wählen Sie "Konsolenausgabe" Bitte zögern Sie nicht, ein Stück fehlerhaften (nicht kompilierenden) Code zu committen oder sogar einen Junit-Test absichtlich zu brechen, Sie werden feststellen, dass der gesamte Prozess zum Stillstand kommt, was die geschossenen Feedbackschleifen erleichtert. Der Entwickler weiß Minuten nach dem Commit, ob er etwas kaputt gemacht hat.

Aber warten Sie, es gibt noch mehr!

Wenn Sie so weit gekommen sind, haben Sie jetzt wahrscheinlich ein kontinuierliches Bereitstellungssystem auf Ihrer VM laufen. Das Problem dabei ist, dass es nur in der Lage ist, immer wieder dieselbe Bereitstellung durchzuführen. Das bedeutet, dass die bereitzustellende Datei (in diesem Fall eine .war-Datei) in verschiedenen Umgebungen immer dieselbe ist, auch wenn die umgebungsspezifischen Parameter nicht identisch sind. Ein weiteres Problem besteht darin, dass Sie bei dieser Konfiguration nur in einem vordefinierten Teil der Umgebung deployen können und keine Ahnung vom Rest Ihrer Umgebung haben, z.B. von Abhängigkeiten mit anderen Systemen. Um dieses Problem zu lösen, bevorzuge ich ein Tool namens Deployit von xebialabs. Die Abbildung zeigt, wo Deployit in der Landschaft eingesetzt wird Deployit stellt Anwendungen automatisch in Middleware- und Cloud-Umgebungen bereit. Schnell. Zuverlässig. Kosteneffiziente Implementierungen - selbst in komplexen Multi-Tier-Umgebungen Der Lebenszyklus von Anwendungsreleases ist unnötig komplex, manuell und zeitaufwändig und bringt Unternehmen durch seine Schwerfälligkeit in eine schwache Position. Dieser sehr kritische Prozess bestimmt, wie schnell ein Unternehmen Produkte auf den Markt bringen kann, und ist dennoch komplex, fehleranfällig und voller Engpässe. Ein optimierter Anwendungsfreigabeprozess bringt Produkte nachweislich schneller auf den Markt, stärkt die gesamte Produkt-Roadmap und ermöglicht es dem Unternehmen, Jahr für Jahr besser auf Marktanforderungen zu reagieren. Application Release Automation verändert die Art und Weise, wie diese großen Unternehmen Anwendungen in Middleware- und Cloud-Umgebungen bereitstellen. Der Prozess der Anwendungsfreigabe bestimmt, wie schnell ein Unternehmen Produkte auf den Markt bringen kann, und ist dennoch komplex, fehleranfällig und voller Engpässe. Ein optimierter Bereitstellungsprozess führt nachweislich dazu, dass Produkte schneller auf den Markt kommen, die gesamte Produkt-Roadmap gestärkt wird und das Unternehmen besser auf die Anforderungen des Marktes reagieren kann. Deployit ist eine Self-Service-Automatisierungsplattform für die Anwendungsfreigabe, die die Bereitstellung von Anwendungskomponenten (Webinhalte, EAR- und WAR-Dateien, Konfigurationsdateien, Datenquellen, Themen und Warteschlangen usw.) in Middleware- und Cloud-Umgebungen automatisiert, einschließlich Anwendungsservern, Webservern, Datenbanken, Messaging-Engines und vielen anderen. Deployit reduziert Bereitstellungsfehler, erhöht die Bereitstellungsgeschwindigkeit und gewährleistet einen kosteneffizienten, nachvollziehbaren und wartbaren Bereitstellungsprozess für alle Ihre Unternehmensbereitstellungen. Deployit verändert die Art und Weise, wie Unternehmen Anwendungen bereitstellen, indem es die Notwendigkeit manueller Konfigurationen, traditioneller Skripte und unnötiger Prozessengpässe beseitigt. Ein Deployit-Benutzer kann einfach vorgefertigte Pakete in Deployit hochladen, die Pakete Umgebungen zuordnen und die AutoFlow Engine von Deployit kümmert sich um den Rest. Value of Deployment Automation for Continuous Delivery:

• Die Automatisierung der Bereitstellung ist von zentraler Bedeutung für die kontinuierliche Bereitstellung
• Einbindung in Build- und Continuous-Integration-Werkzeuge
• Unterstützung gesicherter Lieferpipelines durch Sicherheit
• Integration mit Release Management für Governance
• Auditing & Rückverfolgbarkeit
• Was wird wo eingesetzt = Visualisierung Ihrer Lieferpipeline

Der Wert von Deployment Automation für DevOps:

• Fügen Sie die Bereitstellung der Anwendungsebene zur Umgebungsbereitstellung hinzu, z. B. mit Puppet oder Chef
• Automatisierte Skalierung von Anwendungen
• Automatische Abhilfe/Downgrade ausgelöst durch Überwachung
• Wendet das modellbasierte Paradigma des "de facto DevOps-Standards" auf Anwendungen für extreme Skalierbarkeit an

Damit sich Deployit anmelden kann, aktivieren Sie die Anmeldung (vergessen Sie nicht, ein Passwort anzugeben) des jboss linux-Benutzers: usermod -s /bin/sh jboss Ohne zu sehr ins Detail zu gehen, muss ich in Deployit im Wesentlichen die folgende Konfiguration vornehmen, um es auf seine Aufgabe vorzubereiten sshhost erstellen jbossinstance erstellen Umgebung erstellen Als Nächstes müssen Sie Jenkins so konfigurieren, dass es nicht zu jboss deployt. Öffnen Sie in der Jenkins-Konsole das Projekt petclinic und wählen Sie "Configure" Im Abschnitt "Build" entfernen Sie "jboss:redeploy" aus dem Feld "Goal and options". Es sollte nur lauten: "clean install" Als letzten Schritt müssen wir den Maven-Build aktualisieren. Melden Sie sich als der zuvor erstellte Linux-Dev-Benutzer an und wechseln Sie in das zuvor erstellte Verzeichnis mywork/petclinic. Erstellen Sie ein neues Verzeichnis (ist ein Projekt) mit dem Namen petclinic-dar, dies ist das Projekt, das den dar enthalten wird. Erstellen Sie eine Datei mit dem Namen pom.xml mit dem folgenden Inhalt: <project> <modelVersion>4.0.0</modelVersion> <groupId>org.springframework.samples</groupId> <artifactId>petclinic</artifactId> <name>petclinic-dar</name> <version>1.0-SNAPSHOT</version> <packaging>dar</packaging> <build> <plugins> <plugin> <groupId>com.xebialabs.Deployit</groupId> <artifactId>maven-Deployit-plugin</artifactId> <version>3.7.1</version> <extensions>true</extensions> <executions> <execution> <id>Deployit-plugin-test</id> <phase>install</phase> <goals> <goal>deploy</goal> </goals> </execution> </executions> <configuration> <environmentId>Environments/myDevEnv</environmentId> <username>admin</username> <password>admin</password> <deployables> <deployable> <name>petclinic</name> <type>jee.War</type> <groupId>org.springframework.samples</groupId> <artifactId>org.springframework.samples.petclinic</artifactId> </deployable> </deployables> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>org.springframework.samples</groupId> <artifactId>org.springframework.samples.petclinic</artifactId> <version>1.0.0-SNAPSHOT</version> <type>war</type> <scope>provided</scope> </dependency> </dependencies> </project> Auch das Root-Pom des Projekts muss aktualisiert werden, das jboss-Plugin muss weg und das dar-Projekt muss hinzugefügt werden. Die neue root pom.xml sieht wie folgt aus: <project> <modelVersion>4.0.0</modelVersion> <groupId>org.springframework.samples</groupId> <artifactId>org.springframework.samples.petclinic-root</artifactId> <name>petclinic-root</name> <version>1.0</version> <packaging>pom</packaging> <modules> <module>petclinic-web</module> <module>petclinic-dar</module> </modules> </project> Führen Sie nun die gleichen Aktualisierungstests wie zuvor durch und sehen Sie, wie es funktioniert. Für diejenigen Leser, die keinen Zugang zu einer Deployit-Installation haben, schauen Sie sich bitte die Links in diesem Blogpost an und werfen Sie einen Blick auf diesen Screenshot, der die Deployit-Konsole nach einer erfolgreichen Bereitstellung zeigt.