Skripterstellung für Deployit, Teil 2

Wie jede Software sollten auch Deployit-Plugins automatisch erstellt, bereitgestellt und getestet werden, wann immer dies möglich ist. Im Folgenden erkläre ich Ihnen, wie Sie eine kontinuierliche Integration und Tests für Deployit-Plugins einrichten. Wenn Sie eine größere Anzahl von Plugins für Deployit erstellen, ist es sinnvoll, diese so oft wie möglich zu erstellen und bereitzustellen, damit Sie Fehler frühzeitig erkennen können. Wir haben festgestellt, dass es sehr einfach ist, Plugins zu erstellen, die für sich genommen gut funktionieren, aber nicht funktionieren, wenn sie zusammen eingesetzt werden. Glücklicherweise ist es auch einfach, diese Art von Fehlern zu erkennen, wie ich weiter unten zeigen werde.

Diese Arbeit ist Teil eines größeren Projekts zur Beschreibung und Erklärung von Deployit. Ich habe einen früheren Blog geschrieben, den Sie hier finden können: Scripting deployit/. Den Code für die Beispiele und Plugins finden Sie auf GitHub: git clone git://github.com/jvermeir/DeployitBlogs.git cd DeployitBlogs git checkout ec6b748. Ich habe mich stark an die Arbeit meines Kollegen Joris de Winne angelehnt. Ich werde ein paar Plugins verwenden, die einen neuen Host-Typ definieren. Sie dienen nur dazu, zu zeigen, wie der Build- und Testprozess funktioniert, also ignorieren Sie bitte ihren Inhalt. Im Quellbaum finden Sie sie im Verzeichnis 'citest/test'. Zu jedem Plugin gehört ein buildAndCopy.sh-Skript, das nichts weiter tut, als eine jar-Datei in das Plugins-Verzeichnis zu kopieren, damit sie von Deployit abgeholt werden kann. Um die Beispiele auszuführen, benötigen Sie eine Shell und wechseln in das Verzeichnis 'citest' in 'DeployitBlogs', das Stammverzeichnis eines Projekts auf GitHub, das ich in einem früheren Beitrag beschrieben habe. Das Build- und Deploy-Skript wird durch die Eingabe von ./basicDeployitStartupTest.sh p1 das eine saubere Installation von Deployit durchführt, das Plugin mit dem Namen p1 kopiert und schließlich Deployit startet, um festzustellen, ob es noch funktioniert. Das Skript protokolliert Meldungen über die einzelnen Schritte, z.B.: findAndTerminateDeployitProces installDeployit copyPluginsFromDistribution buildAndCopyPlugins validate Der erste Schritt besteht darin, einen Deployit-Prozess zu finden und zu beenden, der möglicherweise bereits auf dem Testserver läuft. Dazu wird nach einem Java-Prozess gesucht, der Deployits Hauptklasse com.xebialabs.deployit.DeployitBootstrapper ausführt, und dieser Prozess wird dann beendet. Dies kann natürlich fehlschlagen, so dass Sie später Fehler erhalten. Als nächstes entfernt installDeployit() eine frühere Version und entpackt das Deployit-Serverarchiv. Das Archiv, das ich verwendet habe, ist nicht die Standarddistribution, sondern eine Version, die aus einer bestehenden Installation erstellt wurde. Deployit benötigt einige Antworten, wenn es zum ersten Mal gestartet wird. Ich habe also nur das Installationsprogramm ausgeführt, die Fragen beantwortet, Deployit gestoppt und das gesamte Verzeichnis in eine neue Installationsdatei gepackt, die von der Methode installDeployit() entpackt wird. Damit dieser Schritt funktioniert, müssen Sie also dasselbe tun und die Ergebnisse in $ROOTDIR/resources/deployit-$DEPLOYIT_VERSION-server-setup.zip speichern. Im Skript können Sie nachlesen, wohin die Shell-Variablen zeigen sollen. Der dritte Schritt, copyPluginsFromDistribution(), kopiert alle Standard-Plugins aus dem Verzeichnis available-plugins in das Verzeichnis plugins, damit wir alle Funktionen von Deployit nutzen können. Sie können dies ändern, wenn Sie nicht alle Plugins für Ihren Anwendungsfall benötigen. Die dritte Zeile in dieser Methode verwendet Linux find, um noch mehr Plugins zu kopieren, die weder Teil der Standarddistribution noch Ihres Projekts sind. Ein Beispiel könnte das Weblogic-Plugin sein. Diese Plugins sollten in das Verzeichnis lib unter citest kopiert werden. Der vierte Schritt, buildAndCopyPlugins(), erstellt eine Liste der Plugins, die Sie testen möchten, und kopiert sie in das Plugins-Verzeichnis. Die Funktion nimmt eine durch ein Leerzeichen getrennte Liste von Plugin-Namen in einer Variablen namens $PLUGIN_NAMES entgegen. Anschließend durchläuft sie diese Liste in einer Schleife und ruft ein Skript namens buildAndCopy.sh auf, das sich im Stammverzeichnis jedes Plugins befinden sollte. Die Beispiel-Plugins in test/success zeigen, wie das funktioniert. In der realen Welt könnten Sie einen Jenkins-Build starten, ein Artefakt aus einem Repository kopieren oder Maven aufrufen.Die einzige Anforderung ist, dass ein Build auf der Konsole protokolliert wird und eine Zeile mit dem Text 'BUILD FAILURE' ausgibt, wenn etwas schief geht.Schließlich versucht validate(), Deployit zu starten und wartet darauf, dass die Meldung "You can now point your browser to" im Konsolenprotokoll erscheint. Die Methode prüft eine Minute lang alle 5 Sekunden und meldet das Ergebnis. Zum Experimentieren können Sie die beiden Sätze von Plugins verwenden, die in den Verzeichnissen test/success und test/failure bereitgestellt werden. ./basicDeployitStartupTest.sh p1 setzt ein einzelnes Plugin namens p1 aus test/success ein. Dieser Test sollte einen Erfolg melden. ./basicDeployitStartupTest.sh -p test/failure p1 p2 sollte einen Fehler melden, weil er versucht, dasselbe Plugin zweimal einzusetzen. Das dauert eine Weile, weil der Test ständig nach einer Erfolgsmeldung sucht, aber stattdessen wird ein Fehler protokolliert. Ich denke, hier gibt es noch Raum für Verbesserungen. Wir haben einen Vorgänger dieses Skripts erfolgreich eingesetzt, um ein Projekt mit einer großen Anzahl von Plugins, die viele benutzerdefinierte Typen definieren, im Griff zu behalten. Wir haben das Skript als Jenkins-Job ausgeführt, der durch einen Commit auf Subversion ausgelöst wurde. In unserer Umgebung erwies es sich als nützliches Werkzeug, um Fehler bei der Typdefinition frühzeitig zu erkennen.