Blog

Erstellen von Java-Code auf Linux mit VSO Build.vNext

Kees Verhaar

Aktualisiert Oktober 22, 2025
7 Minuten

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:

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.

BildSie 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.

Bild 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.

Bild 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.

BildWir 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.

Bild 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".

Bild Dadurch wird eine neue Build-Definition erstellt, die derzeit noch keine Build-Schritte enthält.

Bild 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.

Bild 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.

Bild 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...".

BildEs 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.

Bild 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.

Bild 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.

Bild 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.

BildSpeichern 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.

Bild 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...".

BildOptional 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".

Bild  Der Build wird gestartet und nach einer Weile sollten Sie die grüne Meldung "Build Succeeded" sehen!

BildIst 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.

Bild 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.

BildSie können sich die detaillierten Ergebnisse des Testlaufs anzeigen lassen. Denken Sie daran, dass dies Java-Code ist, der von JUnit getestet wird!

Bild 

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".

BildSie 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.

Bild  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

Let’s discuss how we can support your journey.