TOC

Erstellen Sie eine Build-Pipeline mit Travis CI

Erstellen Sie eine Build-Pipeline mit Travis CI

1. Einführung

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

Im Allgemeinena build pipeline is a set of automated steps that move code from development to production.

Build-Pipelines eignen sich hervorragend zur Implementierung kontinuierlicher Integrations-Workflows für Software. Sie erlauben unsbuild smaller changes with greater frequency 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 mitTravis CI befassen.

2. Schritte in einer Build-Pipeline

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

  • Compiling code: In unserem Fall bedeutet dies, Java-Quellcode in Klassendateien zu kompilieren

  • Executing tests: wie das Ausführen von Komponententests und möglicherweise Integrationstests

  • Deploying artifacts: Packen von konformem Code in Artefakte, z. B. injar-Dateien, und Bereitstellen dieser

Wenn eine Anwendung unterschiedliche Technologien verwendet, giltadditional steps can be included in the build pipeline. Zum Beispiel könnten wir einen zusätzlichen Schritt haben, der JavaScript-Dateien minimiert oder aktualisierte API-Dokumentation veröffentlicht.

3. Was ist Travis CI?

Für unsere Beispiel-Build-Pipeline verwenden wirTravis CI, a cloud-based continuous integration tool.

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

  • Lässt sich schnell in jedes öffentliche GitHub-Repository integrieren

  • Unterstützt alle wichtigen 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 benachrichtigt uns.

Travis CI ist sofort einsatzbereit und erfordert nur eine geringe Konfiguration. The only required configuration is specifying the programming language.

Wir können jederzeit weitere Konfigurationen bereitstellen, um unsere Pipeline bei Bedarf anzupassen. Beispielsweise können wir eingrenzen, welche Verzweigungen 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 Domainnamen.orggekennzeichnet ist, bietet alle Funktionenfor any public GitHub repository. Die Anzahl der Builds oder Repositorys ist unbegrenzt, obwohl für die Ausführung Ihrer Pipeline Ressourcenbeschränkungen gelten.

Die kostenpflichtige Version, die den Domainnamen.comverwendet, ist für private GitHub-Repositorys erforderlich. Es bietet auch mehr gleichzeitige Builds und unbegrenzte Build-Minuten im Vergleich zum kostenlosen 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. Mit jedem öffentlichen Repository kann eine kostenlose Pipeline erstellt werden.

Alles, was wir tun müssen, ist, uns mit unserem GitHub-Konto bei Travis CI anzumelden und es zu autorisieren:

image

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

4.1. Repository konfigurieren

Zunächst gelten alle unsere öffentlichen Repositorys als inaktiv. Um dies zu beheben,we need to enable our repository from the account settings page.

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

image

Beachten Sie, dass jedes Repository auch eineSettings-Schaltfläche hat. Hier können wir das Verhalten verschiedener Pipelines konfigurieren:

  • Festlegen, 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 Lernprogramm funktionieren die Standardeinstellungen einwandfrei. Später werden wir sehen, wie Sie einige der Standardverhalten überschreiben können.

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. Without this file, the pipeline will not execute.

Für dieses Tutorial müssen wir nur die Konfiguration mit dem absoluten Minimum angeben, die die Programmiersprache angibt: 

language: java

Das ist es! Ohne weitere Informationen wird Travis CI eine einfache Pipeline ausführen, die:

  • Kompiliert unseren Quellcode

  • Führt unsere Tests durch

Sobald wir die.travis.yml-Datei festgeschrieben haben, startet Travis unseren ersten Build. Alle weiteren Festschreibungen für den Zweig vonmasterlösen zusätzliche Builds aus. Das Dashboard ermöglicht es uns auch, die Pipeline jederzeit manuell auszulösen, ohne dass eine Festschreibungs- oder Pull-Anforderung erforderlich ist.

5. Zusätzliche Konfiguration

