Erstellen Sie eine Build-Pipeline mit Travis CI

1. Einleitung

In der modernen Softwareentwicklung wird der Begriff Pipeline häufig verwendet. Aber was ist es?

Im Allgemeinen besteht eine Build-Pipeline aus einer Reihe automatisierter Schritte, mit denen Code von der Entwicklung in die Produktion verschoben wird .

Build-Pipelines eignen sich hervorragend für die Implementierung von Workflows für die kontinuierliche Integration von Software. Sie ermöglichen es uns , kleinere Änderungen häufiger vorzunehmen , mit dem Ziel, Fehler früher zu finden und ihre Auswirkungen zu verringern.

In diesem Tutorial werden wir uns mit dem Erstellen einer einfachen Build-Pipeline mit Travis CI befassen.

2. Schritte in einer Build-Pipeline

Eine Build-Pipeline kann aus vielen verschiedenen Schritten bestehen, sollte jedoch mindestens Folgendes umfassen:

  • Code kompilieren : In unserem Fall bedeutet dies, Java-Quellcode in Klassendateien zu kompilieren
  • Ausführen von Tests : wie das Ausführen von Komponententests und möglicherweise Integrationstests
  • Bereitstellen von Artefakten : Packen von konformem Code in Artefakte, z. B. in JAR- Dateien, und Bereitstellen dieser

Wenn eine Anwendung unterschiedliche Technologien verwendet, können zusätzliche Schritte in die Build-Pipeline aufgenommen werden . Beispielsweise haben wir möglicherweise einen zusätzlichen Schritt, der JavaScript-Dateien minimiert oder aktualisierte API-Dokumentation veröffentlicht.

3. Was ist Travis CI?

Für unsere Beispiel-Build-Pipeline verwenden wir Travis CI, ein Cloud-basiertes Tool zur kontinuierlichen Integration .

Dies hat eine Reihe von Funktionen, die es zu einer großartigen Wahl für den Einstieg in den Bau von Pipelines machen:

  • Kann schnell in jedes öffentliche GitHub-Repository integriert werden
  • Unterstützt alle gängigen Programmiersprachen
  • Wird auf mehreren verschiedenen Cloud-Plattformen bereitgestellt
  • Bietet eine Vielzahl von Messaging- und Alarmierungs-Tools

Auf hoher Ebene wird ein GitHub-Repository auf neue Commits überwacht.

Wenn ein neues Commit durchgeführt wird, werden die in einer Konfigurationsdatei definierten Schritte der Build-Pipeline ausgeführt (mehr dazu weiter unten). Wenn ein Schritt fehlschlägt, wird die Pipeline beendet und wir werden benachrichtigt.

Travis CI erfordert standardmäßig nur sehr wenig Konfiguration. Die einzige erforderliche Konfiguration ist die Angabe der Programmiersprache .

Wir können jederzeit mehr Konfiguration bereitstellen, um unsere Pipeline bei Bedarf anzupassen. Zum Beispiel können wir einschränken, welche Zweige Builds auslösen, der Pipeline zusätzliche Schritte hinzufügen und vieles mehr.

3.1. Kostenlose und kostenpflichtige Versionen

Es ist wichtig zu wissen, dass Travis CI derzeit zwei Angebote hat: eine kostenlose und eine kostenpflichtige Version.

Die kostenlose Version, die mit dem .org- Domainnamen gekennzeichnet ist, bietet alle Funktionen für jedes öffentliche GitHub-Repository . Die Anzahl der Builds oder Repositorys ist nicht begrenzt, obwohl bei der Ausführung Ihrer Pipeline Ressourcenbeschränkungen gelten.

Die kostenpflichtige Version, die den .com- Domainnamen verwendet, ist für private GitHub-Repositorys erforderlich. Es bietet außerdem mehr gleichzeitige Builds und unbegrenzte Build-Minuten als der kostenlose Plan. Für die ersten 100 Builds gibt es eine kostenlose Testversion, um die kostenpflichtige Version zu testen.

4. Erstellen einer Build-Pipeline mit Travis CI

Für dieses Tutorial verwenden wir die oben erwähnte kostenlose Version. Jedes öffentliche Repository kann zum Erstellen einer freien Pipeline verwendet werden.

Wir müssen uns lediglich mit unserem GitHub-Konto bei Travis CI anmelden und es autorisieren:

Nachdem wir unserem GitHub-Konto Berechtigungen erteilt haben, können wir mit der Konfiguration unserer Build-Pipeline beginnen.

4.1. Repository konfigurieren

Zunächst werden alle unsere öffentlichen Repositories als inaktiv betrachtet. Um dies zu beheben, müssen wir unser Repository auf der Seite mit den Kontoeinstellungen aktivieren .

Hier werden alle unsere öffentlichen Repositorys zusammen mit einer Umschalttaste aufgelistet. Durch Klicken auf die Umschaltfläche wird Travis CI so konfiguriert, dass die Überwachung dieses Repositorys auf neue Commits unter Verwendung des Standardzweigs des Masters gestartet wird :

