OK, noch ein Beitrag für heute... Heute Morgen habe ich Ihnen versprochen, Ihnen zu zeigen, wie Sie Java-Code auf einem Linux-Build-Agent mit dem neuen Build.vNext-Build-System in Visual Studio Online erstellen können. Mit diesem Beitrag möchte ich dieses Versprechen einlösen. Da ich ein Linux- und Java-Neuling bin, dachte ich, es würde eine komplexe Aufgabe sein. Wie sich herausstellte, ist es das nicht. Wenn Sie erst einmal alle Bits an Ort und Stelle haben, macht es das großartige neue Build-System einfach, eine Build-Definition zu erstellen, die den Code kompiliert. Ich habe sogar ein paar Unit-Tests eingefügt und die Testergebnisse in VSO veröffentlicht.
Bevor Sie beginnen, sollten Sie zwei Dinge vorbereiten:
- Ein Linux-Build-Agent, der mit Ihrem VSO-Konto verbunden ist: Erstellen eines Build.vNext-Agenten unter Linux
- Einige Java-Codes in einem Git-Repository auf VSO: Importieren von Java-Code in Git auf Visual Studio Online von Eclipse aus
Struktur des Projekts
Für diesen Beitrag habe ich ein kleines Java-Demoprojekt in Eclipse erstellt. Ich werde nicht auf alle Details eingehen, aber es gibt ein paar Dinge, auf die ich gerne hinweisen möchte:
- Das Projekt verwendet Apache Maven, um den Build-Prozess zu verwalten. Maven wird häufig für Java-Projekte verwendet und die Unterstützung ist in Eclipse sowie in Build.vNext integriert.
- Das Projekt besteht aus einer einfachen "Hello World"-Anwendung. Die Hauptklassendatei ("HelloMavenMain.java") enthält Code, der eine "Hello World"-Nachricht ausgibt und eine Methode, die eine Addition durchführt (die eigentlich nirgendwo verwendet wird).
- Es gibt zwei Unit-Tests für das Projekt, die in der Datei "TestHelloMavenMain.java" definiert sind. Diese Tests werden mit dem JUnit-Framework geschrieben.
Voraussetzungen für den Build-Agent
Wenn Sie meinem Beitrag über die Erstellung eines Build.vNext-Agenten unter Linux gefolgt sind, haben Sie die meisten Bits bereits auf Ihrem Agenten installiert. Wir müssen nur noch einige Tools hinzufügen, die speziell für die Erstellung von Java-Anwendungen erforderlich sind. Erfahrene Java-Entwickler werden dies wissen, aber für alle anderen Entwickler werde ich sie hier erwähnen.
- Java Development Kit (JDK): Dieses Kit enthält die grundlegenden Tools zum Kompilieren Ihres Quellcodes.
- Maven: das Tool, das unseren Build tatsächlich ausführen wird
Sie können beides installieren, indem Sie "sudo apt-get install default-jdk maven" in ein Konsolenfenster eingeben.
Sie werden feststellen, dass Sie eine MENGE an Abhängigkeiten benötigen. Zum Glück ist apt-get da, um sich um die Installation zu kümmern! Geben Sie einfach "Y" ein, um es zu starten.
Wenn Sie eine Tasse Kaffee brauchen, ist jetzt der richtige Zeitpunkt, um ihn zu holen... Nach einer Weile sind alle Abhängigkeiten installiert. Starten Sie nun Ihren Build-Agent neu, damit er die neu installierten Tools erkennt und sie als "Fähigkeiten" für den Build-Dienst registriert.
Wenn Sie sich im VSO-Kontrollzentrum die Eigenschaften Ihres Build-Agenten ansehen, werden Sie feststellen, dass der Agent die neu installierte Maven-Binärdatei erkannt und sie als Fähigkeit für sich selbst registriert hat.
Wir haben jetzt alle Voraussetzungen geschaffen. Fangen wir an zu bauen!
Erstellen der Build-Definition
Die Benutzeroberfläche des Build.vNext-Systems ist vollständig webbasiert. Um also eine Build.vNext-Build-Definition zu erstellen, müssen Sie die Weboberfläche verwenden. Starten Sie also Ihren Browser und verbinden Sie sich mit Ihrem VSO-Konto. Navigieren Sie zu dem Teamprojekt, das Ihren Java-Code enthält, und wechseln Sie zur Registerkarte "Build". Klicken Sie dann auf das grüne "+"-Zeichen, um eine neue Build-Definition zu erstellen.
Es gibt eine Reihe von Vorlagen, die vom VSO-Team für Visual Studio, Xamarin und Xcode Builds vordefiniert wurden. Da wir nichts von alledem tun, beginnen wir mit einem Neuanfang und wählen die Option "Leer".
Dadurch wird eine neue Build-Definition erstellt, die derzeit noch keine Build-Schritte enthält.
Wir beginnen damit, das Repository zu konfigurieren, aus dem wir den Code erstellen möchten. Navigieren Sie zur Registerkarte "Repository" und wählen Sie Ihren Repository-Typ sowie Ihr Repository und Ihren Zweig aus. Außerdem habe ich "Clean = true" angegeben, damit das Arbeitsverzeichnis des Agenten vor jedem Build bereinigt wird.
Auf der Registerkarte "Allgemein" legen Sie die Standardwarteschlange fest, die diese Build-Definition verwenden soll. Da ich unter Linux bauen möchte, gebe ich meine "Linux"-Build-Warteschlange an. Optional können Sie eine Beschreibung und ein Build-Nummernformat angeben.
Wenn Sie möchten, können Sie die Aufbewahrungsrichtlinie auf der Registerkarte "Aufbewahrung" ändern. Im Moment mache ich mir darüber keine Gedanken. Wir werden nun den Erstellungsprozess selbst definieren. Navigieren Sie dazu zur Registerkarte "Erstellen" und klicken Sie auf "Schritt hinzufügen...".
Es wird ein Bildschirm angezeigt, in dem Sie aus den verfügbaren Bauaufgaben auswählen können. Die Liste ist bereits recht lang, wird aber in Zukunft wahrscheinlich noch erweitert werden. Sie werden feststellen, dass es bereits eine Aufgabe für einen Maven-Build gibt. Wir fügen diese Aufgabe zu unserem Build-Prozess hinzu.
In der Konfiguration des Maven Build-Tasks müssen wir unsere POM-Datei angeben. Im Feld "Optionen" habe ich "-e" angegeben, damit Maven einen Stack-Trace ausgibt, wenn etwas schief geht. Das wird bei der Fehlersuche helfen. Das Standardziel ist "Paket", was in unserem Fall in Ordnung ist. Außerdem lassen wir das Kontrollkästchen "Auf VSO/TFS veröffentlichen" für die JUnit-Testergebnisse markiert, damit wir unsere Unit-Testläufe später analysieren können.
Als Nächstes fügen wir einen weiteren Build-Schritt hinzu, um unsere erstellten Binärdateien auf dem Server zu veröffentlichen, damit wir sie später von dort abrufen können.
Wir werden die Aufgabe "Artefakt veröffentlichen" so konfigurieren, dass alles im Ordner "target" in einem Artefakt namens "drop" auf den Server kopiert wird. Zum Schluss setzen Sie das Kontrollkästchen "Immer ausführen" auf an, damit Artefakte wie Buildlogs veröffentlicht werden, auch wenn ein vorheriger Build-Schritt fehlschlägt.
Speichern Sie schließlich Ihre Build-Definition und geben Sie ihr einen sinnvollen Namen. Da Build-Definitionen in Build.vNext versioniert werden, müssen Sie auch einen Kommentar angeben, der in der Historie der Build-Definition erscheinen wird.
Das war's! Unsere Build-Definition ist fertig. Jetzt können wir den Build ausführen...
Ausführen des Builds und Anzeigen der Ergebnisse
Um einen neuen Build in die Warteschlange zu stellen, klicken Sie auf das kleine Dreieck vor Ihrer Build-Definition und dann auf "Build in die Warteschlange stellen...".
Optional können Sie die Warteschlange oder den Zweig ändern oder eine Commit-ID angeben, die Sie erstellen möchten. Klicken Sie vorerst einfach auf "OK".
Der Build wird gestartet und nach einer Weile sollten Sie die grüne Meldung "Build Succeeded" sehen!
Ist Ihnen aufgefallen, dass wir nie angegeben haben, auf welchem Betriebssystem unser Build läuft? Dies ist eine der coolen Funktionen von Build.vNext! Da die Aufgaben mit Node.js geschrieben werden, können sie auf jeder Plattform ausgeführt werden. Sie können auf die Build-Nummer klicken, um die Seite "Build-Zusammenfassung" aufzurufen.
Die Seite gibt Ihnen einen grundlegenden Überblick über den Verlauf des Builds. Klicken Sie auf das Symbol Neu laden, um die Testergebnisse zu laden. Sie können Details anzeigen, indem Sie auf den Namen des Laufs klicken.
Sie können sich die detaillierten Ergebnisse des Testlaufs anzeigen lassen. Denken Sie daran, dass dies Java-Code ist, der von JUnit getestet wird!
Um die Binärdateien zu erhalten, die durch den Build erzeugt wurden, gehen Sie zurück zur Build-Übersichtsseite, klicken Sie auf "Artefakte" und dann auf "Erkunden".
Sie können die Build-Ausgabe durchsuchen. Dazu gehören kompilierte Klassen, Testberichte und natürlich auch die endgültige .jar-Datei. Sie können eine Datei herunterladen, indem Sie auf das kleine Dreieck und dann auf "Herunterladen" klicken.
Und da haben Sie es! Java-Code, der aus Eclipse in VSO importiert und auf einem Linux-Build-Agent erstellt wurde. Die Anwendung, die ich in diesem Beitrag erstellt habe, ist zwar an sich nicht sehr nützlich, aber ich finde, sie ist eine sehr schöne Demonstration der Richtung, in die Microsoft geht: Entwickeln, erstellen und ausführen auf vielen Plattformen.
Viel Spaß beim Bauen!
Verfasst von

Kees Verhaar
Welcome to my blog! I am an ALM consultant for Xpirit Netherlands B.V. Sounds fancy, doesn’t it? Basically it means I help people to do their work as a software engineer better, faster and easier. In the past couple of years of working in the field, I have encountered many things of which I thought: “I should share this!â€. This blog is my way of doing that. You’ll find real life stories, tips & tricks, examples and probably even some code here. Hope you enjoy! If you have any suggestions, please feel free to drop me a line.
Contact