Im vorherigen Abschnitt haben wir gesehen, dass eine einzige Konfigurationszeile alles ist, was wir zum Ausführen unserer Build-Pipeline benötigen. Für die meisten Projekte ist jedoch eine zusätzliche Konfiguration erforderlich, um eine aussagekräftige 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 Standarderstellungsbefehls

Der Standardbefehl zum Erstellen von Maven-Projekten lautet: 

mvn test -B

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

script: mvn package -DskipTests

Mit dem Operator&& können mehrere Befehle in einer einzigenscript-Zeile verkettet werden.

Einige Erstellungsbefehle sind komplex und können sich über mehrere Zeilen erstrecken oder eine komplexe Logik aufweisen. Beispielsweise können sie verschiedene Aktionen basierend auf Umgebungsvariablen ausführen.

In these cases, it’s recommended to place the build command in a stand-alone script und rufen Sie das Skript aus der Konfigurationsdatei heraus auf: 

script: ./build.sh

5.2. Code bereitstellen

Die Standard-Build-Einstellungen für Java-Projekte kompilieren einfach den Code und führen Tests durch. Die resultierenden Artefakte (.jar-Dateien usw.) werden am Ende der Pipeline verworfen, es sei denn, wir stellen sie irgendwo bereit.

Travis CI unterstützt eine Reihe 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 auchdeploy code directly to most popular cloud computing platforms wie AWS, Google App Engine, Heroku und viele mehr sein.

Nachfolgend finden Sie eine Beispielkonfiguration, die zeigt, wie Heroku bereitgestellt werden kann. Um verschlüsselte Eigenschaften zu generieren, müssen wirTravis CLI tool verwenden. 

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

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

Beispielsweise 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 fürmaster ausgeführt. Die meisten großen Projekte verwenden jedoch eine Art Git-Verzweigung, um die Entwicklungszyklen zu verwalten.

Travis CI supports both white and blacklisting of git branches, 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 die Zweigemaster undnightly ignorieren. Commits für die Zweigerelease undstable würden die Pipeline auslösen. Beachten Sie, dass die Direktiveonlyimmer Vorrang vor der Direktiveexcepthat.

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 mitdevelopment beginnen.

5.4. Überspringen bestimmter Commits

We can use the git commit message to skip individual commits. Travis CI prüft die Nachricht auf die folgenden Muster:

  • überspringen

  • überspringen

Dabei steht für einen 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 zu.travis.yml hinzugefügt wird: 

os: osx # can also be 'windows'

Selbst unter Linux gibt es drei verschiedene Distributionen, aus denen wir wählen können: 

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

Diebuild platform documentation decken alle verfügbaren Umgebungen und ihre Unterschiede ab.

Denken Sie daran, dass wir beim Ändern der Plattform möglicherweise auch benutzerdefiniertebuild- oderdeploy-Skripte ändern müssen, um die Kompatibilität sicherzustellen. Es gibt verschiedene Möglichkeiten,handle multiple operating systems in der Konfiguration zu konfigurieren.

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 für verschiedene Build-Umgebungen, auch für verschiedene Linux-Distributionen, unterschiedliche JDK-Versionen verfügbar sein können. Konsultieren Sie die Dokumentation für jede Umgebung, um die vollständige Liste der JDK-Versionen anzuzeigen.

6. Matrizen erstellen

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.

Eines der großartigen Merkmale 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 Einstellungen, die wir zuvor gesehen haben, unterschiedliche Werte verwenden.

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

There are two ways to create build matrices. Erstenswe can provide an array of values für eine oder mehrere der zuvor gesehenen Sprach- und Umgebungskonfigurationen. Zum Beispiel: 

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

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

The second way to create a build matrix is to use the matrix.include directive. 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 zwei Jobs ergeben.

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

Es gibtmore options, die eine genauere Kontrolle darüber bieten, welche Jobs erstellt werden sollen und wie Fehler behandelt werden sollen.

7. Fazit

In diesem Artikel haben wir mit Travis CI eine einfache Build-Pipeline erstellt. Wir haben 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.

Related