Beachten Sie, dass jedes Repository auch über eine Schaltfläche Einstellungen verfügt . Hier können wir verschiedene Pipeline-Verhaltensweisen konfigurieren:

  • Definieren Sie, welche Ereignisse die Pipeline auslösen (Pushs, Pull-Anforderungen usw.).
  • Legen Sie Umgebungsvariablen fest, die an die Pipeline übergeben werden
  • Builds automatisch abbrechen, wenn neue Ereignisse ausgelöst werden

In diesem Tutorial funktionieren die Standardeinstellungen einwandfrei. Später werden wir sehen, wie einige der Standardverhalten überschrieben werden.

4.2. Travis-Konfiguration erstellen

Der nächste Schritt besteht darin, eine neue Datei mit dem Namen .travis.yml im Stammverzeichnis unseres Repositorys zu erstellen . Diese Datei enthält alle Informationen, die zum Konfigurieren einer Pipeline erforderlich sind. Ohne diese Datei wird die Pipeline nicht ausgeführt .

Für dieses Tutorial müssen wir nur die Mindestkonfiguration angeben, die die Programmiersprache angibt:

language: java

Das ist es! Ohne weitere Informationen führt Travis CI eine einfache Pipeline aus, die:

  • Kompiliert unseren Quellcode
  • Führt unsere Tests aus

Sobald wir die .travis.yml- Datei festgeschrieben haben, startet Travis unseren ersten Build. Alle weiteren Commits für den Master- Zweig lösen zusätzliche Builds aus. Über das Dashboard können wir die Pipeline auch jederzeit manuell auslösen, ohne dass eine Festschreibungs- oder Pull-Anforderung erforderlich ist.

5. Zusätzliche Konfiguration

Im vorherigen Abschnitt haben wir gesehen, dass nur eine einzige Konfigurationszeile erforderlich ist, um unsere Build-Pipeline auszuführen. Die meisten Projekte erfordern jedoch eine zusätzliche Konfiguration, um eine sinnvolle Pipeline zu implementieren.

In diesem Abschnitt werden einige der nützlicheren Konfigurationen beschrieben, die wir möglicherweise zu unserer Pipeline hinzufügen möchten.

5.1. Ändern des Standard-Build-Befehls

Der Standardbefehl zum Erstellen von Maven-Projekten lautet:

mvn test -B

Wir können dies in einen beliebigen Befehl ändern, indem wir die Skriptanweisung in .travis.yml festlegen :

script: mvn package -DskipTests

Es ist möglich, verketten mehrere Befehle in einem einzigen Skript Zeile mit dem && Operator.

Einige Build-Befehle sind komplex und können mehrere Zeilen umfassen oder eine komplexe Logik aufweisen. Beispielsweise können sie basierend auf Umgebungsvariablen unterschiedliche Aktionen ausführen.

In diesen Fällen wird empfohlen, den Befehl build in einem eigenständigen Skript zu platzieren und dieses Skript aus der Konfigurationsdatei heraus aufzurufen:

script: ./build.sh

5.2. Code bereitstellen

Die Standard-Build-Einstellungen für Java-Projekte kompilieren einfach den Code und führen Tests aus. Die resultierenden Artefakte (JAR-Dateien usw.) werden am Ende der Pipeline verworfen, sofern wir sie nicht irgendwo bereitstellen.

Travis CI unterstützt eine Vielzahl bekannter Dienste von Drittanbietern. Artefakte können auf viele gängige Cloud-Speichersysteme wie Amazon S3, Google Cloud Storage, Bintray und andere kopiert werden.

Es kann Code auch direkt auf den gängigsten Cloud-Computing-Plattformen wie AWS, Google App Engine, Heroku und vielen anderen bereitstellen.

Unten finden Sie eine Beispielkonfiguration, die zeigt, wie wir Heroku bereitstellen können. Um verschlüsselte Eigenschaften zu generieren, müssen wir das Travis CLI-Tool verwenden.

deploy: provider: heroku api_key: secure: "ENCRYPTED_API_KEY"

Darüber hinaus bietet es eine generische Bereitstellungsoption, mit der wir unser eigenes Bereitstellungsskript schreiben können. Dies ist hilfreich, wenn wir Artefakte auf einem System eines Drittanbieters bereitstellen müssen, das von Haus aus nicht unterstützt wird.

Zum Beispiel könnten wir ein Shell-Skript schreiben, das die Artefakte sicher auf einen privaten FTP-Server kopiert:

deploy: provider: script script: bash ./custom-deploy.sh

5.3. Verwalten, welche Zweige die Pipeline auslösen

Standardmäßig wird die Pipeline für jedes Commit auf dem Master ausgeführt . Die meisten großen Projekte verwenden jedoch eine Form der Git-Verzweigung, um Entwicklungszyklen zu verwalten.

Travis CI unterstützt sowohl die weiße als auch die schwarze Liste von Git-Zweigen , um zu bestimmen, welche Commits die Pipeline auslösen sollen.

Betrachten Sie als Beispiel die folgende Konfiguration:

branches: only: - release - stable except: - master - nightly

Dies würde Commits für den Master und die nächtlichen Zweige ignorieren . Commits für die Freigabe und stabile Verzweigungen würden die Pipeline auslösen. Beachten Sie, dass die einzige Direktive immer Vorrang vor der Ausnahme- Direktive hat.

