Tools im CI-Prozess Seminararbeit WS 20/21 - Thomas Jansen 3201738 Prof. Dr. rer. nat. Kraft Torsten Rehfisch
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Seminararbeit WS 20/21
im Studiengang Angewandte Mathematik und
Informatik
Tools im CI-Prozess
Autor Thomas Jansen
Matrikelnummer 3201738
1. Betreuer Prof. Dr. rer. nat. Kraft
2. Betreuer Kraft
Torsten Rehfisch
Eschweiler, den 15. Dezember 2020Inhaltsverzeichnis
1 Einleitung 3
2 Build-Prozess 4
3 Buildtools 4
3.1 Make 5
3.2 Maven 6
3.3 Gradle 7
4 Build-Server 8
5 Continuous Integration 9
5.1 Definition 9
5.2 Intention 9
5.3 Verhaltensregel 10
5.4 Nightly Build 11
5.5 Continuous Delivery 12
6 Automation-Tools 13
6.1 Jenkins 13
6.1.1 Bereitstellung und Kosten 14
6.1.2 Versionsverwaltungssysteme 14
6.1.3 Sprachen und Buildtools 14
6.1.4 Anwendung 14
6.1.5 Skalierbarkeit 16
6.1.6 Wartung 16
6.1.7 Fazit 16
6.2 Travis CI 17
6.2.1 Bereitstellung und Kosten 17
6.2.2 Versionsverwaltungssysteme 17
6.2.3 Sprachen und Buildtools 17
6.2.4 Anwendung 18
6.2.5 Skalierbarkeit 19
6.2.6 Wartung 19
Seite 16.2.7 Fazit 19
6.3 GitLab CI/CD 20
6.3.1 Bereitstellung und Kosten 20
6.3.2 Versionsverwaltungssysteme 20
6.3.3 Sprachen und Buildtools 20
6.3.4 Anwendung 20
6.3.5 Skalierbarkeit 21
6.3.6 Wartung 21
6.3.7 Fazit 22
7 Schlusswort 23
8 Anhang 24
8.1 Default Configuration einer Travis CI VM 24
8.2 Pullrequest Message mit TravisCI 26
8.3 GitLab CI/CD WebUI 26
9 Quellen 27
Seite 21 Einleitung
Im Verlauf der Entwicklung von Softwareentwicklung ist ein klarer Trend zu entde-
cken: Programme werden immer komplexer. Nicht nur die reine Anzahl der Code-
zeilen steigt stetig. Im gleichen Maße wie die Leistungsfähigkeit Hardwarekompo-
nenten zeigt, nehmen auch die Ansprüche an Programme zu. Systeme werden
vermehrt auf High-Performance getrimmt und die Implementierung hochkomplexer
Algorithmen soll die Effizienz von Programmcode steigern.
Um dies zu bewerkstelligen steigt zwangsläufig die Zahl der Personen, die in ei-
nem Projekt involviert sind.
Um die Koordination innerhalb des Projektes weiter zu gewährleisten, werden
Programme modularisiert und Teams aus kleinen Personengruppen sind für die
Entwicklung einzelner Modulen verantwortlich.
Doch so wie bereits Herausforderungen entstehen, wenn zwei Entwickler am
Code entwickeln, bringt das Arbeiten von mehreren Teams an einem Projekt Her-
ausforderungen mit sich:
Wie wird Code aus unterschiedlichen Entwicklungsständen zusammengeführt?
Ein Modul hat sich geändert, wie reagieren andere Module darauf? Was passiert,
wenn sich Schnittstellen ändern? Wie wird Codequalität sichergestellt und Code
getestet? Wie wird Fehleranalyse betrieben?
Auch in meinem Unternehmen musste man sich mit diesen Fragen auseinander
setzen und es wurde in den letzten Jahren zunehmend die Modernisierung von
Entwicklungsprozessen vorangetrieben.
Große Projektgruppen wurden in kleinere agile Teams aufgeteilt. Agile ist ein Soft-
wareentwicklungsprozess der geprägt ist von kurzen Entwurfsphase, schnell iterie-
renden Programmversionen und selbstorganisierten Teams.
In der agilen Softwareentwicklung gilt Continuous Integration als Best Practice und
Teams haben in Eigeninitiative Continuous Integration Prozesse mit zugehörigen
Tools eingeführt. 1
Aus verschiedenen Gründen soll möglichst konzernweit die Entwicklungsprozesse
vereinheitlicht werden und somit auch die Zahl der verwendeten Tools.
Eine Vereinheitlichung verringert Kosten bei der Anschaffung, Administration und
Wartung von Tools. Außerdem verringert sich die Einarbeitungszeit beim Wechseln
zwischen Teams oder Aufbau von neuen Teams.
Seite 3Diese Arbeit befasst sich zunächst mit dem Build-Prozess von Softwarekompo-
nenten. Anschließend wird belichtet, wie sogenannte Buildtools den Build formali-
sieren und Build-Automation ermöglichen.
Weiter wird der Begriff Continuous Integration erklärt und wie Continuous Integra-
tion den Entwicklungsprozess beeinflusst. Abschließend werden drei an Automati-
onsservern vorgestellt.
2 Build-Prozess
Da Continuous Integration die Verwendung von Buildtools voraussetzt, muss zu-
erst geklärt werden, was der Build-Prozess und Buildtools eigentlich sind.
Im einfachsten Sinne entspricht der Build dem kompilieren von Sourcecode zu
Maschinencode. Je nach Sprache und Umgebung finden jedoch zusätzlich zum
reinen Kompilieren noch weitere Prozesse statt.
Während des Builds eines Java-Programmes können neben dem Kompilieren,
also dem Umwandeln von .java-Dateien zu .class-Dateien, weitere Ressourcen
wie Konfigurationsdateien, für Webanwendungen .html- oder .css-Dateien oder
Multimediadateien wie Bilder oder Videos zu einer .jar-Datei gepackt werden.
Als weiteres Beispiel muss in Kotlin, einer Programmiersprache, die die Java Vir-
tual Machine als Laufzeitumgebung verwendet, muss während des Build zunächst
Kotlin-Code in Java-Code umgewandelt werden.
Weitere Sprachen können sich in den einzelnen Schritten unterscheiden, aber das
Ergebnis des Builds ist ein lauffähiges Programm.
3 Buildtools
Wenn mehrere Personen an einer Codebasis arbeiten, wird erwartet, dass sich
das Programm für jeden identisch verhält. Der Build von identischem Sourcecode
kann in unterschiedlichen Umgebungen jedoch zu potentiell drastisch abweichen-
den Programmen führen.
Beispielsweise interpretieren Compiler unterschiedlicher Versionen der selben
Sprache Code unterschiedlich. Das Kompilieren könnte mit einem Fehler abbre-
chen oder das laufende Programm könnte sich unerwartet verhalten. Weiter kön-
nen Plugins oder Frameworks in der lokal verwendeten Entwicklungsumgebung
den Build-Prozess beeinflussen.
Seite 4Damit trotzdem Entwickler die Entwicklungsumgebung frei wählen können, werden
sogenannte Buildtools verwendet.
Buildtools formalisieren den Build-Prozess und sorgen damit dafür, dass sich der
Build unabhängig von der Umgebung wird. 2
Drei populäre Buildtools sind Make, Maven und Gradle.
3.1 Make
Make ist eines der ältesten Buildtools und wird bis heute noch für die Program-
miersprachen C und C++ verwendet. Innerhalb der sogenannten Makefile können
Abhängigkeiten für den Buildprozess definiert werden.
Ein Anwendungsbeispiel für die eine Makefile: 3
CC=gcc
hello_make: beforeEach HelloWorld.c
$(CC) HelloWorld.c -o ./Output/HelloWorld
beforeEach:
mkdir Output
run: hello_make
./Output/HelloWorld
Mit dem Konsolenbefehl make wird die Makefile aufgerufen.
In der ersten Zeile wird eine Variable gesetzt, die in diesem Fall die Wahl des ver-
wendeten Compilers vorgibt. Anschließend wird das erste sogenannte Target auf-
gerufen, hier hello_make. Dieses Target hat die Vorbedingungen beforeEach und
HelloWorld.c, die bewirken, dass bevor das in hello_make definierte Skript aufge-
rufen wird, das Target beforeEach durchlaufen wurde und die Datei HelloWorld.c
existiert. Nach dem Erstellen des Verzeichnisses Output, wird der Sourcecode in
der Datei HelloWorld.c mit dem gewählten Compiler gcc nach Output/HelloWorld
kompiliert.
Mit dem Aufruf von make run wird zunächst das Target hello_make durchlaufen
und anschließend das kompilierte Programm gestartet.
Der Makefile-Mechanismus ist beliebig erweiterbar durch Testfälle für das Pro-
gramm oder Definition von verwendeten Programmcodebibliotheken.
Das Beispiel zeigt im einfachsten Sinne, wie mit dem Buildtool Make für Entwickler
auf unterschiedlichen Umgebungen ein einheitlicher Build-Prozess gewährleistet
werden kann.
Seite 53.2 Maven
Maven ist das Standard-Buildtool für Java Programme. Hier heißt die Konfigurati-
onsfile pom.xml. Maven ist im Gegensatz zu Make ein weitaus ausgereifteres Tool,
das eine Großzahl an zusätzlichen Funktionen bereitstellt.
Maven implementiert einen sieben-phasigen Build-Lifecycle. Bestehend aus den
Phasen/Scopes validate, compile, test, package, verify, install und deploy.
Diese können jeweils auf der Konsole aufgerufen werden (Bsp.: mvn install).
Die Phasen sind aufeinander aufbauend und handeln anhand der Konfigurations-
datei pom.xml, die sich im Rootverzeichnis des Projektes befinden muss.
Beispiel pom.xml:
4.0.0
org.example
HelloWorld
1.0
jar
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
junit
junit
3.8.1
test
Während der Phase validate wird die pom.xml syntaktisch und logisch geprüft. Es
wird getestet, ob Referenzen aufgelöst werden können und ob die Projektstruktur
maven-konform ist.
In der Phase compile wird namensgetreu das Projekt kompiliert.
In der pom.xml können hierzu explicit Plugins zum Build (maven-compiler-plugin)
und verwendete Frameworks (junit) inclusive Version angegeben werden.
Dass die hier angegebenen Abhängigkeiten auch tatsächlich in das Programm
eingebunden werden, wird durch eine weiteren, projektunabhängigen Konfigurati-
onsdatei, der sogenannten settings.xml gewährleistet.
Seite 6In dieser Datei wird zum einen ein lokales Repository-Verzeichnis angegeben,
zum andern können Artefaktrepositories definiert werden. Artefaktrepositories sind
Ablageorte für Codeartefakte wie Frameworks, Plugins oder ganze Programme.
Man kann sowohl öffentliche Repositories verwenden, die allerhand open-source
Artefakte beinhalten, oder private, in denen ein Unternehmen seinen entwickelten
Code aufbewahren und untereinander zugänglich machen kann.
In einer pom.xml erwähnte Artefakte werden, falls diese nicht bereits lokal existie-
ren, von einem Artefaktrepository in das lokale Verzeichnis geladen und sind für
alle Projekte zugänglich.
Zusätzlich verwendet das Maven-Framework eine standardisierte Verzeichnis-
struktur:
!"project
#"pom.xml
!"src
#"main
$ #"java
$ #"resources
#"test
#"java
#"resources
Alle unter src/test liegenden Tests wie JUnit- oder HtmlUnit-Tests werden mit dem
Scope test ausgeführt.
In der Phase package wird das Programm in das in der pom.xml angegebene
Format gepackt, in diesem Beispiel jar.
Mit dem Befehl mvn install wird das gebaute Programm in das lokale Repository
abgelegt und ist für alle lokalen Maven-Projekte referenzierbar.
In der letzten Phase im Maven-Lifecycle deploy wird das gebaute Programm in
einem externen Artefaktrepository abgelegt und kann von anderen verwendet
werden. 4
3.3 Gradle
Gradle ist das von Google verwendete Standardtool zur Androidentwicklung. Im
Gegensatz zu Maven benutzt Gradle keine Konfigurationsdatei sondern die Groo-
vy-Datei build.gradle. Groovy ist eine auf der Java Virtual Machine laufende Pro-
Seite 7grammier und Skriptsprache. Somit handelt es sich bei build.gradle um ein direkt
ausführbares Skript. Dadurch ist Gradle in der Lage Build-Prozesse zu parallelisie-
ren. Damit ist Gradle besonders geeignet für den Bau großer Projekte oder Sys-
teme, die aus mehreren Programmen zusammen gesetzt sind. 5
Das Potential der einzelnen Buildtools wurde im Rahmen dieser Arbeit nur leicht
angeschnitten. Trotzdem sind die Vorteile, die die Verwendung von Buildtools mit
sich bringt offensichtlich.
Entwickler sind flexibel in der Wahl der Entwicklungsumgebung. Abhängigkeiten
werden selbstständig aufgelöst. Versionsänderungen von Abhängigkeiten werden
zentral konfiguriert. Der Build-Prozess verläuft in jeder Umgebung identisch. Tests
werden automatisiert durchgeführt und der Bereitstellungsmechanismus ist stan-
dardisiert. Abschließend können ganze Builds durch teilweise einzeilige Skripte
angestoßen werden und sind so Grundbaustein für die Automatisierung in Zu-
sammenhang von Continuous Integration.
4 Build-Server
Ein Build-Server ist ein Server auf dem Builds automatisiert durchgeführt werden.
Build-Server sind mit allen Systemen und Umgebungen verbunden, die im Verlauf
des Builds benötigt werden. Durch einen Build-Server wird gewährleistet, dass je-
der Build identisch, sprich mit den selben Parametern, angestoßen wird. Weiter
können hier Skripte definiert werden, um auf Buildergebnisse zu reagieren. So
können Entwickler bei einem Fehlschlag informiert werden oder bei Erfolg werden
weitere Tests angestoßen, die nicht während des Builds stattfinden. Außerdem
können von hier aus Programme auf Testumgebungen verteilt werden.
Seite 85 Continuous Integration
5.1 Definition
„Kontinuierliche Integration (auch fortlaufende oder permanente Integration; eng-
lisch continuous integration (CI)) ist ein Begriff aus der Software-Entwicklung, der
den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer An-
wendung beschreibt.“ 6
In anderen Worten: Continuous Integration bedeutet, dass jede Änderung von
Code in einem Codemanagementsystem den Build des gesamten Programmes
anstößt.
5.2 Intention
Continuous Integration gelangte besonders zu Popularität als eine der Grundsäu-
len des Vorgehensmodells Extreme Programming. Neben weiteren Praktiken wie
Pair-Programming, in dem mindestens zwei Entwickler gemeinsam Code entwi-
ckeln, oder testgetriebener Entwicklung, dem Konzept, dass vor der Implementie-
rung von Code Testfälle geschrieben werden, gehört auch die permanente Integra-
tion zu einer Praktik, die die Effektivität im Softwareentwicklungsprozess steigern
soll. 7
Extreme Programming in der Praxis umzusetzen ist jedoch sehr aufwendig und ist
fast nur für erfahrene Expertenteams anwendbar.
Trotzdem wurden viele der Grundpraktiken des Extreme Programmings in teilwei-
se abgewandelter Form der Breite zugänglich gemacht und gelten heute als Best
Practice.
So auch das Konzept der permanenten Integration bzw. Continuous Integration.
Das Ziel von Continuous Integration ist die Zeitspanne zwischen Codeänderung
und Build des Programmes zu minimieren.
Entwicklerteams eines Projektes arbeiten zeitgleich an unterschiedlichen Modulen
des selben Programmes mit teilweise direkten Abhängigkeiten, die bereits bei der
Entwicklung des eigenen Moduls von Bedeutung sind, oder indirekten Abhängig-
keiten, die erst im Kontext des gesamten Programmes in Erscheinung treten.
Das Minimieren der Zeitspanne zwischen Codeänderung am Programmcode und
Build des gesamten Programmes bringt mehrere Vorteile mit sich.
Zum einen bekommt der Entwickler zeitnah die Rückmeldung, ob nach seinen
vorgenommenen Codeänderungen das Programm lauffähig ist und den in den
Buildtools definierten Testfällen entspricht.
Seite 9Besonderes Problem bei der Entwicklung mehrer Personen bzw. Teams an einer
Codebasis sind Abweichungen zwischen aktuellem Codestand und lokalen Kopien
mit unterschiedlichen Entwicklungsständen.
Während des lokalen Entwickelns an einem Modul sind Änderungen von Schnitt-
stellen oder Abhängigkeiten nicht spürbar.
Deswegen sind nach Tests von Modulen nur aussagekräftig nach der Integration
in das gesamte Programm.
Die Minimierung der Zeitspanne zwischen Änderung eines Moduls und bauen des
Programmes führt weiter dazu, dass Fehler schneller entdeckt und behoben wer-
den.
Außerdem sind durch die Tatsache, dass Entwickler Codeänderungen regelmäßi-
ger ausrollen müssen, die lokalen Kopien auf den Systemen der Entwickler aktuel-
ler. Durch eine niedrigere Anzahl an Codeänderungen wird die Fehleranalyse ver-
einfacht und beschleunigt.
Schließlich wird durch regelmäßige Builds gewährleistet, dass Fehler schneller ge-
funden und Auswirkungen potentieller Fehlerkaskaden, die auftreten, wenn auf ei-
nem Fehler weiterer Code aufbaut, eingegrenzt werden.
5.3 Verhaltensregel
Martin Fowler, Mitautor es Manifests für agile Software-Entwicklung, stellt in seiner
Arbeit „Continuous Integration“ einige Verhaltensregeln auf, um erfolgreich Conti-
nuous Integration im Entwicklungsalltag verwenden zu können:
Zum einen ist zwingend, dass der Gesamtcode eines Programmes an einem Ort
abgelegt wird und von diesem bezogen wird.
In der Praxis ist folglich die Verwendung eines Source Control Management Sys-
tem zwingend nötig. Heute hat sich für die meisten Anwendungsfälle git als Best
Practice durchgesetzt. Vor allem der in git integrierte Multibranch-Mechanismus
unterstützt die Zusammenarbeit in großen Projekten. In der Regel existiert ein
Branch, der Master, zu jeder Zeit. Von dem Master werden erzeugen sich Entwick-
ler einen Feature-Branch, auf dem neue Funktionen implementiert und getestet
werden. Wenn ein Branch für produktivfähig gehalten wird, wird dieser mit dem
Master vereint im sogenannten Merge. Es können beliebig viele Branches ange-
legt werden und so können an beliebig vielen Features gleichzeitig gearbeitet
werden. Wie oben bereits erwähnt, wird das Zusammenführen von Feature-
Branch und Master aufwendiger, je länger die Zeitspanne zwischen erstellen des
Branches und Mergen ist.
Im Zusammenhang damit ist die nächste Verhaltensregel, dass der Master immer
funktionstüchtig und fehlerfrei sein muss. Es ist zwar nicht möglich auszuschlie-
Seite 10ßen, dass nach einem Merge der Master korrumpiert ist, doch falls durch den im
Kontext von Continuous Integration angestoßene Build fehlschlägt, umgehend die
Integrität des Masters wieder hergestellt werden. Das verhindert, dass ein Branch
auf Basis eines fehlerhaften Codestandes aufbaut.
Um diesen Aspekt geht implizit hervor das Builds mittels Buildtools automatisiert
sein müssen.
Tests sollen soweit wie möglich automatisiert sein. Zwar ist die Automatisierung
von Tests keineswegs neu in der Softwareentwicklung, jedoch lohnt es sich beim
Verwenden von Continuous Integration Zeit in das Anlegen von möglichst vielen
Testfällen zu investieren. Im Rahmen von CI steigt die Frequenz der Builds von
wöchentlich oder täglich zu mehreren pro Tag und händisches Testen wird schnell
sehr kostenintensiv.
Damit durchgeführte Tests auch aussagekräftig für das Verhalten innerhalb der
produktiven Umgebung sind, muss die Testumgebung der produktiven Umgebung
möglichst ähnlich bzw. nachempfunden sein. Im besten Fall hält es sich bei der
Testumgebung um eine Kopie der produktiven Umgebung, in der falls nötig sensi-
ble Daten anonymisiert sind.
Je nach Anwendungsfall sind auch mehrere Testumgebungen sinnvoll. Beispiels-
weise müssen Programme für verschiedene Betriebssysteme, unterschiedliche
Laufzeitumgebungen oder Internetbrowser getestet werden. 8 9
Zusammenfassend müssen folgende Bedingungen erfüllt sein, um erfolgreich
Continuous Integration betreiben zu können.
Programmcode wird zentral mit einem Versionskontrollsystem wie git verwaltet
und ist für alle involvierten Entwickler zugänglich. Builds und Tests sind automati-
siert. Testumgebungen sind der produktiven Umgebung weitestgehend nachemp-
funden. Der Master-Branch ist immer lauffähig.
5.4 Nightly Build
Bereits vor dem Einführen von Continuous Integration waren Entwicklern die Vor-
teile von regelmäßig angestoßenen, automatisierten Builds, um Integrationsinter-
valle zu verkürzen, bekannt und seien hier nicht wiederholend aufgelistet.
Nightly Build beschreibt den Prozess, auf einem Build-Server zeitgesteuert, bei-
spielsweise in Form eines Cronjobs, einen Build anzustoßen. 10
Da in der Regel nachts nicht an Code gearbeitet wird, findet der Build meistens
nachts statt - daher der Name.
Zwar gilt Nightly Build als Vorgänger von Continuous Integration, wird jedoch in
der Praxis auch von Teams mit integriertem CI-Prozess verwendet.
Seite 11Im CI-Kontext dürfen Builds nicht zu lange dauern, damit für Entwickler keine War-
tezeiten entstehen. Einen großen Zeitfaktor während eines Builds können Tests
einnehmen und wie bereits erwähnt sollten so viele Testfälle wie möglich innerhalb
des Builds durchgeführt werden. Da hier zwei Prinzipien der Continuous Integrati-
on werden sich gegenseitig behindern, werden in der Praxis sehr zeit- und res-
sourcenaufwendige Tests in einen Nightly Build ausgelagert.
Ein weiterer Grund für die Verwendung von Nightly Builds trotz Continuous Inte-
gration ist das Ausliefern von Programmversionen auf Testumgebungen. Auf Test-
umgebungen könnten manuell Tests von Entwicklern, Kunden oder nicht fachli-
chen Mitarbeitern. Da kann es von Vorteil sein, wenn das Programm auf der Test-
umgebung tagsüber verfügbar ist und nicht mehrfach am Tag neu aufgespielt wird.
Continuous Integration wird über sogenannte Runner-Tools oder Automationsser-
ver, die im weiteren Verlauf vorgestellt werden, realisiert. Da diese Tools in der
Regel auch zeitgesteuerte Builds unterstützen und im CI-Kontext Nightly Builds
verwendet werden, werden in der Literatur teilweise Nightly Builds zu Continuous
Integration- Prozessen gezählt, auch wenn das genau genommen nicht stimmt.
Nightly Build bezeichnet einen Build der automatisiert zu einer bestimmten Uhrzeit
läuft. Bei Continuous Integration stößt jeder Commit in dem Versionsverwaltungs-
tool einen Build an.
5.5 Continuous Delivery
Von Continuous Delivery spricht man, wenn anschließend an einen Continuous
Integration Build automatisiert eine Auslieferung bzw. Produktivschaltung ange-
stoßen wird.
Nach einem erfolgreichen Build werden automatisch verschiedene Kontrollstruktu-
ren angesprochen wie Kundenakzeptanztests. Nachdem von allen Instanzen die
Produktivschaltung abgesegnet wurde, wird das Programm ausgeliefert.
In der Literatur sind werden Continuous Integration und Continuous Delivery oft in
einem Zusammenhang erwähnt als und mit CI/CD abgekürzt.
In Kontext von DevOps-Teams, also der Zusammenführung von Entwicklung und
Betrieb können die Grenzen zwischen Continuous Integration und Continuous De-
livery fließend sein, denn bisherige Kontrollinstanzen werden ins Team integriert. 11
Im weiteren Verlauf wird nicht genauer auf spezifische Continuous Delivery Struk-
turen eingegangen.
Seite 126 Automation-Tools
Es wurde bereits vorgestellt, wie Nightly Builds auf Build-Servern in Form eines
zeitgesteuerten Cronjobs automatisiert werden. In diesem Kapitel wird erklärt, wie
der Automationsprozess bei Continuous Integration tatsächlich implementiert wird.
Zu Beginn ist ein Tool zwingend, dass folgende Bedingungen erfüllt.
Das Tool benötigt Leseberechtigungen auf das verwendete Versionsverwaltungs-
system. Weiter muss das Tool über Codeänderungen informiert werden. Außer-
dem muss das auf Tool eine Reihe verschiedener Buildtools zugreifen können.
Zudem benötigt ein Tool Schnittstellen zu den während des Builds aufgelösten
Abhängigkeiten. Zuletzt sollte die Möglichkeit gegeben werden, Builds auf ver-
schiedenen Testumgebungen auszuführen.
Nicht zwingende, aber wünschenswerte Funktionalitäten sind Kommunikation zu
Entwicklern, eine übersichtliche Benutzeroberfläche, Visualisierung der Builds und
eine Benutzeradministration.
In der weiteren Vorstellung verschiedener Automations-Tools wurde besonderer
Fokus auf das Versionsverwaltungssystem git und den Schnittstellen zu dessen
netzbasierten Diensten GitHub, GitLab und Bitbucket.
Im folgenden werden verschiedene vorgestellt und an anhand folgender Kriterien
verglichen. Implementierung eines Continuous Integration Projektes, Bereitstel-
lung des Tools, unterstützte Sprachen, Buildtools und Versionsverwaltungssyste-
men, Erweiterbarkeit, Wartung und Kosten.
6.1 Jenkins
Ursprünglich wurde Jenkins unter dem Namen Hudson entwickelt. Nach einem
Urheberstreit mit Oracle teilte sich das Projekt auf. Oracle entwickelte bis 2017 an
Hudson. Jenkins, das zweite Projekt, aufbauend auf einem Fork, konnte sich am
Markt durchsetzten. 12
Heute ist Jenkins einer der populärsten Automations-Server. Jenkins ist ein kos-
tenfreies, open-source Programm. Alleine dadurch interessant für sowohl Hobby-
programmierer als auch große IT-Unternehmen.
Seite 136.1.1 Bereitstellung und Kosten
Jenkins wird ausgeliefert als stand-alone Anwendung mit integriertem build-in Java
Application-Server. Das hat zur Folge, dass die Jenkins WAR-File (Web applicati-
on archive) auf jedem Betriebssystem oder jeder Plattform mit einer von Jenkins
unterstützten Java-Version lauffähig ist. Aktuell werden Java 8 und Java 11 unter-
stützt. Darüber hinaus stellt Jenkins explizit Support und Dokumentation für die
Betriebssysteme Linux, macOS und Windows und die Plattformen Docker und
Kubernetes bereit. 13 14
Als kostenfreies open-source Programm entstehen keine Beschaffungskosten.
Es ist jedoch nicht außer Acht zu lassen, dass trotzdem Kosten bei der Bereitstel-
lung der Laufzeitumgebung, Wartung, Pflege und Administration entstehen.
6.1.2 Versionsverwaltungssysteme
Jenkins unterstützt das durch separate Plugins sowohl Bitbucket, GitHub als auch
GitLab. Die Plugins Konfiguration der Plugins ist identisch.
Für das Einbinden der Verwaltungssysteme wird ein User ein User benötigt, der
Admin-Berechtigungen für das jeweilige Projekt besitzt. Hier empfiehlt sich nicht
persönliche Zugangsdaten zu verwenden, sondern einen separaten User für Jenk-
ins anzulegen und diesem für alle benötigten Projekte Berechtigungen zuzuwei-
sen.
6.1.3 Sprachen und Buildtools
Mit Jenkins werden keine Sprachen oder Buildtools ausgeliefert.
Jenkins verwendet die Konsole des Servers auf dem das Tool läuft und kann
dementsprechend alle Buildtools verwenden, die auf dem Server installiert wur-
den.
Es existiert eine große Zahl an Plugins, die in der Benutzeroberfläche das Arbeiten
mit Buildtools erleichtern, zum Beispiel welche Maven-Version verwendet werden
soll. Die Tools müssen jedoch trotzdem händisch bereitgestellt werden.
6.1.4 Anwendung
Zum Verwenden von Jenkins als Build-Server wird in dem Repository des Projek-
tes eine Groovy-Datei abgelegt. Der Name ist frei wählbar, empfohlen wird Jenk-
insfile.
Seite 14Beispiel einer Jenkinsfile:
pipeline {
agent none
options {
skipStagesAfterUnstable()
}
stages {
stage('Build') {
steps {
sh 'mvn -B -DskipTests clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
stage('Deliver') {
steps {
sh './jenkins/scripts/deliver.sh'
}
}
}
}
Jenkins empfiehlt für Builds die Verwendung einer Pipeline. Pipelines bestehen
aus Stages, die nacheinander abarbeitet werden und anschließend in der Jenkins-
Oberfläche visualisiert werden.
Das vorliegende Beispiel zeigt eine einfache Buildpipeline.
agent none: Das Skript wird auf der lokalen Maschine ausgeführt. Hier kann alter-
nativ auch ein Agent konfiguriert werden.
Jenkins unterstützt ein Agent-Master-Konstrukt. In diesem Konstrukt existiert ein
Master, der die Benutzeroberfläche und API-Endpoints bereitstellt. Agents stehen
mit dem Master in Verbindung und der Master kann Aufgaben auf den Agents auf-
teilen. In Kontext eines Builds kann dieser Mechanismus genutzt werden, um Last
aufzuteilen oder Build auf spezifischen Zielumgebungen auszuführen.
Weiter wurde im dem Beispiel eine Option skipStagesAfterUnstable definiert. Die-
se Option bewirkt, dass falls ein Stage mit dem Status Unstable verlassen wird,
keine weiteren Stages mehr aufgerufen werden. Ein Stage wird als Unstable mar-
kiert, wenn sie nicht den Returncode 0 zurück gibt. In diesem Beispiel, wenn ein
Maven Befehl nicht mit erfolgreich ist.
In der ersten Stage Build wird ein Maven-Build ausgeführt und explicit die Phase
Test übersprungen. Damit wird sichergestellt, dass diese Stage der Build nur fehl-
schlägt bei einem Fehler während des Builds.
In der nächsten Stage werden dann alle definierten Tests ausgeführt.
Seite 15Die letzte Stage deutet an, nach dem Build Software ausgeliefert werden könnte
und so eine Continuous Integration Pipeline zu einer Continuous Delivery Pipeline
wird.
Nachdem eine solche Datei in dem Repository abgelegt ist, muss eine Pipeline in
der Jenkinsoberfläche angelegt werden. In dieser Pipeline muss nun das Reposi-
tory angegeben werden und der Pfad zu der Jenkinsfile. Anschließend muss nur
noch der Trigger-Mechanismus ausgewählt werden. Für eine CI-Pipeline wird die
Option „trigger build after push“ ausgewählt. Diese Option bewirkt, dass in dem
Repository ein Webhook angelegt wird, durch den Jenkins informiert wird, wenn
eine Codeänderung stattgefunden hat und diese Pipeline wird angestoßen.
Möchte man zusätzlich zu einer solchen CI-Pipeline eine weitere Pipeline die zeit-
lich gesteuert ist, wie für einen Nightly Build, muss lediglich eine weitere Jenkins-
file angelegt werden, analog eine Pipeline erstellt werden und der Trigger-Mecha-
nismus zu „Build periodically“ angepasst werden. 15
6.1.5 Skalierbarkeit
Wie bereits erwähnt unterstützt Jenkins ein Master-Agent-Konstrukt und ist so
stark skalierbar. Agents können dabei statisch oder dynamisch sein. Ein statischer
Agent ist dabei dauerhaft erreichbar. Mit dynamischen Agents hingegen kann zu-
sätzlich Bedarf ein Container in einer Containerplattform wie Kubernetes oder eine
Virtuelle Maschine in einem Cloudservice wie AWS.
Da Jenkins kostenfrei ist könnte zusätzlich ganze Jenkins Instanzen aufgebaut
werden. 16
6.1.6 Wartung
Jenkins ist ein Wartungsintensives Tool. Versionsupdates müssen eigenständig
durchgeführt werden. Jenkins wird mit kaum Funktionalität ausgeliefert werden.
Verwendete Plugins administriert werden. Außerdem müssen alle Benötigten Um-
gebungen und Tools verwaltet werden.
6.1.7 Fazit
Jenkins ist durch seine starke Erweiterbarkeit ein mächtiges Tool und kann als
vollwertiger Automationsserver ein breites Spektrum an Anwendungsfällen abde-
cken, die weit über die Funktionalität eines klassischen Build-Servers hinaus ge-
hen. Ein weiteres Argument für das Tool ist, dass es kostenfrei ist.
Andererseits ist die initiale Konfiguration, Administration und Wartung des Systems
zeitintensiv und Testumgebungen müssen bereitgestellt werden.
Seite 166.2 Travis CI
Travis CI ist eine Webanwendung, die Continuous Integration für in Github liegen-
de Projekte bereitstellt. Besonders an diesem Tool ist, das Travis CI für jeden Build
eine separate Virtuelle Maschine hochfährt und so ein breitest Spektrum an Lauf-
zeitumgebungen für verschiedene Anwendungsfälle von Haus aus bereitstellen
kann.
6.2.1 Bereitstellung und Kosten
Travis CI ist für open-source Projekte kostenfrei verwendbar unter der Webseite
travis-ci.org. Für private Projekte muss die Webpage travis-ci.com verwendet wer-
den. Zusätzlich existiert die Möglichkeit Travis CI Enterprise zu verwenden. Hier
wird die Anwendung auf der eigenen Infrastructure gehostet. Travis CI Enterprise
ermöglicht die Integration zu GitHub Enterprise, der self-hostet Enterprise-Version
von GitHub. Nur durch Vorhandensein von Travis CI Enterprise und GitHub Enter-
prise ist es möglich, dass sich Code ausschließlich auf der eigenen Infrastruktur
befindet.
Die kostenlose Verwendung über travis-ci.org wurde November 2020 abgekündigt.
Ein Termin für die Abschaltung des Systems ist noch nicht bekannt. 17
6.2.2 Versionsverwaltungssysteme
Aktuell unterstützt Travis CI Continuous Integration ausschließlich Projekte die von
GitHub verwalten werden. Die Integration zu Bitbucket und Gitlab befindet sich ak-
tuell in der beta-Entwicklungsphase.
6.2.3 Sprachen und Buildtools
Die von Travis CI bereitgestellten virtuellen Maschinen unterstützen die Betriebs-
systeme Linux, MacOS und Windows. Weiter stehen Laufzeitumgebungen und die
sprachspezifischen Standard-Buildtools zu folgenden Sprachen bereit: C, C++,
C#, Clojure, Crystal, D, Dart, Elixir, Erlang, F#, Go, Groovy, Haskell, Haxe, Java,
JavaScript, Julia, Objective-C, Perl, PHP, Python, R, Ruby, Rust, Scala, Smalltalk,
Swift und Visual Basic. 18
19 Anhang befindet sich eine default Konfiguration einer bereitgestellten virtuellen
Maschine mit Linux Betriebssystem inklusive installierter Tools.
Seite 17Hervorzuheben ist, dass Travis CI zusätzlich Builds für Android- und iOS-Projekte
ermöglicht. Außerdem werden zum Testen Webanwendungen verschiedene Web-
browser bereitgestellt.
6.2.4 Anwendung
Die Verwendung von Travis CI unterscheidet sich zwischen kostenfreien und kos-
tenpflichtigen Versionen nicht. Zunächst wird ein GitHub-Account mit Besitzer-Be-
rechtigungen für das gewünschte Repository benötigt.
In der Travis CI Weboberfläche meldet man sich mit den GitHub Benutzerdaten an
und kann nun für alle eigenen GitHub-Projekte Travis CI aktivieren. Durch das Ak-
tivieren wird im GitHub-Projekt ein Webhook zu Travis CI angelegt, sodass Travis
CI in Zukunft immer Informationen über Änderungen im Projekt erhält.
In der Travis CI Oberfläche kann nun konfiguriert werden, ob Builds nach jedem
Commit, nach jedem Merge und/oder nur händisch angestoßen werden.
Bei angestoßenem Build sucht Travis CI nach einer YAML-Datei mit den
Namen .travis.yml im Root-Verzeichnis des Projektes.
Die .travis.yml -Datei für ein Maven Projekt kann beispielsweise so aussehen:
os: linux
language: java
jdk:
- oraclejdk8
- oraclejdk9
- openjdk8
Für jeden Build stellt Travis CI eine virtuelle Maschine bereit. Mit dem os-Tag wird
definiert, welches Betriebssystem die virtuelle Maschine benutzt.
Das language-Tag definiert in welcher Sprache das Projekt geschrieben ist. Für
Java unterstützt Travis CI Gradle, Maven und Ant und sucht nun im Projekt Code
nach zugehörigen Konfigurationsdateien. Im Falle eines Maven Projektes wird die
pom.xml gefunden und Travis CI weiß, das es sich um ein Maven Projekt handelt.
Mit dem jdk-Tag können die Java Development Kit Versionen ausgewählt werden,
für die ein Build durchgeführt werden soll. Da im Beispiel drei Versionen angege-
ben werden, werden auch drei Builds mit jeweils einer separaten virtuellen Ma-
schine.
Da hier nicht weiter definiert werden für den Build folgende Maven-Befehle ausge-
führt.
Zunächst wird „mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V“
ausgeführt.
Seite 18Dieser Befehl baut das Programm, führt jedoch keine Tests durch und generiert
keine Javadoc-Dateien.
Anschließend werden die Testfälle durchlaufen durch den Befehl „mvn test -B“.
Status und Ergebnis des Builds können jetzt in der Travis CI Oberfläche eingese-
hen werden. Bei Builds, die von einem neuen Commit angestoßen werden, sind
diese Informationen von GitHub aus nicht einsehbar.
Bei Pullrequests hingegen wird im Conversations-Reiter des Pullrequests der ak-
tuelle Status des Builds dargestellt.
Daraus folgt, dass Teams sinnvoller Weise, Änderungen auf den Master-Branch
ausschließlich über Pullrequest auszurollen. 20
6.2.5 Skalierbarkeit
Bedingt durch die Tatsache, das für jeden Build eine eigene virtuelle Maschine
verwendet wird, laufen Builds und Tests parallel. Beim Verwenden der Travis CI
Infrastruktur hängt die Menge der möglichen parallelen Builds gekoppelt an den
verwendeten Tarif. Eine explizite Obergrenze wird nicht angegeben.
Beim Verwenden von Travis CI Enterprise ist die Skalierbarkeit begrenzt durch die
eigene Infrastruktur.
6.2.6 Wartung
Beim Verwenden der Travis CI Infrastrukturen über die Webseiten travis-ci.org
oder travis-ci.com fallen keine Wartungsarbeiten an.
Die Wartungsarbeit beim Verwenden von Travis CI Enterprise wurden im Rahmen
dieser Arbeit nicht untersucht.
6.2.7 Fazit
Travis CI besticht vor allem durch seine einfache Handhabung. Das Einbinden ei-
nes Testprojektes in einen vollwertigen Continuous Integration Prozess hat wenige
Minuten benötigt. Außerdem ist die breite Unterstützung für Sprachen und Tools
hervorzuheben. Zusätzlich fallen keine keine Wartungsarbeiten an.
Im Rahmen dieser Arbeit wurde die kostenfreie Version verwendet. Hier sind hohe
Wartezeiten bei der Initialisierung der virtuellen Maschinen aufgetreten. Inwieweit
dies auch für kostenpflichtige Versionen gilt, wurde nicht weiter untersucht.
Negativ zu erwähnen ist, das aktuell nur GitHub unterstützt wird. Außerdem ist der
Informationsaustausch zwischen Travis CI und GitHub ausbaufähig. Zum einen
sind ausführliche Buildinformationen nur unter Travis CI einsehbar, Sourcecode
Seite 19hingegen nur über GitHub. Zusätzlich werden zwingend Owner-Berechtigungen
benötigt, um in Travis CI Buildinformationen einsehen zu können.
6.3 GitLab CI/CD
6.3.1 Bereitstellung und Kosten
GitLab CI/CD ist ein in Gitlab eingebautes Continuous Integration Tool. Wenn be-
reits Gitlab als Verwaltungstool verwendet wird entfällt damit die Bereitstellung ei-
nes weiteren Tools.
Gitlab kann auf der eigenen Infrastruktur kostenlos in der Community Edition ver-
wendet werden oder mit zusätzlichem Funktionen und Support kostenpflichtig als
Enterprise Edition.
Zusätzlich kann GitLab unter der Webadresse gitlab.com verwendet werden.
Alle Varianten unterstützten das Tool GitLab CI/CD. 21
Mit dem Tool definierten Builds werden nicht auf dem GitLab Server selbst, son-
dern auf extra bereitgestellten leichtgewichtigen Agents, den sogenannten Run-
nern ausgeführt.
Projekte, die die GitLab Webadresse verwenden, können bereitgestellte Runner
verwenden. Für alle anderen Anwendungsfälle muss mindestens ein Runner kon-
figuriert werden. 22
6.3.2 Versionsverwaltungssysteme
Da das Tool in GitLab integriert ist, wird als Versionsverwaltungssystem aus-
schließlich GitLab unterstützt.
6.3.3 Sprachen und Buildtools
Es können alle Sprachen und Buildtools verwendet werden, die dem verwendeten
Runner zur Verfügung stehen.
6.3.4 Anwendung
Um für ein GitLab-Projekt eine Continuous Integration Pipeline zu implementieren,
muss lediglich eine YAML-Datei namens .gitlab-ci.yml. Ab diesem Moment wird
nach jedem Commit oder Pullrequest eine in der Datei konfigurierten Pipeline an-
gestoßen.
Seite 20Eine einfache Pipeline für den Build eines Maven-Projektes kann so aussehen:
image: maven:latest
build:
stage: build
script:
- mvn install -DskipTests=true
test:
stage: test
script:
- mvn test
Das zugehörige Projekt liegt verwendet die GitLab Infrastruktur unter gitlab.com
und verwendet einen in dieser Umgebung bereitgestellten GitLab Runner.
Diese Runner verfügen nicht über viele vorinstallierte Tools.
GitLab empfiehlt zur Bereitstellung von Tools die Verwendung von Images des
Containertools Docker.
Mit dem ersten Befehl image: maven:latest lädt der Runner ein Image mit der ak-
tuellen Maven-Version runter. Die anschließenden Builds finden innerhalb dieses
Images statt.
Die Pipeline ist in die beiden Stages build und test aufgeteilt. Die Funktionalität der
Skripte wurde bereits erläutert.
Im Anhang befindet sich ein Bildschirmfoto, dass die Integration des Tools in die
Weboberfläche zeigt (siehe GitLab CI/CD WebUI). 23
6.3.5 Skalierbarkeit
Gitlab CI/CD ist durch das Verwenden von Runnern gut skalierbar. Runner können
analog zu Jenkins Agents statisch oder dynamisch sein (siehe Jenkins/Skalierbar-
keit). 24
GitLab stellt Dokumentation zum Aufbau von Runnern in den gängigen Betriebs-
systemen bereit. Hervorzuheben ist hier die Cloudkompatibilität durch das Contai-
ner-Orchestrierungstool Kubernetes. 25
6.3.6 Wartung
Potentiell anfallende Wartungsarbeiten sind überschaubar.
Beim Verwenden der Infrastruktur GitLabs fallen nur Arbeiten, wenn ein eigener
Runner verwendet wird.
Seite 21Da GitLab CI/CD in GitLab integriert ist, deckt die bisherige Pflege von GitLab
auch das CI-Tool ab. Auch hier gilt, dass nur die Instandhaltung der Runner als
Mehraufwand auftreten.
6.3.7 Fazit
GitLab CI/CD ist ein vielseitig einsetzbares Tool für Continuous Integration und De-
livery.
Es ist einerseits durch die Verwendung selbstdefinierter Runner, ähnlich wie bei
der Verwendung von Jenkins-Agents, für jeden Anwendungsfall konfigurierbar. Hat
jedoch den Vorteil, dass das Benutzer-Oberfläche in GitLab integriert ist. Damit
sind zum einen alle Informationen bzgl. Code und Buildstatus für den Entwickler
innerhalb einer Weboberfläche einsehbar. Zum anderen muss, um Continuous In-
tegration verwenden zu können, kein weiteres Tool neben dem Versionskontroll-
tool bereitgestellt und gepflegt werden.
Seite 227 Schlusswort
Continuous Integration gilt heute nicht ohne Grund als Best Practice.
Zur Verwendung von Continuous Integration in einem Team oder einem Unter-
nehmen, ist initial die Umstellung gewohnter Prozesse und Arbeitsstrukturen nötig.
Gegebenenfalls muss der Build-Prozess mit einem Buildtool formalisiert und zuvor
händisch durchgeführte Tests automatisiert werden.
Hinzu kommt das Bereitstellen eines Automationstool und dessen Konfiguration.
Dieser Prozess kann von einem einmaligen Erstellen und Konfigurieren eines
Kontos auf einer Webseite bis zum Aufbau einer ganzen Infrastruktur mit Schnitt-
stellen zu Kubernetes-Clustern in Cloud-Umgebungen reichen, für dessen War-
tung und Administration ganze Teams zuständig sind.
Trotz hohem initialen Zeit- und Kostenaufwand, langfristig bringt die Continuous
Integration einem Projekt Mehrwert.
CI fördert das Modularisieren von Projekten. Durch die permanente Integration
von Codeänderungen in das Programm ist, bekommt der Entwickler direktes
Feedback. Durch kleine Codeänderung werden Fehlerquellen eingegrenzt und
das Analysieren und Beheben von Fehlern beschleunigt.
Außerdem erleichtern viele kleine Änderungen das Zusammenführen unterschied-
licher Entwicklungsstände und die Dokumentation von Änderungen wird klein-
schrittig und somit nachvollziehbarer.
Weiter steht stets eine aktuelle und lauffähige Version des Programmes zur verfü-
gung.
Seite 238 Anhang
8.1 Default Configuration einer Travis CI VM
Server:
Engine:
Version: 18.06.0-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: 0ffa825
Built: Wed Jul 18 19:09:05 2018
OS/Arch: linux/amd64
Experimental: false
[34m[1mclang version[0m
clang version 7.0.0 (tags/RELEASE_700/final)
[34m[1mjq version[0m
jq-1.5
[34m[1mbats version[0m
Bats 0.4.0
[34m[1mshellcheck version[0m
0.7.0
[34m[1mshfmt version[0m
v2.6.3
[34m[1mccache version[0m
3.2.4
[34m[1mcmake version[0m
cmake version 3.12.4
[34m[1mheroku version[0m
heroku/7.42.1 linux-x64 node-v12.16.2
[34m[1mimagemagick version[0m
Version: ImageMagick 6.8.9-9 Q16 x86_64 2019-11-12 http://www.imagemagick.org
[34m[1mmd5deep version[0m
4.4
[34m[1mmercurial version[0m
version 4.8
[34m[1mmysql version[0m
mysql Ver 14.14 Distrib 5.7.30, for Linux (x86_64) using EditLine wrapper
[34m[1mopenssl version[0m
OpenSSL 1.0.2g 1 Mar 2016
[34m[1mpacker version[0m
1.3.3
[34m[1mpostgresql client version[0m
psql (PostgreSQL) 10.13 (Ubuntu 10.13-1.pgdg16.04+1)
[34m[1mragel version[0m
Ragel State Machine Compiler version 6.8 Feb 2013
[34m[1msudo version[0m
1.8.16
[34m[1mgzip version[0m
gzip 1.6
[34m[1mzip version[0m
Zip 3.0
[34m[1mvim version[0m
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 18 2020 14:06:17)
[34m[1miptables version[0m
iptables v1.6.0
[34m[1mcurl version[0m
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 li-
brtmp/2.3
[34m[1mwget version[0m
GNU Wget 1.17.1 built on linux-gnu.
[34m[1mrsync version[0m
Seite 24rsync version 3.1.1 protocol version 31
[34m[1mgimme version[0m
v1.5.4
[34m[1mnvm version[0m
0.35.3
[34m[1mperlbrew version[0m
/home/travis/perl5/perlbrew/bin/perlbrew - App::perlbrew/0.88
[34m[1mphpenv version[0m
rbenv 1.1.2-30-gc879cb0
[34m[1mrvm version[0m
rvm 1.29.10 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io]
[34m[1mdefault ruby version[0m
ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
[34m[1mCouchDB version[0m
couchdb 1.6.1
[34m[1mElasticSearch version[0m
5.5.0
[34m[1mInstalled Firefox version[0m
firefox 63.0.1
[34m[1mMongoDB version[0m
MongoDB 4.0.19
[34m[1mPhantomJS version[0m
2.1.1
[34m[1mPre-installed PostgreSQL versions[0m
9.4.26
9.5.22
9.6.18
[34m[1mRedis version[0m
redis-server 6.0.5
[34m[1mPre-installed Go versions[0m
1.11.1
[34m[1mant version[0m
Apache Ant(TM) version 1.9.6 compiled on July 20 2018
[34m[1mmvn version[0m
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
[34m[1mgradle version[0m
Gradle 5.1.1!
[34m[1mlein version[0m
Leiningen 2.9.3 on Java 11.0.2 OpenJDK 64-Bit Server VM
[34m[1mPre-installed Node.js versions[0m
v10.21.0
v11.0.0
v12.18.1
v4.9.1
v6.17.1
v8.12.0
v8.17.0
v8.9
[34m[1mphpenv versions[0m
system
5.6
5.6.40
7.1
7.1.27
7.2
* 7.2.15 (set by /home/travis/.phpenv/version)
hhvm
hhvm-stable
[34m[1mcomposer --version[0m
Composer version 1.8.4 2019-02-11 10:52:10
[34m[1mPre-installed Ruby versions[0m
ruby-2.3.8
ruby-2.4.5
ruby-2.5.3
Seite 258.2 Pullrequest Message mit TravisCI
8.3 GitLab CI/CD WebUI
Seite 269 Quellen
1 vgl. Agile Sofwareentwicklung. https://de.wikipedia.org/wiki/Agile_Softwareentwicklung
(Stand 5.12.2020)
2 vgl. Lukas Körfer - CI/CD & Build-Tools - was ist das eigentlich?. https://www.it-ta-
lents.de/blog/it-talents/alles-ueber-den-build-prozess (Stand 4.12.2020)
3vgl. Sachin Patil - What is a Makefile and how does it work?. https://opensource.com/
article/18/8/what-how-makefile (Stand 1.12.2020)
4 vgl. Introduction to the Build Lifecycle. https://maven.apache.org/guides/introduction/
introduction-to-the-lifecycle.html (Stand 1.12.2020)
5 vgl. Gradle. https://de.wikipedia.org/wiki/Gradle (Stand 4.12.2020)
6 Kontinuierliche Integration. https://de.wikipedia.org/wiki/Kontinuierliche_Integration
(Stand 1.12.2020)
7vgl. Extreme Programming. https://de.wikipedia.org/wiki/Extreme_Programming (Stand
10.12.2020)
8vgl.Kontinuierliche Integration. https://de.wikipedia.org/wiki/Kontinuierliche_Integration
(Stand 1.12.2020)
9 vgl. Continuous Integration https://www.ionos.de/digitalguide/websites/web-entwick-
lung/continuous-integration/ (Stand 1.12.2020)
10 vgl. Nightly Build https://de.wikipedia.org/wiki/Nightly_Build (Stand 2.12.2020)
11 vgl. il1411 - Was ist DevOps?. https://www.dev-insider.de/was-ist-devops-a-570286/
12vgl. Jenkins (Software). https://de.wikipedia.org/wiki/Jenkins_(Software)
Stand(8.12.2020)
13vgl. Jenkins (Software). https://de.wikipedia.org/wiki/Jenkins_(Software) (Stand
8.12.2020)
14 vgl. Installing Jenkins. https://www.jenkins.io/doc/book/installing/ (Stand 8.12.2020)
15vgl. Build a Java app with Maven. https://www.jenkins.io/doc/tutorials/build-a-java-
app-with-maven/ (Stand 8.12.2020)
16vgl. Using Agents. https://www.jenkins.io/doc/book/using/using-agents/ (Stand
8.12.2020)
17 vgl. Travis CI. https://en.wikipedia.org/wiki/Travis_CI (Stand 14.12.2020)
18 vgl. https://docs.travis-ci.com (Stand 6.12.2020)
19 vgl. Apps, Clients and Tools. https://docs.travis-ci.com/user/apps/ (Stand 6.12.2020)
20vgl. Building a Java project. https://docs.travis-ci.com/user/languages/java/ (Stand
6.12.2020)
21 vgl. GitLab. https://de.wikipedia.org/wiki/GitLab (Stand 6.12.2020)
22vgl. Configuring runners in GitLab. https://docs.gitlab.com/ee/ci/runners/README.html
(Stand 6.12.2020)
Seite 2723vgl. How to deploy Maven projects to Artifactory with GitLab CI/CD. https://docs.gitla-
b.com/ee/ci/examples/artifactory_and_gitlab/ (Stand 6.12.2020)
vgl. Configuring runners in GitLab. https://git.fh-aachen.de/help/ci/runners/READ-
24
ME.md (Stand 6.12.2020)
25 Kubernetes. https://de.wikipedia.org/wiki/Kubernetes (Stand 6.12.2020)
Seite 28Sie können auch lesen