Wir können auch reguläre Ausdrücke verwenden, um zu steuern, welche Zweige die Pipeline auslösen:

branches: only: - /^development.*$/

Dies würde die Pipeline nur für Commits in Zweigen starten, die mit der Entwicklung beginnen .

5.4. Überspringen bestimmter Commits

Wir können die git-Commit-Nachricht verwenden, um einzelne Commits zu überspringen . Travis CI untersucht die Nachricht auf folgende Muster:

  • überspringen
  • überspringen

Wo ist einer der folgenden Werte:

  • ci
  • Travis
  • travis ci
  • travis-ci
  • travisci

Wenn die Festschreibungsnachricht mit einem dieser Muster übereinstimmt, wird die Pipeline nicht ausgeführt.

5.5. Verwenden verschiedener Build-Umgebungen

Die Standard-Build-Umgebung für Java-Projekte ist Ubuntu Linux. Pipelines können auch unter Mac OS X oder Windows Server ausgeführt werden, indem die folgende Konfiguration in .travis.yml hinzugefügt wird :

os: osx # can also be 'windows'

Selbst unter Linux stehen 3 verschiedene Distributionen zur Auswahl:

os: linux dist: xenial # other choices are 'trusty' or 'precise'

Die Dokumentation zur Build-Plattform deckt alle verfügbaren Umgebungen und ihre Unterschiede ab.

Denken Sie daran, dass wir beim Ändern der Plattform möglicherweise auch benutzerdefinierte Build- oder Bereitstellungsskripts ändern müssen , um die Kompatibilität sicherzustellen. Es gibt verschiedene Möglichkeiten, mehrere Betriebssysteme in der Konfiguration zu behandeln.

5.6. Verwenden verschiedener JDK-Versionen

Wir können auch gegen eine bestimmte Version des JDK testen, indem wir die folgende Konfiguration in der Datei .travis.yml festlegen :

jdk: oraclejdk8

Beachten Sie, dass in verschiedenen Build-Umgebungen, auch in verschiedenen Linux-Distributionen, unterschiedliche JDK-Versionen verfügbar sein können. In der Dokumentation für jede Umgebung finden Sie die vollständige Liste der JDK-Versionen.

6. Erstellen Sie Matrizen

Standardmäßig wird unsere Pipeline bei jeder Ausführung als einzelner Job ausgeführt. Dies bedeutet, dass alle Phasen der Pipeline nacheinander auf einer einzelnen virtuellen Maschine mit denselben Einstellungen ausgeführt werden.

Eine der großartigen Funktionen von Travis CI ist jedoch die Möglichkeit, eine Build-Matrix zu erstellen. Auf diese Weise können wir für jedes Commit mehrere Jobs ausführen und für einige der zuvor angezeigten Einstellungen unterschiedliche Werte verwenden.

Beispielsweise können wir eine Build-Matrix verwenden, um unsere Pipeline sowohl unter Linux als auch unter Mac OSX oder mit JDK 8 und 9 auszuführen.

Es gibt zwei Möglichkeiten, Build-Matrizen zu erstellen . Erstens können wir eine Reihe von Werten für eine oder mehrere der zuvor gesehenen Sprach- und Umgebungskonfigurationen bereitstellen . Zum Beispiel:

language: java jdk: - openjdk8 - openjdk9 os: - linux - osx

Mit diesem Ansatz erweitert Travis CI automatisch jede Konfigurationskombination, um mehrere Jobs zu bilden. Im obigen Beispiel wären das Ergebnis insgesamt vier Jobs.

Die zweite Möglichkeit, eine Build-Matrix zu erstellen, besteht in der Verwendung der Direktive matrix.include . Auf diese Weise können wir explizit deklarieren, welche Kombinationen wir ausführen möchten:

language: java matrix: include: - jdk: openjdk8 os: linux - jdk: openjdk9 os: osx

Das obige Beispiel würde zu zwei Jobs führen.

Wenn wir auf mehreren Betriebssystemen aufbauen, müssen wir erneut darauf achten, dass unsere Build- und Bereitstellungsskripts in allen Fällen funktionieren. Shell-Skripte funktionieren beispielsweise unter Windows nicht. Wir müssen geeignete bedingte Anweisungen verwenden, um mit verschiedenen Betriebssystemen umzugehen.

Es gibt mehr Optionen, mit denen Sie genauer steuern können, welche Jobs erstellt werden sollen und wie Fehler behandelt werden sollen.

7. Fazit

In diesem Artikel haben wir eine einfache Build-Pipeline mit Travis CI erstellt. Mit der meist sofort einsatzbereiten Konfiguration haben wir eine Pipeline erstellt, die Code erstellt und Tests ausführt.

Wir haben auch eine kleine Auswahl davon gesehen, wie konfigurierbar Travis CI ist. Es funktioniert mit einer Vielzahl von Programmiersprachen und Cloud-Plattformen von Drittanbietern. Der einzige Nachteil ist, dass es derzeit nur mit GitHub-Repositorys funktioniert.