See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/346053222

Maßnahmen zur Steigerung der Software-Qualität durch Continuous

Integration als Teil von DevOps in österreichischen KMU

Thesis · February 2019

DOI: 10.13140/RG.2.2.29227.67362

CITATIONS READS

0 515

1 author:

Markus Meierhofer

2 PUBLICATIONS 0 CITATIONS

SEE PROFILE

All content following this page was uploaded by Markus Meierhofer on 21 November 2020.

The user has requested enhancement of the downloaded file.

 BACHELORARBEIT

MASSNAHMEN ZUR STEIGERUNG DER SOFTWARE-QUALITÄT DURCH

CONTINUOUS INTEGRATION ALS TEIL VON DEVOPS IN ÖSTERREICHISCHEN
KMU

ausgeführt an der

am Studiengang
Wirtschaftsinformatik

Von: Markus Meierhofer

Personenkennzeichen: 1610319050

Graz, am … .............................................................
Unterschrift
EHRENWÖRTLICHE ERKLÄRUNG

Ich erkläre ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst,
andere als die angegebenen Quellen nicht benützt und die benutzten Quellen wörtlich zitiert sowie
inhaltlich entnommene Stellen als solche kenntlich gemacht habe.

.............................................................
Unterschrift

I
DANKSAGUNG

An dieser Stelle möchte ich mich bei meinem Betreuer, Herrn DI Markus Petelinc, für die
hervorragende Unterstützung bedanken. Durch Ihre Unterstützung konnten alle meine Fragen
geklärt und die Arbeit korrekt umgesetzt werden.

Bedanken möchte ich mich auch bei meinen Eltern, Andrea und Gerhard, und besonders bei
meiner Freundin, Nina, dass sie mir während der Arbeit zur Seite gestanden ist und viele
Aufgaben übernommen hat.

II
KURZFASSUNG

Die Praxis Continuous Integration hat sich in Softwareunternehmen als ein Standard bei der
Entwicklung etabliert. Oftmals wird diese Praxis jedoch nicht effektiv umgesetzt. Das Ziel dieser
Arbeit ist die Präsentation von Maßnahmen, die umgesetzt werden können, um Continuous
Integration effektiv zur Steigerung der Software-Qualität einzusetzen, wobei sich die genannten
Maßnahmen auf österreichische KMU fokussieren. Außerdem wird Continuous Integration mit
dem aktuelleren Trend DevOps verglichen, welcher ähnliche Zielsetzungen besitzt.

Zur Beantwortung der Fragestellung dient eine systematische Literaturrecherche zu den

Themen DevOps und Continuous Integration und wie diese im Zusammenhang mit hoher
Software-Qualität stehen. Als Erstes wird der Begriff DevOps definiert und ein Überblick über
Methoden, Ideen und Praktiken gegeben, auf welche DevOps basiert. Danach wird die
Verbindung zwischen Continuous Integration und DevOps beschrieben. Es werden weiters die
Bestandteile der Umsetzung von Continuous Integration dargestellt und geklärt, wie Continuous
Integration zur Erreichung hoher Software-Qualität beiträgt.

Abschließend werden einerseits Herausforderungen österreichischer KMU bezüglich hoher

Software-Qualität recherchiert und analysiert, welche dieser Herausforderungen durch
Continuous Integration bewältigt werden. Andererseits werden konkrete Maßnahmen
präsentiert, durch welche Continuous Integration qualitätssteigernd eingesetzt werden kann.

Es zeigt sich, dass eine zumindest tägliche Integration der Quellcode-Änderungen zwischen
EntwicklerInnen ein wichtiges Kriterium zur Qualitätssteigerung darstellt. Ein besonderer Fokus
muss unter anderem auch auf automatisierte Tests auf allen Ebenen gelegt werden, um
komplexe Software effektiv testen zu können. Schlussendlich benötigt die qualitätssteigernde
Umsetzung von Continuous Integration auch eine hohe Teamdisziplin, um die dadurch
gewonnenen Erkenntnisse bezüglich der Software-Qualität auch zu berücksichtigen.

III
ABSTRACT

Continuous Integration is an established development practice in many software development

companies, but it is often not effectively implemented. The aim of this thesis is to present
measures by which Continuous Integration can be used effectively to raise the software quality
in Austrian small and medium-sized enterprises (SMEs). In addition, Continuous Integration is
compared to the more recent trend DevOps, which has similar goals.

The thesis uses systematic literature research on the topics DevOps and Continuous Integration
and how they are connected to software quality. First, the term DevOps is defined and an
overview over the methods, ideas and practices that DevOps bases on is given. Then the
connection between Continuous Integration and DevOps is defined. Also, the different
components of the implementation of Continuous Integration are shown and how they contribute
to higher software quality.

Finally, challenges of Austrian SMEs regarding to software quality are researched and it is
analysed which of those challenges can be overcome by using Continuous Integration. The
thesis concludes with the presentation of several measures to use Continuous Integration to
raise software quality.

The results show that an at least daily integration of developers’ code changes is crucial to
increase software quality by Continuous Integration. A special focus should also be laid on
having automated tests on all layers to effectively test complex software. Quality increases
ultimately also need a high team discipline to use the insights given by Continuous Integration.

IV
INHALTSVERZEICHNIS

1 EINLEITUNG .................................................................................................................................... 1

1.1 Forschungsfrage ............................................................................................................................... 1

1.2 Methode ............................................................................................................................................ 1

2 EINFÜHRUNG IN DEVOPS ............................................................................................................. 3

2.1 Definition ........................................................................................................................................... 3

2.2 Entstehung ........................................................................................................................................ 5
2.3 Grundlegende Konzepte, Methoden und Tools ................................................................................ 6
2.3.1 Lean ..................................................................................................................................... 6
2.3.2 Agile Softwareentwicklung ................................................................................................... 7
2.3.3 Versionsverwaltung ............................................................................................................. 8
2.3.4 Testgetriebene Entwicklung ................................................................................................ 8

2.4 Kulturelle Veränderungen bei der Einführung .................................................................................. 9

2.4.1 Verbesserung der Zusammenarbeit .................................................................................... 9
2.4.2 Kontinuierliche Verbesserung ............................................................................................ 10
2.4.3 Teamkultur entwickeln ....................................................................................................... 11

2.5 Ziele ................................................................................................................................................ 11

3 CONTINUOUS INTEGRATION (CI) ............................................................................................... 13

3.1 Definition ......................................................................................................................................... 13

3.2 Abgrenzung zu ähnlichen Praktiken ............................................................................................... 15
3.2.1 Continuous Delivery/Deployment ...................................................................................... 15
3.2.2 Trunk Based Development ................................................................................................ 16

3.3 Voraussetzungen für das Betreiben von CI .................................................................................... 17

3.3.1 Versionsverwaltung ........................................................................................................... 17
3.3.2 Automatisierter Build-Prozess ........................................................................................... 18
3.3.3 Automatisierte Tests .......................................................................................................... 20
3.3.4 Methode der kontinuierlichen Integration .......................................................................... 21

3.4 Zusätzliche Bestandteile einer CI Pipeline ..................................................................................... 22

3.4.1 Automatische Datenbankintegration.................................................................................. 22

V
 3.4.2 Automatische Code-Inspektionen...................................................................................... 23
3.4.3 Automatisches Software-Deploy ....................................................................................... 24

3.5 Vorteile von CI bezüglich Software-Qualität ................................................................................... 24

4 HOHE SOFTWARE-QUALITÄT VON KMU DURCH CI ............................................................... 26

4.1 Eigenschaften österreichischer (Software-)KMU ........................................................................... 26

4.2 Aspekte von Software-Qualität ....................................................................................................... 26
4.3 Herausforderungen hoher Software-Qualität ................................................................................. 27
4.4 Welche Herausforderungen durch CI bewältigt werden ................................................................. 28

5 MASSNAHMEN ZUR STEIGERUNG DER SOFTWARE-QUALITÄT DURCH CI........................ 30

5.1 Tägliche und schnelle Integration der Änderungen ........................................................................ 30

5.2 Hoher Grad automatisierter Tests auf allen Ebenen ...................................................................... 31
5.3 Sinnvolle automatisierte Inspektionen ............................................................................................ 32
5.4 CI Pipeline mit mehreren Phasen ................................................................................................... 33
5.5 Hohe Teamdisziplin ........................................................................................................................ 33

6 CONCLUSIO UND AUSBLICK ...................................................................................................... 35

ABKÜRZUNGSVERZEICHNIS ................................................................................................................ 37

ABBILDUNGSVERZEICHNIS ................................................................................................................. 38

LITERATURVERZEICHNIS ..................................................................................................................... 39

VI
1 EINLEITUNG

Der Begriff DevOps hat seit seiner Popularisierung durch die DevOpsDays-Konferenz eine hohe
Bedeutung in der Softwareentwicklungsbranche gewonnen. Viele Konferenzen im Bereich der
Softwareentwicklung und Magazine besitzen Abschnitte über DevOps. Besonders Software-
Lösungen im Bereich von Infrastructure as Code, Containerization und Cloud-Computing werden
hier als Tools, also Software-Werkzeuge, zur Umsetzung von DevOps beworben. Diese Arbeit
soll den Begriff DevOps definieren und seine Bestandteile, Geschichte und Zielsetzungen näher
betrachten. Dabei wird klargestellt, dass DevOps nicht von spezifischen Tools abhängig ist,
sondern eine breitere Sammlung von Ideen, Praktiken und Tools mit gemeinsamen Zielen
darstellt.

Danach wird Continuous Integration als wichtiger Bestandteil für die Erreichung der Ziele von
DevOps hervorgehoben und wichtige Aspekte von dessen Umsetzung beschrieben. Auch werden
die Herausforderungen österreichischer Software-KMU bei der Erreichung hoher Software-
Qualität analysiert und geklärt, welche dieser Herausforderungen durch Continuous Integration
bewältigt werden können.

1.1 Forschungsfrage
Die folgende Arbeit soll die Frage klären, welche Maßnahmen ergriffen werden müssen, um
Continuous Integration zur Qualitätssteigerung von Software einzusetzen. Dabei werden die
dargestellten Maßnahmen auf österreichische Software-KMU bezogen und wie diese dort
Vorteile bezüglich Software-Qualität erzeugen können. Es soll auch geklärt werden, wie
Continuous Integration sich in den größeren Kontext von DevOps integriert und wie diese Themen
zusammenhängen.

1.2 Methode
Die zur Beantwortung der Forschungsfrage benötigten Daten wurden mittels Literaturrecherche
in Online-Suchmaschinen gewonnen. Bezüglich der Theorie zu DevOps und Continuous
Integration wurden hier die bekanntesten und am meisten referenzierten Werke und Artikel
recherchiert und als Grundlage für die Aufarbeitung der Themen herangezogen. Auch die
Herausforderungen von österreichischen KMU bei der Erreichung hoher Software-Qualität
wurden durch Internet-Recherche erhalten. Schließlich wurden die Vorteile von Continuous
1
Integration bezüglich Software-Qualität und effektive Maßnahmen zu deren Umsetzung aus den
inkludierten Quellen gewonnen.

2
2 EINFÜHRUNG IN DEVOPS

Das Konzept, das mit der DevOps-Bewegung im Jahr 2009 entstanden ist, hat mittlerweile in der
Softwareentwicklungsbranche eine große Bedeutung. Viele Unternehmen versuchen daher, die
dahinterliegenden Konzepte und Praktiken selbst einzuführen. Dies nicht nur aufgrund dessen,
dass DevOps in der Softwarebranche in Mode ist, sondern auch, weil dessen Effektivität bereits
in Studien nachgewiesen wurde.

Puppet Labs (2015) belegen statistisch, dass die Umsetzung von DevOps unternehmerische
Vorteile bringt. Unternehmen, die DevOps effektiv umgesetzt haben, haben beispielsweise 60-
mal weniger Probleme mit Ausfällen ihrer Systeme und beheben diese Ausfälle 168-mal
schneller.

Dieses Kapitel soll eine Einführung in die DevOps-Bewegung geben und welche Beweggründe,
fundamentalen Konzepte und Werkzeuge dahinterliegen.

2.1 Definition
Der Begriff DevOps ist ein Kofferwort aus den Begriffen „Development“ und „Operations“, also
den Entwicklungsabteilungen und IT-Betriebsabteilungen eines Unternehmens. Das
ursprüngliche Ziel von DevOps ist die Verbesserung der Zusammenarbeit zwischen diesen
Abteilungen, jedoch soll durch DevOps auch die Zusammenarbeit mit weiteren Abteilungen
erhöht werden. (Davis & Daniels, 2016, S. 14; Verona, 2016, S. 2)

Eine einheitliche Definition von DevOps ist in der Fachliteratur selten.

Mehrere Definitionen und Erklärungen betrachten DevOps als hauptsächlich kulturellen Wandel:

Devops is a cultural movement that changes how individuals think about their work,

values the diversity of work done, supports intentional processes that accelerate the

rate by which businesses realize value, and measures the effect of social and
technical

change. It is a way of thinking and a way of working that enables individuals and

organizations to develop and maintain sustainable work practices. It is a cultural

framework for sharing stories and developing empathy, enabling people and teams to

practice their crafts in effective and lasting ways. (Davis & Daniels, 2016, S. 13)

3
Eine andere Definition stellt gemeinsame Ziele, Prozesse und Werkzeuge zwischen den
Abteilungen in den Mittelpunkt der Betrachtung von DevOps:

DevOps is a mix of patterns intended to improve collaboration between development

and

operations. DevOps addresses shared goals and incentives as well as shared

processes

and tools. Because of the natural conflicts among different groups, shared goals and

incentives may not always be achievable. However, they should at least be aligned
with

one another. (Hüttermann, 2012, S. 8)

Es sind also zur Umsetzung von DevOps in erster Linie Änderungen an der Betriebskultur
vorzunehmen, wobei zusätzlich Praktiken und Werkzeuge die Ziele von DevOps unterstützen.
(Walls, 2013, S. 1)

In mehreren Quellen wird DevOps auch darüber definiert, was es nicht ist, um eine bessere
Abgrenzung zu anderen Bewegungen und Frameworks in der Softwareentwicklung und IT-
Operations zu erhalten. Es sollte beispielsweise nicht zur Umsetzung von DevOps ein eigenes
Team eingesetzt werden, welches zwischen EntwicklerInnen und IT-Operations MitarbeiterInnen
vermittelt. Dieses Vorgehen widerspricht der grundlegenden Idee, dass das Abteilungsdenken in
Unternehmen abgebaut und auf gemeinsame Ziele hingearbeitet werden muss. Ebenso wenig
Sinn macht die mittlerweile häufige Job-Bezeichnung „DevOps Engineer“, welche die Arbeiten
von Entwicklung und IT-Betrieb in einem Beruf vereinen soll. Diese Kombination funktioniert in
großen Unternehmen nicht, da eine Spezialisierung auf bestimmte Tätigkeiten notwendig wird.
Auch ist das Hauptziel von DevOps nicht die Zusammenlegung der Entwicklungs- und IT-
Operations-Tätigkeiten, sondern die Verbesserung der Zusammenarbeit zwischen diesen
Tätigkeitsbereichen. (Davis & Daniels, 2016, S. 46f.; Hüttermann, 2012, S. 9f.)

Ein weiteres Missverständnis bei der Umsetzung von DevOps ist die Annahme, dass es einen
richtigen Weg für die Umsetzung von DevOps gibt. Mit der Einführung von vorgefertigten
Entwicklungspraktiken und Werkzeugen, welche auch von Vorreitern der DevOps-Bewegung
eingesetzt werden, wird versucht, schnelle Erfolge zu erzielen. Da es bei DevOps aber zu einem
großen Teil um kulturelle Änderungen geht, die auch ständiges Lernen beinhalten, können
Erfolge nicht einfach durch Kopieren von Praktiken anderer reproduziert werden. (Davis &
Daniels, 2016, S. 49; Hüttermann, 2012, S. 10f.)

4
Das Nachahmen von Prozessen und Praktiken anderer Unternehmen kann als Cargo-Kult
bezeichnet werden. Als Cargo-Kult wurde ursprünglich eine religiöse Bewegung aus Melanesien
bezeichnet, welche nach Ende des Zweiten Weltkriegs entstanden ist. Da die dortigen
Inselbewohner während des Zweiten Weltkriegs Flugzeuge auf ihrer Insel landen sahen und
diese wertvolle und nützliche Fracht (Cargo) brachten, wollten die Bewohner diese nach Ende
des Krieges wieder zurückholen, indem sie die Rahmenbedingungen nachahmten. Es wurden
Flugzeuge und Landebahnen nachgebaut, ohne zu verstehen, warum die Flugzeuge damals
kamen. Das gleiche Konzept lässt sich auf Software-Unternehmen übertragen, welche Praktiken
führender DevOps-Unternehmen direkt übernehmen, ohne über den dahinterliegenden Nutzen
und die Sinnhaftigkeit im eigenen Unternehmen nachzudenken. (Verona, 2016, S. 6)

2.2 Entstehung
Seitdem Software nicht mehr in direkter Abhängigkeit mit der Hardware steht, wird Entwicklung
und Betrieb von IT-Lösungen in den meisten Unternehmen getrennt. Zwischen Unternehmen
wurden hilfreiche Ideen und Konzepte nicht geteilt, da diese geheim sein sollten, um einen
Geschäftsvorteil für das eigene Unternehmen zu erreichen. Diese Einstellung erhöhte jedoch die
Gesamtkomplexität von IT-Systemen in den meisten Unternehmen, wodurch Abteilungen mit
Spezialwissen in vielen Gebieten nötig wurden. Es wurden zusätzliche Abteilungen wie
Systemadministration, Qualitätssicherung, Datenbanken und Netzwerkadministration
geschaffen, welche sich auf einen bestimmten Bereich konzentrierten, jedoch von anderen
Abteilungen recht abgekapselt waren und daher nicht auf gemeinsame Ziele hinarbeiteten. (Davis
& Daniels, 2016, S. 22f.)

Es besteht durch die unterschiedlichen Zielsetzungen von Entwicklung und IT-Operations ein
chronischer Konflikt: EntwicklerInnen wollen Änderungen so schnell wie möglich an den/die
Nutzer/in bringen, um Nutzen für diese/n zu schaffen. Für IT-Operations hingegen ist das
Hauptziel, stabile Software und IT-Systeme mit möglichst wenigen Ausfällen zu betreiben (Kim,
Humble, Debois & Willis, 2016, S. 17f.).

Es war jedoch bis vor einigen Jahren die Stabilität einer Software oft nicht vereinbar mit der
Umsetzung von Änderungen und Erweiterungen der Software. Eine der Haupttätigkeiten von IT-
Operations-MitarbeiterInnen, die mit dem Einführen neuer Software-Versionen verbunden war,
war oft die Stabilisierung des Systems nach einem Update. Durch die Installation von Software-
Aktualisierungen auf Produktionssystemen wurden oft kritische Probleme beziehungsweise
Ausfälle verursacht. Diese Probleme mussten dann zu problematischen Zeiten wie nachts oder
am Wochenende von IT-Operations-MitarbeiterInnen behoben werden (Kim et al., 2016), was
deren Ablehnung zu häufigen Software-Aktualisierungen nur verstärkte.

5
IT-Unternehmen erkannten dieses Problem und setzten erste Maßnahmen dagegen. Im Jahr
2009 hielten Paul Hammond und John Allspaw, Entwicklungs- und IT-Operations Manager der
Webseite Flickr, die Rede 10+ Deploys per Day: Dev and Ops Cooperation at Flickr, in der
präsentiert wurde, wie diese hohe Anzahl an Deployments, also der Installation von Software-
Änderungen in einer Produktionsumgebung, pro Tag möglich war (Davis & Daniels, 2016, S. 27f.).
Durch die positive Aufnahme der Rede durch die Anwesenden veranstalte der Softwareentwickler
Patrick Debois, der ebenfalls eine Verbesserung der Zusammenarbeit zwischen Entwicklung und
IT-Operations anstrebte, die Konferenz DevOpsDays. In sozialen Netzwerken wurde in
nachfolgenden Gesprächen über die Konferenz als Abkürzung DevOps verwendet, wodurch das
Wort als Begriff für diese Bewegung entstand (Verona, 2016, S. 2).

2.3 Grundlegende Konzepte, Methoden und Tools

Viele der Ideen der DevOps-Bewegung sind nicht neu. Es wurden teilweise bestehende Konzepte
aus anderen Branchen übernommen (z.B. Lean Software Development von Lean Manufacturing),
oder Konzepte auf größere Bereiche von Software-Unternehmen angewandt (z.B. Retrospektiven
aus dem agilen Softwareentwicklungsmodell Scrum auch in anderen Bereichen des
Unternehmens einsetzen). Ein Auszug Dieser und ihre Verbindung zu DevOps soll hier
dargestellt werden. Diese Grundlagen wurden aus Davis und Daniels (2016) und Kim et al. (2016)
übernommen.

2.3.1 Lean

Aus dem Studium des Toyota Produktionssystems wurde Anfang der 90er Jahre das Konzept
der Lean Production (in etwa schlanke Produktion) entwickelt. Die Hauptziele von Lean
Production bestehen im Eliminieren aller Arten von Verschwendung (Waste) und das Maximieren
von Kundennutzen. Da das Konzept einen generalisierbaren Hintergrund hat, wurde es auf
weitere Bereiche von Unternehmen beziehungsweise Unternehmen anderer Branchen
angewandt. (Davis & Daniels, 2016)

Aus diesen Bemühungen heraus ist schließlich Lean Software Development entstanden, welches
ebenfalls auf derselben Basis wie Lean Production beruht. Eines der Grundprinzipien dieses
Konzepts ist ebenfalls das Eliminieren aller Arten von Verschwendung. In Bezug auf die
Softwareentwicklung wird unter Verschwendung unter anderem unfertiger Code, Übergaben an
andere Mitarbeiter oder Verzögerungen verstanden (Poppendieck & Poppendieck, 2007). Die
Reduktion der genannten Arten von Verschwendung ist auch eine wichtige Zielsetzung für
DevOps. Unter unfertigem Code wird beispielsweise ungetesteter Code verstanden, der bei
DevOps zur Umsetzung von Automatisierung nicht vorhanden sein darf.

6
2.3.2 Agile Softwareentwicklung

Der Ansatz der agilen Softwareentwicklung war begründet in den Schwierigkeiten mit
traditionellen Entwicklungsmodellen wie dem Wasserfallmodell oder V-Modell, welche die
gesamte Spezifikation eines Software-Produkts der eigentlichen Entwicklung voranstellten.
Durch agile Entwicklungsmethoden, die ihren Ursprung in der Methode Extreme Programming
haben, sollten Änderungen an den Kundenanforderungen besser und schneller in die
Entwicklung integriert und die Qualität von Software durch Praktiken wie Testgetriebene
Entwicklung erhöht werden. (Davis & Daniels, 2016, S. 24)

Eine heutzutage weitverbreitete agile Entwicklungsmethode stellt Scrum dar, welches einige
wenige Rollendefinitionen und Abläufe enthält, um im Softwareentwicklungsprozess auf
Änderungen besser reagieren zu können. Die zu entwickelnden Features werden im Rahmen
von Sprints abgehandelt, zwei- bis vierwöchige Zyklen, in denen das Entwicklungsteam die
Änderungen plant und umsetzt. Zusätzlich wird ein tägliches kurzes Meeting namens Daily Scrum
abgehalten, in dem die EntwicklerInnen ihren Status abklären und Probleme ansprechen können.
Ein Product Owner kümmert sich um das Erheben und Definieren der Anforderungen. Der Scrum
Master ist dafür zuständig, dem Entwicklerteam Hilfe bei der Einhaltung des Scrum-Prozesses
zu geben. (Schwaber & Sutherland, 2017)

Aus den Ideen des Extreme Programming entstand 2001 das Agile Manifest, welches die Ideen
der agilen Softwareentwicklung in wenigen Sätzen vereinte:

Wir erschließen bessere Wege, Software zu entwickeln,

indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,

schätzen wir die Werte auf der linken Seite höher ein. (Beck et al., 2001, Abs. 1-3)

Die DevOps-Bewegung setzt hier hauptsächlich bei „Individuen und Interaktionen mehr als
Prozesse und Werkzeuge“ an (Verona, 2016, S. 2). Dies deswegen, da bei DevOps die

7
Zusammenarbeit als sehr wichtig gesehen wird und diese nicht nur in starren Prozessabläufen,
sondern auch auf informaler Basis nach Notwendigkeit stattfinden soll.

2.3.3 Versionsverwaltung

Eine Basis für viele moderne Software-Praktiken ist eine Versionsverwaltung (englisch Version
Control System = VCS). Durch eine Versionsverwaltung können Änderungen an der Codebasis
einer Anwendung einfach nachvollzogen werden. Jede Änderung an der Codebasis wird durch
einen Commit dargestellt, welcher zusätzlich eine Nachricht zur Beschreibung der Änderung und
eine/n Autor/in enthält. Wenn Änderungen Probleme verursachen, können die zugehörigen
Commits auch einfach rückgängig gemacht werden. Eine zusammenhängende Codebasis wird
als Repository bezeichnet, und innerhalb dieser können verschiedene Entwicklungszweige
(Branches) bestehen, in denen unabhängig weiterentwickelt werden kann. Dabei werden die
Hauptentwicklungszweige, in denen alle fertigen Änderungen am Produkt enthalten sein sollen,
je nach VCS mainline, trunk, oder master genannt. Zur konsistenten Bezeichnung werden
Referenzen auf den Hauptentwicklungszweig im Folgenden immer als mainline bezeichnet.

Zur Versionsverwaltung gibt es zurzeit mehrere Implementierungen. Bekannte VCS sind unter
anderem SVN, Git und Mercurial.

Laut Davis & Daniels (2016) besteht der Zusammenhang mit DevOps darin, dass einerseits
Teams durch Versionsverwaltung einfach zusammenarbeiten können, da gleichzeitig am selben
Code gearbeitet und die Änderungen zusammengefügt werden können. Andererseits macht es
die Struktur bei Versionsverwaltung sehr einfach, Änderungen rückgängig zu machen, was dem
Mut zum Risiko als Teil einer DevOps-Kultur zugutekommt.

2.3.4 Testgetriebene Entwicklung

Testgetriebene Entwicklung (Test-Driven Development, kurz TDD) ist eine Programmiertechnik,

welche erstmals 1999 von Kent Beck im Rahmen der agilen Entwicklungsmethode Extreme
Programming beschrieben wurde (Fowler, 2005). Die Entwicklung von Code sollte laut dieser
Technik in drei Schritten ablaufen:

1. Es werden Tests für die zu entwickelnde Implementierung geschrieben, die anfangs

fehlschlagen.

2. Die Implementierung des Quellcodes wird durchgeführt, bis alle Tests erfolgreich
durchlaufen werden.

3. Die Struktur des entstandenen Codes wird umgearbeitet, um sie verständlicher zu

gestalten. Dabei müssen am Ende alle Tests wieder erfolgreich durchlaufen werden.

8
Vorteile dieser Technik sind unter anderem, dass der dadurch entstandene Code leichter testbar
wird, anstatt erst nach der Implementierung den Code auf Testbarkeit umzubauen. Um
Komponenten einfacher zu testen, müssen deren Zuständigkeiten klar sein und die
Abhängigkeiten der Komponenten von außen hineingegeben werden können. Daher fördert
testgetriebene Entwicklung auch gutes Software-Design im Sinne von eindeutigen
Zuständigkeiten und dem Einsatz von Inversion of Control.

In Bezug auf DevOps hat testgetriebene Entwicklung den Vorteil, dass dadurch die
Testabdeckung des Codes und Testautomatisierung auf ein hohes Level gebracht werden
können. Dies erhöht das Vertrauen in und die Qualität von Software Releases, was die Arbeit der
IT-Operations-MitarbeiterInnen erleichtert und somit die Zusammenarbeit zwischen IT-
Operations und Entwicklung verbessert.

2.4 Kulturelle Veränderungen bei der Einführung

Wie bereits aus den Definitionen von DevOps erkenntlich, ist zur Umsetzung von DevOps eine
Änderung der Firmenkultur notwendig. Im Speziellen muss die effektive Zusammenarbeit
zwischen Abteilungen/Teams durch verschiedene Änderungen in der Kultur verbessert werden.
Auch sollte sich die Kultur von Teams über Werte definieren sowie kontinuierliche Verbesserung
im Unternehmen als zentrales Prinzip festgelegt werden.

2.4.1 Verbesserung der Zusammenarbeit

Eines der Hauptziele, welches durch den Einsatz von DevOps-Praktiken erreicht werden soll, ist
eine engere Zusammenarbeit zwischen EntwicklerInnen und IT-Operations-MitarbeiterInnen.
Eine dahingehende Verbesserung kann durch verschiedene Ansätze erreicht werden.

Es kann die Kommunikation zwischen Entwicklung und IT-Operations in Unternehmen offener

gestaltet werden, wie es Walls (2013) beschreibt. Die Kommunikation sollte nicht nur über
formelle Anfragen und Ticketsysteme, sondern auf pragmatische Art und Weise zwischen den
verschiedenen Abteilungen erfolgen.

Einen wichtigen Aspekt stellt hier auch die Schaffung von gemeinsamen Zielen für Entwicklung
und IT-Operations dar. Meist sind die Ziele dieser Abteilungen gegensätzlich: EntwicklerInnen
wollen möglichst viele Änderungen und Fehlerbehebungen durchführen, während IT-Operations-
MitarbeiterInnen ein möglichst stabiles System für KundInnen bereitstellen wollen (Kim et al.,
2016). Durch diese entgegengesetzten Zielsetzungen können Konflikte zwischen den
Abteilungen entstehen. Durch Fokussierung aller Abteilungen beziehungsweise Teams auf
gemeinsame Ziele wie ein möglichst benutzerfreundliches System können alle MitarbeiterInnen

9
zum Erfolg des Unternehmens beitragen. Diese gemeinsame Definition stellt auch eine gute
Basis für die offene Kommunikation zwischen Abteilungen dar, da über das Produkt und seine
Anforderungen und nicht über jeweils eigene Ziele miteinander kommuniziert werden kann.

Auch ist es essentiell, Vertrauen zwischen den verschiedenen Abteilungen eines Unternehmens
zu etablieren. Beispielsweise müssen EntwicklerInnen den IT-Operations-MitarbeiterInnen
vertrauen, dass diese das Software-System korrekt installieren und konfigurieren. Andererseits
müssen IT-Operations-MitarbeiterInnen den EntwicklerInnen vertrauen, dass diese ihre
Software-Änderungen gewissenhaft durchgeführt und getestet haben. Beispiele von Davis und
Daniels (2016) zeigen, welche Auswirkungen das Fehlen von Vertrauen haben kann. Wenn ein
Team von ServeradministratorInnen kein Vertrauen in andere Abteilungen hat und den Zugriff auf
die administrierten Server nur dem eigenen Team erlaubt, kann es zu einer Reduktion des
Arbeitsflusses kommen, weil das AdministratorInnen-Team einen Engpass zum Ändern der
Server-Infrastruktur darstellt. Es stellt auch ein Problem dar, wenn einzelne Personen im Team
bestimmte Infrastruktur allein warten, da bei Ausfällen dieser Infrastruktur das ganze Team nicht
mehr arbeiten kann, wenn die Person zu dieser Zeit nicht erreichbar ist.

2.4.2 Kontinuierliche Verbesserung

Kontinuierliche Verbesserung ist eine Praxis, die aufgrund des grundlegenden Konzepts des
Lean Development im Rahmen der DevOps-Bewegung einen wichtigen Aspekt darstellt. Kim et
al. (2016) versuchen hier, kontinuierliches Lernen durch einige wenige Praktiken in Unternehmen
zu etablieren. Beispielsweise sollen menschliche Fehler nicht bestraft, sondern als
Prozessproblem betrachtet oder Post-Mortems, also Analysen nach dem Auftreten von
Problemen wie schwerwiegenden Systemausfällen, abgehalten werden.

Das Kopieren von Praktiken allein ist jedoch nicht zielführend. Das Konzept des Lean
Development ist ursprünglich aus dem Toyota Produktionssystem entstanden. Hier haben viele
Firmen versucht, die durch jahrelange Erfahrung und Verbesserung gewonnen Praktiken wie
auch die Praxis der kontinuierlichen Verbesserung von Toyota zu kopieren und im Unternehmen
umzusetzen. Es wurden oft jedoch nur Teile umgesetzt, wodurch die Erfolge nicht kopiert werden
konnten (Poppendieck & Poppendieck, 2007). Um die Erfolge wirklich replizieren zu können,
müssen nicht nur einmalige Änderungen und Verbesserungen durchgeführt, sondern eine Kultur
der kontinuierlichen Verbesserung etabliert werden (Schwarz, 2014). Diese Verbesserungskultur
muss auch in IT-Unternehmen integriert werden, um langfristig den gewünschten Effekt erzielen
zu können.

Die Etablierung einer Kultur der kontinuierlichen Verbesserung ist nicht einfach durchzuführen,
wie Schwarz (2014) erklärt. Es werden in vielen Unternehmen nur punktuelle Anstrengungen zur

10
Verbesserung unternommen, die jedoch wieder verloren gehen, wenn keine Kultur zur
Verbesserung besteht. Die Durchführung von pauschal ausgerichteten Maßnahmen und
Programmen zur Änderung der Kultur ist nicht zielführend. Stattdessen muss ein klarer
Zielzustand der Kultur vorhanden sein und die Ideen der Zielkultur sollen Personen individuell
nähergebracht werden, um nach und nach zum Zielzustand zu gelangen. Am effektivsten können
diese Änderungen umgesetzt werden, wenn vom Top-Management herab nach und nach die
MitarbeiterInnen von einer Idee überzeugt werden und diese dann an untere Ebenen
weitergeben.

Auch kann eine Kultur der kontinuierlichen Verbesserung nicht entstehen, wenn wie in vielen
Unternehmen nur Standards definiert werden, um Abweichungen zu erkennen und zu beheben.
Es sollten immer wieder neue Zielzustände definiert werden, damit sich die unterschiedlichen
Unternehmensteile ständig verbessern können. Es muss hier darauf geachtet werden, dass die
Ziele an einem Hauptziel beziehungsweise einer Vision ausgerichtet sind. Ansonsten würde sich
das Unternehmen in verschiedene Richtungen entwickeln, womit kein langfristiger Erfolg möglich
ist. (Schwarz, 2014)

2.4.3 Teamkultur entwickeln

Um eine gute Firmenkultur zu erreichen, ist als Basis eine funktionierende Teamkultur notwendig.
Um mit häufigen Änderungen in Teams besser umgehen zu können und Konflikte zu minimieren,
sollten Teams gemeinsame Werte zu definieren. Ein Beispiel für gemeinsame Werte wäre der
Umgang mit knappen Projekt-Deadlines: Sollen alle benötigten Features, wenn auch in
halbfertiger oder ungetesteter Form, umgesetzt werden oder trotzdem auf die Qualität geachtet
werden, auch wenn dann nicht alle Features fertiggestellt werden können. Teamwerte
beschreiben also den einheitlichen Umgang von Teams mit Situationen beziehungsweise ihrer
Umwelt. (Davis & Daniels, 2016)

Es sollte darauf geachtet werden, dass sich die Werte von Teams auf die professionelle Arbeit
und nicht auf externe Faktoren beziehen. (Davis & Daniels, 2016) beschreiben hier ein
Negativbeispiel von Teamkultur, bei dem voraussichtliche neue Kandidaten zum Mittagessen
eingeladen wurden. Da die Teammitglieder gerne Bier miteinander tranken, wurden teilweise
Kandidaten abgelehnt, die beim Mittagessen kein Bier bestellten.

2.5 Ziele
Die Implementierung der Konzepte, Praktiken und kulturellen Veränderungen, die mit DevOps
einhergehen, soll nicht zum Selbstzweck durchgeführt werden. DevOps kann und soll mehrere
geschäftliche Vorteile bringen, welche Kim et al. (2016) in Form von Studienergebnissen
11
darstellen. Im Vergleich zu Unternehmen ohne Einsatz von DevOps-Praktiken können solche, die
eine DevOps-Kultur implementiert haben, geschriebenen Code häufiger und schneller in
Produktion bringen. Das zeigt sich durch 30-mal häufigere Deployments und 200-fach kürzere
lead time, also Zeit zwischen dem Einchecken von Änderungen und dem Zeitpunkt der
Auslieferung dieser. Hoch performante IT-Organisationen können hier eine lead time von
wenigen Minuten bis Stunden erreichen.

Trotz dieser kurzen Zeitspanne, um Änderungen zu veröffentlichen, ist die Qualität der
produzierten Software auch höher. Das wurde dadurch sichtbar, dass die Wahrscheinlichkeit
eines erfolgreichen Release bei DevOps praktizierenden Unternehmen 60-mal höher war als
beim Durchschnitt.

12
3 CONTINUOUS INTEGRATION (CI)

Die Praxis der Continuous Integration hat sich in den letzten Jahren in der Softwareentwicklung
zu einer essentiellen entwickelt. Kaum ein aktuelles Software-Projekt verwendet nicht Continuous
Integration in irgendeiner Form. Bei vielen Projekten stimmt die Durchführung von Continuous
Integration jedoch nicht mit der ursprünglichen Definition überein, was im nächsten Kapitel
erläutert werden soll.

Continuous Integration ist eine essentielle Komponente für eines der Ziele, die durch DevOps
erreicht werden sollen: Hohe Geschwindigkeit beim Entwickeln neuer Features und gleichzeitig
hohe Qualität der entstandenen Software. Durch Continuous Integration werden Code-
Änderungen so oft wie möglich mit den Änderungen anderer EntwicklerInnen zusammengeführt
und dabei auf Kompilierfähigkeit und gegen eine Reihe automatisierter Tests geprüft. Durch diese
Maßnahmen soll einerseits das Zusammenführen von großen Code-Änderungen, andererseits
das Durchführen wochenlanger manueller Tests am Ende eines Projekts beziehungsweise des
Release-Zyklus verhindert werden. Die Durchführung dieser CI-Praktiken ist wiederum nur dann
effektiv möglich, wenn die Zusammenarbeit innerhalb eines Teams oder, wenn mehrere Teams
am gleichen Software-Produkt arbeiten, zwischen Teams gut ist, was auch einen der zentralen
Aspekte bei der Umsetzung von DevOps darstellt.

Die folgenden Abschnitte sollen einen Überblick über verschiedene Definitionen von Continuous
Integration geben, und wie es mit bekannten ähnlichen Praktiken in Zusammenhang steht. Auch
sollen die Voraussetzungen für die Durchführung von CI aufgelistet sowie die typischen
Bestandteile einer CI Pipeline beschrieben werden. Zuletzt werden verschiedene Vorteile von
Continuous Integration in Bezug auf Software-Qualität aufgezeigt.

3.1 Definition
Im Vergleich zu den Definitionen von DevOps sind jene von Continuous Integration einheitlicher
in ihrer Aussage. Das liegt daran, dass DevOps eher eine Sammlung von Konzepten, Praktiken
und Werkzeugen mit gemeinsamen Zielen darstellt, während Continuous Integration eine
konkrete Praxis in der Softwareentwicklung repräsentiert.

Fowler (2006a) beschreibt Continuous Integration folgendermaßen:

Continuous Integration is a software development practice where members of a team

integrate their work frequently, usually each person integrates at least daily - leading
to multiple integrations per day. Each integration is verified by an automated build
(including test) to detect integration errors as quickly as possible. (Abs. 1)

13
Wichtige Punkte sind hier die häufige (zumindest tägliche) Integration von Code-Änderungen pro
Entwickler/in und dass jede Integration durch einen automatisierten Build-Prozess läuft, der auch
automatisierte Tests enthält. Diese zentralen Eckpunkte von Continuous Integration finden sich
in vielen Quellen wieder (Duvall, Matyas & Glover, 2007; Humble & Farley, 2011).

Folgende weitere Gemeinsamkeiten weisen die Quellen in der Definition auf:

• Die tägliche Integration der Änderungen muss auf den Hauptentwicklungszweig des VCS
erfolgen, da sonst die Änderungen nur mit wenigen und nicht mit allen EntwicklerInnen
integriert werden (Duvall et al., 2007; Fowler, 2006a; Humble & Farley, 2011).

• Ein separater PC für den automatisierten Build-Prozess ist notwendig, um dem Problem
vorzubeugen, dass bestimmte Code-Änderungen nur auf einer bestimmten
Entwicklungsumgebung funktionieren (Duvall et al., 2007; Fowler, 2006a).

• Der Build-Prozess sollte möglichst schnell ablaufen, um direkt Feedback erhalten zu können.
Als Maximalwert für die Dauer wird hier meist zehn Minuten genannt (Duvall et al., 2007;
Fowler, 2006a; Humble & Farley, 2011).

• Continuous Integration funktioniert nicht automatisch durch Tools wie CI Server, sondern ist
eine Praxis, die von allen EntwicklerInnen gelebt werden soll. Daher funktioniert Continuous
Integration auch nur, wenn alle beziehungsweise die meisten EntwicklerInnen dieser Praxis
zustimmen (Duvall et al., 2007; Humble & Farley, 2011).

Auch weisen mehrere Quellen auf den Ursprung von Continuous Integration als eine Praxis des
agilen Vorgehensmodells Extreme Programming hin, welches von Kent Beck 1999 entworfen
wurde (Fowler, 2006a; Humble & Farley, 2011).

In der Praxis zeigt sich, dass die Definition von Continuous Integration für viele Unternehmen
nicht klar ist. Luke und Prince (o.D.) führten eine Studie durch, in der Teilnehmende Personen
Definitionen für Praktiken wie Continuous Integration geben und gleichzeitig beantworten
mussten, ob und wie sie diese Praktiken in ihrem Unternehmen verwenden. Es zeigte sich, dass
die meisten TeilnehmerInnen Continuous Integration nicht vollständig definieren konnten, aber
dieselben TeilnehmerInnen auch angaben, diese Praxis zu verwenden. 90% der Teilnehmenden,
die nicht täglich ihre Änderungen in die mainline integrieren, sondern länger existierende
Branches verwenden (zum Beispiel Feature Branches, bei dem pro Feature ein neuer Branch im
VCS erzeugt wird), gaben gleichzeitig an, Continuous Integration zu praktizieren. Luke und Prince
schlossen daraus, dass die Verwendung eines CI Servers von vielen Unternehmen mit dem
Praktizieren von Continuous Integration gleichgestellt wird.

14
3.2 Abgrenzung zu ähnlichen Praktiken
Zusätzlich zu der Tatsache, dass die Praxis von Continuous Integration selbst nicht von allen
Unternehmen korrekt definiert werden kann, sind auch in den Jahren nach der Popularisierung
von Continuous Integration ähnliche Praktiken entstanden. Diese tragen zusätzlich zur
Verwirrung um den Begriff bei (Luke & Prince, o.D.).

Einerseits sind hier die Methoden Continuous Delivery beziehungsweise Continuous Deployment
zu erwähnen. Diese erweitern die Idee von Continuous Integration um eine Komponente zum
kontinuierlichen Deployment in Produktionsumgebungen beziehungsweise der Möglichkeit eines
solchen. Andererseits existiert der relativ neue Begriff Trunk Based Development, der sich auf
die Basisidee von Continuous Integration fokussiert.

3.2.1 Continuous Delivery/Deployment

Continuous Delivery erweitert die klassische Definition von Continuous Integration, wonach alle
Änderungen einen automatischen Build- und Test-Prozess durchlaufen. Bei der Praktizierung von
Continuous Integration werden Änderungen zwar automatisch kompiliert und es werden
automatisierte Tests ausgeführt, jedoch folgt diesem automatisierten Prozess meist ein längerer
manueller Testprozess bzw. wird das Deployment in Produktionsumgebungen vom IT-Operations
Team meist manuell durchgeführt. (Humble & Farley, 2011)

Continuous Delivery soll durch weitere Automatisierung des Softwareentwicklungsprozess

folgende Ergebnisse zur Folge haben (Humble & Farley, 2011):

• Durch weitere Arten von automatisierten Tests, die beispielweise auch das gesamte
System oder die nichtfunktionalen Anforderungen wie Kapazität und Antwortzeit testen,
werden manuelle Tests auf ein Minimum reduziert. Zusätzlich sollen Tester Code-
Änderungen auf ihre Testumgebung nach einem Pull Prinzip selbst deployen können.

• IT-BetriebsmitarbeiterInnen müssen keine komplizierten, fehleranfälligen manuellen

Schritte zur Durchführung eines Software Deployments tätigen, sondern können per
Knopfdruck Anwendungen in eine Produktionsumgebung deployen.

Diese Änderungen sollen insgesamt dazu führen, dass fast alle Schritte im
Softwareentwicklungsprozess automatisiert ablaufen. Dadurch, dass damit auch Deployments im
Vergleich zur seltenen manuellen Durchführung häufiger durchgeführt werden, werden diese
Abläufe häufiger getestet und beinhalten weniger Fehler. Humble und Farley (2011, S. 26)
nennen dieses Prinzip „If It Hurts, Do It More Frequently, and Bring the Pain Forward“.

Im Unterschied zu Continuous Delivery bereitet Continuous Deployment nicht nur jede Code-
Änderung darauf vor, auf verschiedenen Umgebungen einfach deployed werden zu können. Bei

15
Praktizieren von Continuous Deployment wird jede Code-Änderung automatisiert in eine
Produktionsumgebung deployed. Daher ist in diesem Sinne Continuous Release eine präzisere
Beschreibung dieser Praxis. (Humble, 2010)

Continuous Deployment kann nicht für jedes Software-Projekt praktiziert werden. Beispielsweise
ist dies bei eingebetteten Systemen gar nicht möglich. Bei hochkritischen Anwendungen sollte
trotz aller automatisierten Tests auch eine manuelle Begutachtung erfolgen, um das System
möglichst stabil zu halten. Ein Vorteil von Continuous Deployment ist jedoch, dass
EntwicklerInnen durch das automatische Deployment aller Änderung in die
Produktionsumgebung praktisch gezwungen sind, sehr gute automatisierte Tests auf allen
Ebenen zu schreiben (Unit Tests, Komponententests, Systemtests, …). Gleichzeitig wird bei
einem solchen Mechanismus bei Vorhandensein einer einfachen Rollback-Möglichkeit das Risiko
eines Release auf eine einzige Änderung reduziert. (Humble & Farley, 2011)

Continuous Delivery und Continuous Deployment bauen beide direkt auf der Praxis von
Continuous Integration auf. Beide haben zum Ziel, nicht nur einen automatisierten Build und Test
jeder Code-Änderung durchzuführen, sondern auch das Deployment der neuen Software-Version
zu automatisieren. Continuous Deployment geht hier noch einen Schritt weiter und führt auch das
Software Release bei jeder einzelnen Code-Änderung durch.

3.2.2 Trunk Based Development

Trunk Based Development versucht, die ursprünglichen Ideen von Continuous Integration
verständlicher und klarer sichtbar zu machen (Hammant, o.D.):

• Die EntwicklerInnen sollen alle Änderungen häufig in die mainline des VCS committen.

• Die Funktionalität aller Änderungen muss durch Tests bestätigt werden.

• Die EntwicklerInnen besitzen Vertrauen in die Funktionsfähigkeit aller Code-Änderungen,

da Commits, bei denen der Build fehlschlägt, automatisch zurückgerollt werden.

Fowler (2017) beschreibt die Problematik, dass viele den Begriff Continuous Integration falsch
verstehen, durch das Stellen von drei Fragen (diese Idee stammt ursprünglich von Jez Humble)
bei Vorträgen:

• Pushen alle EntwicklerInnen mindestens täglich auf die mainline?

• Löst jeder Commit einen automatischen Build- und Testprozess aus?

• Wenn der Build fehlschlägt, ist dieser üblicherweise innerhalb von zehn Minuten wieder
funktionsfähig?

16
Meist bleiben nach Stellen dieser Fragen wenige TeilnehmerInnen in einer Gruppe übrig, die
glaubt, Continuous Integration zu praktizieren. Fowler (2006b) nennt dieses Problem Semantic
Diffusion: Ein Begriff mit einer ursprünglich genauen Bedeutung wird weiterverbreitet und populär.
Da viele den Begriff verwenden, ohne auf die originalen AutorInnen zu referenzieren, wird die
Bedeutung des Begriffs schwammig und der Begriff schwieriger verwendbar.

Die Problematik, dass Continuous Integration nicht richtig verstanden wird, hat zur Entstehung
des Begriffs Trunk Based Development geführt. Dadurch sollte der Grundgedanke von
Continuous Integration mit einem neuen Begriff klargestellt werden. Es könnte hier jedoch
ebenfalls bei Popularisierung des Begriffs die gleiche Semantic Diffusion auftreten, was die
Problematik wiederholen würde. (Fowler, 2017)

3.3 Voraussetzungen für das Betreiben von CI

Um Continuous Integration im Unternehmen einsetzen zu können, sind bestimmte Praktiken
notwendig, die korrekt angewendet werden müssen. Unter anderem muss ein
Versionskontrollsystem verwendet werden, der Software-Build automatisiert und relativ schnell
ablaufen und eine Möglichkeit zur Integration vorhanden sein, entweder mithilfe eines separaten
PCs oder durch einen CI Server.

3.3.1 Versionsverwaltung

Um die Zusammenarbeit zwischen EntwicklerInnen an einer gemeinsamen Codebasis sinnvoll

zu ermöglichen, ist ein VCS notwendig. Für das Betreiben von Continuous Integration ist hier
wichtig, dass alle für den Build-Prozess benötigten Artefakte im VCS eingecheckt sind (Fowler,
2006a). Wenn für den Build benötigte Dateien nicht eingecheckt werden, kann die Integration von
Änderungen an diesen Dateien nicht funktionieren. Ausnahmen sind hier bestimmte Dateien von
Systemumgebungen, die sich nie oder sehr selten verändern, beispielsweise die Java-Umgebung
oder die Betriebssystemumgebung.

Ein ebenfalls kritischer Punkt ist die Häufigkeit des Eincheckens von Änderungen auf den
Hauptentwicklungszweig, was im Schnitt pro Entwickler/in einmal täglich passieren sollte. Nur
durch diese Praxis kann sichergestellt werden, dass Änderungen ständig mit Änderungen
anderer EntwicklerInnen integriert werden. (Fowler, 2017)

Ein häufiges Problem vieler Umsetzungen von Continuous Integration ist die Verwendung
langlebiger Feature Branches. Diese werden oft solange nicht in die mainline integriert, bis ein
Kundenfeature umgesetzt wurde. Das hat zur Folge, dass Änderungen erst nach Tagen oder
Wochen integriert werden, was die Vorteile von Continuous Integration stark reduziert.

17
Kundenfeatures sollen jedoch solange nicht für KundInnen sichtbar sein, bis diese vollständig
umgesetzt sind. Da bei halb umgesetzten Features die Benutzererfahrung leiden würde, wurden
Feature Branches oft als Lösung verwendet. (Fowler, 2009)

Diese Problematik kann einerseits dadurch umgangen werden, dass die Änderungen im
Hintergrund, also beispielsweise am Businesslogik und Datenmodell, für den User sowieso nicht
sichtbar sind und die UI-Änderungen oft in einem Commit durchgeführt werden können.
Andererseits können bei komplexen neuen Features Feature Toggles eingesetzt werden, die
diese in der produktiven Anwendung solange deaktivieren, bis sie vollständig umgesetzt sind.
(Fowler, 2009)

3.3.2 Automatisierter Build-Prozess

Einer der grundlegenden Vorteile von Continuous Integration ist die Sicherstellung der ständigen
Kompilierfähigkeit von Anwendungen, wobei der Prozess des Kompilierens meist als Build
bezeichnet wird. Im Rahmen eines Build werden oft zusätzliche Schritte wie das Ausführen
automatisierter Tests durchgeführt, doch in seiner Grundform wird Quellcode kompiliert. Für die
konsistente und von Benutzerinteraktion entkoppelte Durchführung eines Build wird ein Build-
Tool benötigt. (Duvall et al., 2007)

3.3.2.1. Build-Tools
Hier sind mittlerweile viele Build-Tools für die bekanntesten Programmiersprachen erhältlich.
Beispiele sind NAnt oder MSBuild für .NET und Ant, Maven oder Gradle für Java. Im Fall von
Java war jahrelang Ant das vorherrschende Build-Tool. Ant-Builds werden durch eine Reihe von
Tasks in XML-Dokumenten spezifiziert, welche durchzuführende Aufgaben im Rahmen des Build
darstellen. Tasks für simple Aufgaben wie das Kopieren von Dateien oder Kompilieren von
Quellcode sind bereits vorhanden. Jedoch ist das Durchführen von Builds mit Ant mit mehreren
Problemen verbunden. Beispielsweise müssen Build-Skripts in XML geschrieben werden, was
die Lesbarkeit von großen Dateien oft schwierig gestaltet. Auch muss oft boilerplate code, also
immer wiederkehrende gleiche Codebausteine, geschrieben werden, um einfache Aufgaben wie
das Erstellen von JARs (Java Archiven, ausführbare Java-Dateien) oder das Durchführen von
automatisierten Tests zu bewältigen. (Humble & Farley, 2011)

Als Lösung für viele Probleme von Ant wurde Maven entwickelt. Dieses Build-Tool versucht
einerseits, boilerplate code durch die Vorgabe von bestimmten Konventionen zu vermeiden.
Damit wird bewirkt, dass bei Projekten mit Einhaltung der Standardvorgaben nur wenig
Konfiguration benötigt wird. Andererseits war Maven auch das erste Java Build-Tool, das die
automatische Verwaltung von Abhängigkeiten unterstützt. Diese können mit Maven angegeben

18
und, bei Bedarf, automatisch von zentralen Repositories heruntergeladen werden. (Humble &
Farley, 2011)

Abbildung 1: POM Datei eines Maven Projekts (eigene Abbildung)

Abbildung 1 zeigt einen Ausschnitt aus der Konfiguration eines einfachen Maven Projekts, welche
POM (Project Object Model) genannt wird. Projekte in Maven werden zwar auch in XML
beschrieben, jedoch sind die zugehörigen Dateien durch das Prinzip von Konvention über
Konfiguration meist kürzer als Build-Skripts in Ant. Abhängige Projekte können einfach im
Abschnitt dependencies angegeben werden und werden, wenn sie lokal nicht vorhanden sind,
heruntergeladen. Einfache Projekte benötigen keine zusätzliche Konfiguration für viele
Standardaufgaben beim Build von Java-Anwendungen. Unterstützt werden unter anderem das
Durchführen von automatisierten Tests, die Erstellung von JARs oder das Hochladen der
erstellten JARs in ein zentrales Repository.

3.3.2.2. Wichtige Umsetzungsaspekte

Das Ausführen von automatisierten Builds soll mit nur einem Befehl möglich sein, beispielsweise
mvn clean install bei Einsatz von Maven. Dadurch wird laut Duvall et al. (2007) sichergestellt,
dass alle für den Build notwendigen Dateien direkt verfügbar sind und erleichtert das Durchführen
eines automatisierten Build über einen CI Server. Außerdem wird dadurch ein immer gleicher
Ablauf des Build erreicht, was dessen Stabilität erhöht.

Es ist außerdem wichtig, dass der Build- und Test-Prozess so kurz wie möglich gehalten wird.
Humble und Farley (2011) nennen mehrere Folgen eines zu langen Build. Beispielsweise werden
nicht mehr alle Tests von EntwicklerInnen vor Einchecken von Änderungen ausgeführt, was zu

19
häufigeren fehlgeschlagenen Builds am Integrations-PC führt. Auch werden Änderungen seltener
eingecheckt, da bei jedem Einchecken lange auf das Durchführen des Build-Prozesses gewartet
werden muss.

3.3.3 Automatisierte Tests

Das Ausführen von automatisierten Tests ist ein wichtiger Bestandteil bei der Anwendung von
Continuous Integration. Wenn Änderungen zwischen EntwicklerInnen häufig integriert werden,
kann es ohne automatisierte Tests auftreten, dass Änderungen zwar kompilierfähig sind und für
sich selbst funktionieren, jedoch andere Teile des Systems beinträchtigen. Andererseits ist ein
kompletter manueller Test der Anwendung durch EntwicklerInnen bei mehrmals täglichen
Commits nicht möglich. Hier helfen automatisierte Tests, die bei Durchführen jedes Integrations-
Build die funktionale Korrektheit der Anwendung sicherstellen.

In diesem Zusammenhang ist von self-testing code die Rede, also Quellcode, der sich selbst
testet. Praktiken wie TDD helfen hierbei, solchen self-testing code zu produzieren, da die Tests
bereits vor der Implementierung geschrieben werden. Um die Anwendung von TDD zu
erleichtern, entstanden auch mehrere Frameworks für das Erstellen von Unit Tests, also Tests
von einzelnen Code-Komponenten, wie beispielsweise JUnit für Java oder NUnit für .NET.
(Fowler, 2006a)

JUnit war die erste verbreitete Implementierung des von Kent Beck entworfenen xUnit-Konzepts
(Fowler, 2006c). Mit JUnit können automatisierte Tests einfach im Code geschrieben und
entweder über die Entwicklungsumgebung (IDE) oder verbreitete Java Build-Tools wie Maven
oder Gradle gestartet werden. Abbildung 2 zeigt das Ergebnis einer Durchführung von JUnit Tests
durch Maven. Es wird die Anzahl erfolgreicher und fehlgeschlagener Tests angezeigt. Im Falle
fehlgeschlagener Tests werden diese auch explizit angegeben. Standardmäßig schlägt auch der
Maven-Build fehl, wenn einzelne Tests fehlschlagen.

20
Abbildung 2: Ausführung von JUnit Tests in Maven (eigene Abbildung)

Für die Sicherstellung der Funktionalität einer gesamten Anwendung reichen oft Unit Tests nicht
aus. Einerseits testen diese nur zum Beispiel einzelne Klassen und nicht die Interaktion zwischen
diesen, andererseits können Teile der Anwendung wie die grafische Benutzeroberfläche (GUI)
mit Unit Tests schwer getestet werden. Aus diesem Grund wurden Frameworks für End-To-End-
Tests(E2E-Tests) entwickelt, mithilfe welcher Tests auf die gesamte Anwendung durchgeführt
werden können.

Auch können durch solche E2E-Tests Akzeptanztests automatisiert werden. Akzeptanztests

testen die gewünschte Funktionalität einer Anwendung aus Sicht der BenutzerInnen und
zusätzlich nicht-funktionale Anforderungen wie Kapazität, Stabilität oder Leistungsfähigkeit.
Durch die zusätzliche Ausführung solcher Tests kann das Vertrauen in die korrekte Funktionalität
der gesamten Anwendung ohne Durchführung manueller Tests weiter erhöht werden. (Humble,
2010)

3.3.4 Methode der kontinuierlichen Integration

Zentrale Idee von Continuous Integration ist, dass bei jedem Commit ins VCS ein automatischer
Build-Prozess durchlaufen wird, um die Integrationsfähigkeit der Änderungen zu prüfen. Dieser
Build-Prozess kann entweder manuell durch EntwicklerInnen oder automatisiert durch einen CI
Server angestoßen werden. Wichtig ist, dass in jedem Fall ein separater PC für die Integration
verwendet wird, um den erfolgreichen Build nicht nur auf einer Entwicklungsumgebung zu
garantieren (Duvall et al., 2007).

Dass Continuous Integration auch ohne einen CI Server betreibbar ist, zeigt Shore (2006) anhand
einer einfachen Vorgangsweise. Ein ausrangierter Computer kann als Integrations-PC dienen,
auf dem der Quellcode ausgecheckt werden kann. Zusätzlich wird eine Art physischer Token
benötigt, damit im Team klar ist, wer gerade Änderungen integriert. Wenn ein/e Entwickler/in
21
Änderungen lokal getestet hat, holt er/sie sich den Token, checkt die Änderungen auf dem
Integrations-PC aus und führt dort einen automatischen Software-Build durch. Wenn die
Integration erfolgreich war, kann der Token zurückgegeben werden. Ansonsten kann versucht
werden, den Fehler innerhalb kurzer Zeit zu beheben und ansonsten können die Änderungen
wieder rückgängig gemacht werden.

CI Server erleichtern diesen Prozess, indem bei jedem Commit auf den Hauptentwicklungszweig
automatisch ein Build der Anwendung gestartet wird. Auch können CI Server einen grafischen
Überblick über das Ergebnis eines Build liefern und dieses beispielsweise per E-Mail an den/die
Autor/in der jeweiligen Änderungen senden.

3.4 Zusätzliche Bestandteile einer CI Pipeline

Als CI Pipeline werden bei vielen CI Servern alle Aktivitäten bezeichnet, die im Rahmen eines
Integrations-Build durchgeführt werden. Diese beinhaltet bei fortgeschrittener Anwendung nicht
nur das Kompilieren des Quellcodes und Ausführen automatisierter Tests, sondern auch weitere
Schritte. Unter anderem können Datenbankänderungen integriert, der Quellcode auf
verschiedene Metriken geprüft oder automatisiert Software-Deployments in beispielweise
Testumgebungen durchgeführt werden. Abbildung 3 zeigt hier die Visualisierung einer diese
Schritte umfassenden CI Pipeline.

Kompilation Datenbankintegration Tests

Code-Inspektionen Software-Deployment

Abbildung 3: Darstellung einer CI Pipeline (in Anlehnung an Duvall, Matyas & Glover, 2007)

3.4.1 Automatische Datenbankintegration

In vielen Software-Unternehmen arbeiten SoftwareentwicklerInnen und

DatenbankadministratorInnen (DBA) getrennt. Wenn EntwicklerInnen Änderungen an der
Datenbankstruktur vornehmen müssen, benötigen sie dazu eine/n DBA, was einen Flaschenhals
bei der Softwareentwicklung darstellt. Auch werden Datenbankskripts oft nicht zentral verwaltet
und nur geteilte Datenbankumgebungen zur Verfügung gestellt, wodurch Änderungen schwer
durchgeführt werden können, da damit unter Umständen die geteilte Datenbankumgebung für

22
andere EntwicklerInnen kurzfristig unbenutzbar wird. Durch automatische Datenbankintegration
sollen diese Probleme minimiert werden. (Duvall et al., 2007)

Ein erster Schritt ist die Verwaltung der Datenbankskripts in einem VCS Repository, um diese
innerhalb des Build-Prozesses einfach zur Verfügung zu stellen und das Teilen und Verwalten
der Änderungen einfacher zu gestalten. Dadurch können diese Skripts auch in einem
Integrations-Build automatisiert durchgeführt und getestet werden, um bei jeder Änderung die
Funktionalität der Datenbank sicherzustellen. Durch diese Automatisierung ist wiederum die
Erstellung einer Datenbank auf einem Entwicklungsrechner einfach möglich, mit welcher
Datenbankänderungen lokal getestet werden können und wodurch geteilte Datenbanken oft
überflüssig sind. Auch können dadurch EntwicklerInnen direkt Änderungen an der
Datenbankstruktur vornehmen. (Duvall et al., 2007)

Diese Automatisierung entlastet auch den/die DBA, wodurch mehr Zeit für höhere Tätigkeiten in
der Datenbankadministration wie Normalisierung oder Performanceoptimierungen zur Verfügung
steht (Duvall et al., 2007). Automatisierte Datenbankintegration kann daher die Entwicklung von
Software-Systemen mit Datenbankanbindung agiler gestalten und auch die Qualität der
Datenbank durch automatisierte Tests dieser und höheren Fokus auf eine gute Datenstruktur
durch beispielsweise Normalisierung erhöhen.

3.4.2 Automatische Code-Inspektionen

Das Durchführen von manuellen Code-Reviews bei Quellcodeänderungen ist in der

Softwareentwicklung mittlerweile üblich. Die Änderungen werden von einem unbeteiligten Dritten
korrekturgelesen, um deren Richtigkeit und Qualität sicherzustellen. Dabei werden auch Aspekte
wie Einhaltung von Code-Richtlinien des Unternehmens und Standardrichtlinien der
Programmiersprache überprüft, was manuell jedoch fehleranfällig sein kann. Aus diesem und
weiteren Gründen können automatische Code-Inspektionen hohe Software-Qualität und
effizientere Entwicklung fördern. (Duvall et al., 2007)

Eine wichtige Metrik, die durch Code-Inspektionen geliefert werden kann, ist die Anzahl der
Quellcodezeilen pro Methode. Methoden, die eine hohe Anzahl an Zeilen besitzen, sind oft
verschachtelter und daher fehleranfälliger. Auch Metriken wie die Menge von dupliziertem Code
und die Testabdeckung können automatisiert errechnet werden. Weiters können mittels
automatischer Code-Inspektionen Richtlinien wie die sinnvolle Benennung von Methoden und
Variablen geprüft werden, wodurch diese Prüfungen in manuellen Reviews überflüssig werden.
(Duvall et al., 2007)

Gängige Inspektionstools können auch einfach zu einem Integrations-Build hinzugefügt werden.

Integrationen mit bekannten Build-Tools wie Ant, Maven, Gradle oder NAnt werden von den

23
meisten Inspektionstools zur Verfügung gestellt, wodurch bei automatischen Builds Inspektionen
durchgeführt werden können. (Duvall et al., 2007)

3.4.3 Automatisches Software-Deployment

Wenn alle anderen Bestandteile einer CI Pipeline implementiert wurden, also automatische
Builds, Tests, Datenbankintegrationen und Code-Inspektionen, ist es theoretisch möglich, zu
jeder Zeit die Funktionsfähigkeit der Software zu garantieren und diese daher auch jederzeit in
eine Produktionsumgebung zu deployen (Duvall et al., 2007). Wie bereits in Kapitel 3.2.1 erwähnt,
nennt sich diese Praxis Continuous Deployment. Continuous Integration liefert hier eine Basis für
Continuous Deployment, da die Software mitsamt der Datenbank bereits automatisiert erzeugt
und getestet wird.

Das Automatisieren von Deployments stellt somit nur mehr einen zusätzlichen Schritt in der CI
Pipeline dar. Da bei Durchführung von automatischen E2E-Tests im Rahmen von Continuous
Integration eine vollständige Applikation installiert sein muss (Duvall et al., 2007), muss
Continuous Integration in diesen Fällen bereits eine Möglichkeit zum automatisierten Deployment
in Testumgebungen bereitstellen. Dabei stellt sich die Frage, auf wie vielen Systemebenen die
Software mit all seinen Abhängigkeiten neu installiert werden muss (Duvall et al., 2007). Bei
Testumgebungen reicht es meist aus, nur die Software neu zu installieren. Wenn die Software
stark von anderen Komponenten oder dem Betriebssystem abhängt, müssen möglicherweise bei
einem Deployment auch diese Komponenten neu installiert werden.

3.5 Vorteile von CI bezüglich Software-Qualität

Software-Qualität kann von zwei Seiten betrachtet werden. Einerseits kann sie als Qualität einer
Software für KundInnen bezeichnet werden. Es wird ausgedrückt, wie gut die Kundenbedürfnisse
mit der Software erfüllt werden und dass das System möglichst wenige Fehler besitzt, kann also
als externe Software-Qualität bezeichnet werden. Andererseits kann unter Qualität einer Software
auch die interne Struktur des Quellcodes verstanden werden. Diese umfasst unter anderem die
Verständlichkeit des Quellcodes und wie gut dieser einer vorgegebenen Architektur folgt, um
beispielsweise Wartung einfacher zu gestalten und Fehlerpotenziale zu minimieren. Diese Art
von Software-Qualität kann als interne Software-Qualität bezeichnet werden. Die Durchführung
von Continuous Integration kann dabei externe und interne Software-Qualität gleichermaßen
erhöhen.

Ein Qualitätsvorteil bei Anwendung von Continuous Integration ist die Tatsache, dass Code-
Änderungen ständig in die mainline integriert werden, was die frühzeitige Erkennung und
Behebung von Problemen ermöglicht (Duvall et al., 2007). Einerseits werden bei einer hohen
24
Testabdeckung die meisten Probleme bereits beim Check-In der Änderungen und dem folgenden
Integrations-Build erkannt. Falls die Probleme nicht durch automatische Tests abgefangen
werden, arbeiten EntwicklerInnen ab dem Check-In mit dieser Änderung und es besteht eine
hohe Wahrscheinlichkeit, dass andere EntwicklerInnen die Probleme früh erkennen und
beheben. Gemeinsam können diese Aspekte von Continuous Integration dazu beitragen, dass
Probleme mit Code-Änderungen bereits während der Entwicklung eines Release behoben
werden, was manuelle Test-Phasen vor einem Release der Software verkürzt und die externe
Software-Qualität erhöht.

Durch die Praxis von Continuous Integration können viele repetitive Aufgaben in der Software-
Entwicklung wie Build und Test automatisiert durchgeführt werden, was Fehler in deren
Durchführung reduziert (Duvall et al., 2007). Ein automatischer Build stellt sicher, dass dieser
immer auf die gleiche Art und Weise durchgeführt wird und somit die Qualität des Software-Build
konsistent auf dem gleichen Niveau ist. Auch muss für die Durchführung von komplexeren
automatisierten Tests wie Akzeptanztests die Anwendung automatisiert deployed werden können
(Fowler, 2006a). Dies schafft eine Basis für das automatisierte Deployment auch in
Produktionsumgebungen, wodurch dieser bei Software oft heikle Schritt eine konsistente Qualität
erreicht und dabei ebenfalls die externe Software-Qualität erhöht wird.

Wenn in einem Software-Projekt bereits eine einfache CI Pipeline eingeführt wurde, ist es einfach,
diese um weitere Schritte zu erweitern. Um die interne Software-Qualität zu erhöhen, können
automatisierte Inspektionen und Prüfungen auf die Architektur durchgeführt werden. Durch
Einführung einer Metrik für die Testabdeckung kann sichergestellt werden, dass sich die
Testabdeckung der gesamten Anwendung bei Code-Änderungen nicht verschlechtert. Da zur
Testbarkeit von Software-Komponenten auch oft eine klare Schnittstelle und ein gutes Design
notwendig sind (Fowler, 2005), erhöht sich dadurch auch die Wartbarkeit und Änderbarkeit der
Software. Dadurch, dass bei Änderungen alle automatisierten Tests durchgeführt werden,
werden Regressionen verhindert, also das Zerstören bestehender Funktionalität durch
Einführung von neuen Features (Humble & Farley, 2011).

25
4 HOHE SOFTWARE-QUALITÄT VON KMU DURCH CI

Dieses Kapitel soll darstellen, welchen Beitrag Continuous Integration bei effektiver Anwendung
zur Erreichung hoher Software-Qualität in österreichischen KMU leistet. Einerseits werden
relevante Eigenschaften österreichischer KMU allgemein und speziell im Software-Bereich
beschrieben. Andererseits wird Software-Qualität in seine unterschiedlichen Aspekte aufgetrennt
und welche Herausforderungen bei der Erreichung dieser bestehen. Abschließend wird geklärt,
welche dieser Herausforderungen speziell in österreichischen KMU durch Continuous Integration
besser bewältigt werden können.

4.1 Eigenschaften österreichischer (Software-)KMU

KMU machen EU-weit und auch in Österreich den Großteil der Unternehmen aus. 99,7% aller
österreichischen Unternehmen sind KMU, wobei diese 67,7% der Beschäftigten anstellen.
Hinsichtlich der Größe der KMU sind 87% Kleinstunternehmen mit weniger als zehn
MitarbeiterInnen und davon 36% Ein-Personen-Unternehmen. 5,6% der KMU sind im Bereich der
Information und Kommunikation tätig, also Software-KMU. (Neubauer & Zoder, 2016)

Der größte Teil der KMU sind daher Kleinstunternehmen mit 2 bis 9 Beschäftigten, die einen
Anteil von 51% an allen KMU ausmachen. Bei einer solchen Unternehmensgröße sind personelle
und meist auch finanzielle Ressourcen beschränkt (Neubauer & Zoder, 2016). Andererseits
fehlen laut EU-Kommission bis zum Jahr 2020 900.000 Fachkräfte im Bereich IKT (Informations-
und Kommunikationstechnologie) und speziell Österreich besitzt hier im EU-Vergleich einen
Mangel an Personen mit IKT-Kenntnissen (Neubauer & Zoder, 2016). Software-KMU haben
folglich auch Schwierigkeiten, im Bedarfsfall zusätzliches Fachpersonal einzustellen.

4.2 Aspekte von Software-Qualität

Software-Qualität als Gesamtes ist schwierig zu definieren, sie kann jedoch grundsätzlich in
folgende Aspekte aufgetrennt werden (Perry, 1992):

• Korrektheit: Die Software erfüllt die funktionalen Anforderungen der KundInnen.

• Zuverlässigkeit: Die Software besitzt konstante und möglichst fehlerfreie Abläufe.

• Effizienz: Die Software nutzt bei ihren Abläufen möglichst wenig Ressourcen.

• Integrität: Die Software ist vor unautorisiertem Zugriff geschützt.

26
 • Benutzerfreundlichkeit: Es ist für BenutzerInnen möglichst einfach, mit der Software zu
interagieren.

• Wartbarkeit und Flexibilität: Es ist einerseits das Finden und Beheben von Fehlern in der
Software und andererseits die Anpassung der Software an geänderte Anforderungen
einfach.

• Testbarkeit: Die Software kann einfach auf ihre korrekte Funktionalität getestet werden.

• Portabilität: Die Software kann einfach auf verschiedenen Hardware-Systemen genutzt

werden beziehungsweise der Aufwand der Portierung ist gering.

• Wiederverwendbarkeit: Die Software kann einfach innerhalb anderer Anwendungen

verwendet werden.

• Interoperabilität: Die Kommunikation zwischen der Software und anderen Anwendungen

ist einfach und standardisiert.

4.3 Herausforderungen hoher Software-Qualität

Bei der Entwicklung von Software, ob im Rahmen eines Projektes oder kontinuierlicher
Produktentwicklung, besteht meist Zeitdruck. Features müssen innerhalb von vorgegebenen
Deadlines fertiggestellt werden, da diese für KundInnen einen hohen Nutzen haben und in der
eigenen Software vor den Konkurrenzprodukten auf den Markt kommen müssen. Dies ist unter
anderem ein Faktor, der niedrige interne Software-Qualität begünstigt und damit technical debt
erhöht. (Kim et al., 2016)

Quellcode mit technical debt ist solcher, bei dem Refaktorierungen nicht durchgeführt werden und
die Struktur und Komplexität des Quellcodes daher immer schwerer zu durchschauen ist. Diese
Faktoren tragen zu reduzierter Wartbarkeit und Flexibilität, aber auch Zuverlässigkeit und
Testbarkeit bei.

Eine übliche Strategie zur Erhöhung der Software-Qualität ist die Durchführung von
umfangreichen manuellen Tests, womit jedoch mehrere Probleme verbunden sind. Es ist oft
schwierig, die Qualität eines Produkts im Nachhinein durch Tests zu erhöhen (Perry, 1992). Wenn
hohe Qualität erst in der meist am Ende eines Entwicklungszyklus gelegenen manuellen Test-
Phase erzeugt werden soll, verzögert dies durch die notwendigen Änderungen und Wiederholung
der Tests das Release der Software weiter und die Kosten für den Release erhöhen sich (Humble
& Farley, 2011), was gegen eine Vernachlässigung der internen Software-Qualität bei knappen
Deadlines spricht.

27
Je komplexer Software wird, desto aufwendiger wird auch das manuelle Testen der Software.
Zusätzlich können ab einer gewissen Komplexität nicht mehr alle möglichen
Konfigurationsmöglichkeiten und Abläufe nur mehr unter sehr hohen Kosten getestet werden.
Jedoch können Änderungen an Teilen des Codes unvorhergesehene andere Abläufe zerstören.
In Kombination hat dies zur Folge, dass manche Abläufe nach Änderungen nicht mehr
funktionsfähig sind, durch die Komplexität der Software nicht manuell getestet wurden und Fehler
mit diesen Abläufen erst bei Auslieferung von Updates an KundInnen sichtbar werden (Humble
& Farley, 2011). Diese Probleme verschlechtern somit die Korrektheit und Zuverlässigkeit von
Software.

Für österreichische KMU sind die genannten Herausforderungen besonders schwierig zu

bewältigen. Da, wie in Kapitel 4.1 dargelegt, hier die personellen Ressourcen beschränkt sind,
kann bei knappen Deadlines nicht einfach zusätzliches Personal zu kritischen Projekten
zugewiesen werden. Der Mangel an IKT-Fachkräften in Österreich verstärkt diese Problematik
noch, da neues Personal schwerer zu beschaffen ist. Dadurch leidet besonders in KMU die
Software-Qualität bei Zeitdruck mit Änderungen. Da manuelle Tests bei wachsender Qualität von
Software sehr hohe Kosten verursachen (Humble & Farley, 2011) und, wie in Kapitel 4.1 erklärt,
auch die finanziellen Ressourcen von KMU oft niedriger sind, ist gerade für KMU das
umfangreiche Durchführen von manuellen Tests eine Herausforderung.

4.4 Welche Herausforderungen durch CI bewältigt werden

Continuous Integration bietet die Möglichkeit, Software-Qualität bereits früh in den
Entwicklungszyklus zu integrieren. Auf jede ins VCS eingecheckte Code-Änderung werden unter
anderem automatisierte Tests zur Korrektheit der Software und Prüfungen auf die Einhaltung der
Software-Architektur und Programmierrichtlinien ausgeführt. Diese Maßnahmen stellen sicher,
dass sich technical debt nicht aufbauen kann. Die Einhaltung von Programmierrichtlinien und
Software-Architektur-Guidelines ist auch einfacher und weniger zeitaufwendig, wenn nicht
manuell darauf geachtet werden muss, sondern Werkzeuge wie CheckStyle oder Sonarqube
ständig auf Einhaltung der Richtlinien prüfen (Duvall et al., 2007). Dadurch kann auch in Phasen
mit hohem Zeitdruck ein gewisser Qualitätsstandard des Codes gewahrt werden
beziehungsweise ist klar, welche Stellen betroffen sind und im Nachhinein verbessert werden
müssen. Continuous Integration kann hier also Wartbarkeit und Flexibilität von Software
sicherstellen.

Software mit einem guten Design und ohne technical debt kann auch besser automatisiert
werden, beispielsweise können automatisierte Akzeptanztests leichter umgesetzt werden
(Humble & Farley, 2011). Daraus lässt sich schließen, dass die korrekte Anwendung von

28
Continuous Integration auch die automatisierte Testbarkeit von Software erhöht. Durch
regelmäßige Ausführung automatisierter Tests und die ständige Integration der Änderungen
werden Fehler schneller gefunden und behoben. Diese frühe Behebung von Fehlern verkürzt
wiederum manuelle Test-Phasen, da im Rahmen dieser weniger Fehler auftreten und behoben
werden müssen.

Automatisierte Tests, die bei korrekter Anwendung von Continuous Integration produziert werden,
in Verbindung mit automatisierten Software-Inspektionen stellen eine hohe Testabdeckung des
Codes sicher. Durch eine hohe Testabdeckung wird wiederum die Komplexität von Software
beherrschbar, da alle möglichen Abläufe in der Software getestet werden. Durch diese
Maßnahmen stellt Continuous Integration eine hohe Korrektheit und Zuverlässigkeit der Software
sicher.

Besonders für Software-KMU stellen manuelle Tests aufgrund mangelnden Personals eine große
Belastung dar, wie in Kapitel 4.3 erklärt wurde. Entweder werden durch den Umfang an
durchzuführenden Tests Release-Zyklen länger und das Unternehmen verliert an
Wettbewerbsfähigkeit, oder die Tests werden nicht umfangreich genug ausgeführt, was Probleme
bei KundInnen nach sich zieht. Gerade bei österreichischen KMU ist die Einstellung neuer
MitarbeiterInnen im IKT-Bereich schwierig (Neubauer & Zoder, 2016). Continuous Integration
kann hier nach anfänglichem Aufwand für die Einführung durch ständige Überprüfungen die
Software-Qualität auf einem hohen Niveau halten.

29
5 MASSNAHMEN ZUR STEIGERUNG DER SOFTWARE-
QUALITÄT DURCH CI

Wie Luke und Prince (o.D.) in ihrer Studie beschreiben, ist die Definition von Continuous
Integration für viele Unternehmen nicht klar. Es wurde darunter von den meisten TeilnehmerInnen
die Verwendung eines CI Servers verstanden. Jedoch wurde die Notwendigkeit zum täglichen
Commit in die mainline von 90% der Befragten nicht gesehen. Auch Fowler (2017) beschreibt,
dass die meisten EntwicklerInnen diese essentiellen Bestandteile von Continuous Integration wie
tägliche Commits und das automatisierte Auslösen eines Build bei jedem Commit nicht
durchführen, obwohl behauptet wird, Continuous Integration zu betreiben. Die Vorteile von
Continuous Integration bezüglich Software-Qualität können jedoch nicht realisiert werden, wenn
diese Prinzipien nicht eingehalten werden. In diesem Kapitel soll ein Überblick über effektive
Maßnahmen gegeben werden, durch welche Continuous Integration zur Steigerung der Software-
Qualität eingesetzt werden kann.

5.1 Tägliche und schnelle Integration der Änderungen

Wie in Kapitel 3.3.1 erläutert, ist eine essentielle Praxis von Continuous Integration der tägliche
Commit von Änderungen durch EntwicklerInnen auf eine gemeinsame mainline. Nur dadurch
kann sichergestellt werden, dass Änderungen gemeinsam mit den Änderungen anderer
EntwicklerInnen funktionieren. Zusätzlich erleichtert es das Finden von Fehlern durch das
ständige Testen der Änderungen durch andere EntwicklerInnen, was in Kapitel 3.5 beschreiben
wurde.

Jedoch sind viele Software-Erweiterungen nicht innerhalb eines Tages vollständig durchgeführt.
Daher müssen die benötigten Änderungen bei Anwendung von Continuous Integration auf
mehrere Tage aufgeteilt werden. Es muss dabei bei jedem Commit sichergestellt sein, dass die
mainline in einem funktionsfähigen Zustand bleibt. Die Änderungen am Quellcode sollten
inkrementell erfolgen und nach jedem Inkrement können diese dann committed werden. (Humble
& Farley, 2011)

Um Continuous Integration sinnvoll einsetzen zu können und den Umgang damit für
EntwicklerInnen zu erleichtern, muss auf einen möglichst kurzen Integrations-Build geachtet
werden, um Folgen wie die in Kapitel 3.3.2.2 beschriebenen zu verhindern. Falls ein Build länger
als das geforderte Limit dauert, können Änderungen am Build-Prozess durchgeführt werden, um
diesen schneller zu gestalten.

30
Duvall et al. (2007) schlagen hier mehrere Taktiken vor, um die Dauer von Build-Prozessen zu
verringern. Simple Verbesserungen sind der oft ohnehin für effektive Continuous Integration
notwendige eigenständige Integrations-PC sowie dessen hardwareseitige Aufrüstung. Wenn die
automatisierten Tests bzw. Inspektionen viel Zeit benötigen, können Maßnahmen zur
Verbesserung der Performance dieser gesetzt werden. Falls ein System aus mehreren
Komponenten besteht und Änderungen einer Komponente andere Komponenten nicht
beeinflusst, können eigene Integrations-Builds für jede Komponente einzeln durchgeführt
werden, was die Build-Zeit für ein Projekt stark reduzieren kann. Schlussendlich können bei vielen
modernen CI Servern mehrere PCs gleichzeitig für die Integration genutzt und Teile der CI
Pipeline auch parallel ausgeführt werden, was sich positiv auf die Durchlaufzeit von Integrations-
Builds auswirkt.

5.2 Hoher Grad automatisierter Tests auf allen Ebenen

In Kapitel 3.3.3 wurde das Durchführen automatisierter Tests als ein zentraler Bestandteil bei
Durchführung von Continuous Integration genannt. Dabei ist es für die Erreichung hoher
Software-Qualität wichtig, nicht nur Unit Tests einzuführen, sondern auch Komponententests und
E2E-Tests. Wenn sichergestellt wird, dass alle Klassen einer Codebasis eigenständig
funktionieren, jedoch nicht die Funktionalität des Gesamtsystems, sind trotzdem viele manuelle
Tests notwendig.

Bei der Durchführung von Unit Tests muss darauf geachtet werden, dass diese wirklich nur eine
Code-Einheit testen und abhängige Code-Teile durch Pseudo-Implementierungen ausgetauscht
werden (Duvall et al., 2007). Durch Praktiken wie TDD wird die einfache Unit-Testbarkeit dadurch
sichergestellt, dass bereits vor der Implementierung die Tests geschrieben werden und klar sein
muss, wie die Einheit getestet wird. Der Einsatz von TDD im Rahmen von Continuous Integration
ist grundsätzlich wünschenswert, jedoch nicht zwingend notwendig (Fowler, 2006a). Auch
Komponententests, die größere Einheiten mit ihren abhängigen Code-Teilen testen, sollten durch
EntwicklerInnen kontinuierlich geschrieben und ausgeführt werden.

Eine hohe Testabdeckung des Quellcodes ist jedenfalls eine Schlüsselaufgabe zur Erreichung
hoher Software-Qualität. Automatisierte Inspektionstools können im Rahmen eines Integrations-
Build die Testabdeckung der Codebasis berechnen und somit kann deren Entwicklung einfach
von den Software-EntwicklerInnen nachvollzogen werden. Wenn negative Trends erkennbar
sind, können EntwicklerInnen einerseits manuell eingreifen und Testfälle für schlecht getestete
Code-Einheiten hinzufügen. Andererseits kann aber auch der Integrations-Build so konfiguriert
werden, dass dieser bei Unterschreiten einer Grenze bezüglich Testabdeckung fehlschlägt,

31
wodurch EntwicklerInnen zum automatisierten Test ihrer Änderungen gezwungen sind. (Humble
& Farley, 2011)

Zusätzlich zu entwicklergerichteten Tests wie Unit- und Komponententests müssen zur

Erreichung hoher Software-Qualität auch kundengerichtete automatisierte Akzeptanztests
geschrieben werden, was ebenfalls in Kapitel 3.3.3 erwähnt wurde. Diese werden in
Unternehmen oft nicht implementiert, da ihre Implementierung sehr kostspielig sein kann. Dies
ist beispielsweise der Fall, wenn Akzeptanztests direkt mit der GUI interagieren und daher bei
kleinen Änderungen der GUI fehlschlagen. Wenn Akzeptanztests jedoch auf eine
Abstraktionsschicht über der GUI gerichtet sind, können diese stabil sein und weniger Kosten als
manuelle Tests verursachen. (Humble & Farley, 2011)

Wenn die GUI-Schicht wie in vielen modernen Anwendungen nur für die Anzeige zuständig ist,
können Tests gegen die Application Driver Schicht darunter implementiert werden, mit welcher
auch die GUI kommuniziert. Dies kann beispielsweise eine Abstraktion einer REST Schnittstelle
sein, über welche die Businesslogik verfügbar ist. Dabei sollten sich die Akzeptanztests direkt
aus den Akzeptanzkriterien der Anforderungen, beispielsweise von User Stories in agilen
Vorgehensmodellen, ableiten. Hier gibt es einerseits die Möglichkeit, Akzeptanzkriterien direkt
ausführbar zu beschreiben. Tools wie Cucumber oder Twist beschreiben die Akzeptanztests in
möglichst lesbarer Form, welche auch von Nicht-EntwicklerInnen einfach erlernbar ist. Diese
Akzeptanztests werden dann direkt mit Testimplementierungen wie beispielsweise in JUnit
verlinkt. (Humble & Farley, 2011)

In dieser Darstellungsform müssen jedoch die Beschreibungen der Akzeptanztests mit den
Implementierungen synchron gehalten werden, was einen Zusatzaufwand darstellt. Wenn die
Tester in einem Software-Projekt mit Programmierung vertraut sind oder die Tests von den
EntwicklerInnen geschrieben werden, können auch direkt xUnit-Frameworks wie beispielsweise
JUnit verwendet werden. Das hat den Vorteil, dass der Zusatzaufwand für die Spezifikation der
Akzeptanztests in Tools wie Cucumber nicht benötigt wird. Jedoch können aus solchen Test-
Implementierungen nur schwer lesbare Spezifikationsdokumente erstellt werden. (Humble &
Farley, 2011)

5.3 Sinnvolle automatisierte Inspektionen

Wie in Kapitel 3.4.2 beschrieben, können im Rahmen eines Integrations-Build auch
automatisierte Inspektionen durchlaufen werden. Neben der zuvor beschriebenen Inspektion der
Testabdeckung tragen auch Prüfungen auf die Anzahl an dupliziertem Code oder die Länge von
Methoden zur Überwachung der internen Software-Qualität bei. Die daraus gewonnenen
Metriken sollten regelmäßig überprüft, problematische Codestellen analysiert und bei Bedarf

32
verbessert werden. Oftmals stellt bereits die Kenntnis von problematischen Codestellen eine
Verbesserung gegenüber keinen Metriken dar, da bei Änderungen an diesen Stellen besonders
Acht gegeben werden kann.

5.4 CI Pipeline mit mehreren Phasen

Innerhalb einer CI Pipeline können viele Schritte automatisiert werden, wie Tests auf
verschiedenen Ebenen, Inspektionen oder Datenbankintegration. Teile wie Akzeptanztests oder
Inspektionen können jedoch oft nicht in einer für rasches Feedback akzeptablen Geschwindigkeit
durchgeführt werden. Um gleichzeitig die Zeit für Feedback auf Änderungen niedrig zu halten und
die Qualitätsgewinne für Software durch zusätzliche automatisierte Schritte zu erhalten, können
die Integrations-Builds in mehrere Phasen mit unterschiedlicher Geschwindigkeit aufgeteilt
werden (Fowler, 2006a).

Eine verbreitete Methode, Integrations-Builds aufzuteilen, ist ein Ansatz in zwei Phasen, wie es
beispielsweise Duvall et al. (2007) oder Humble und Farley (2011) beschreiben. In einer ersten
Phase wird die Anwendung kompiliert und einfache Unit Tests ausgeführt. Auch einfache
Inspektionen wie solche auf Einhaltung von Code-Richtlinien können dort ausgeführt werden, um
bei Nichteinhaltung den Build fehlschlagen zu lassen und dem/der Entwickler/in Feedback zu
geben. Eine zweite Phase führt dann umfangreichere Aufgaben wie automatisierte
Akzeptanztests oder komplexe Inspektionen auf beispielsweise Architekturkonformität durch. Die
zweite Phase wird entweder für jeden Commit durchgeführt, nachdem die erste Phase erfolgreich
war, oder aufgrund der langen Dauer in regelmäßigen Abständen beziehungsweise nachts.

5.5 Hohe Teamdisziplin

Viele Aspekte von Continuous Integration wie das Schreiben und die Erhaltung automatisierter
Tests oder die Einarbeitung von Feedback aus automatisierten Inspektionen können nicht
einmalig durchgeführt werden, sondern benötigen ständige Aufmerksamkeit durch die
EntwicklerInnen. Auch muss beispielsweise immer auf die Performance der Integrations-Builds
geachtet werden, da der Quellcode in der Regel größer und die Prüfungen im Rahmen von CI
umfangreicher werden. Aus diesen Tatsachen lässt sich schließen, dass viele Teile von
Continuous Integration eine hohe Disziplin der Teammitglieder bei ihrer Aufrechterhaltung
benötigen, wie auch Humble und Farley (2011) feststellen.

Teilaspekte von Continuous Integration können von Befürwortern von CI in einem Team durch
Unterstützung von CI Servern durchgesetzt werden, wie das Fehlschlagen von Integrations-
Builds aufgrund zu geringer Testabdeckung oder Nichteinhaltung der Code-Richtlinien. Um

33
jedoch Continuous Integration zielführend umsetzen zu können, ist die Zustimmung aller
beteiligten Personen notwendig (Duvall et al., 2007). Nur dadurch können auch die positiven
Effekte auf die Software-Qualität erreicht werden. Es muss zur Erhaltung einer
qualitätssteigernden CI Pipeline diese auch ständig verbessert werden, was eine Kultur der
kontinuierlichen Verbesserung, wie in Kapitel 2.4.2 beschrieben, voraussetzt.

34
6 CONCLUSIO UND AUSBLICK

Die DevOps-Bewegung stellt, wie in Kapitel 2 erläutert, eine Sammlung von kulturellen
Veränderungen, Praktiken und Werkzeugen dar. Diese sollen die Zusammenarbeit zwischen
EntwicklerInnen und IT-Operations-MitarbeiterInnen erhöhen, was Software öfter und mit höherer
Sicherheit und Qualität deploybar macht. Dabei sind die Definitionen von DevOps in
verschiedenen Quellen oft unterschiedlich. Dahingegen ist Continuous Integration eine klar
definierte Praxis, die die Zusammenarbeit zwischen EntwicklerInnen an einer gemeinsamen
Code-Basis verbessern und die Software-Qualität erhöhen soll.

Continuous Integration kann dabei als Praxis bei der Umsetzung von DevOps gesehen werden,
da Continuous Integration einen Fokus auf rasche Integration der Änderungen bei ständiger
Wahrung der Qualität setzt. Dies ist eine notwendige Basis, um die als Ziel von DevOps gesehene
häufige und rasche Release-Fähigkeit von Änderungen sicherzustellen. Die Begriffe Continuous
Delivery bzw. Continuous Deployment erweitern Continuous Integration um die Wahrung von
ständiger Release-Fähigkeit von Anwendungen durch beispielsweise mehr Fokus auf
automatisierte kundengerichtete Tests und den Softwareentwicklungsprozess über die Grenzen
der Entwicklungsteams hinaus. DevOps erweitert diese Ansätze noch um kulturelle Aspekte, die
notwendig sind, um solche Änderungen innerhalb von Teams und Abteilungen umzusetzen.

Continuous Integration wird von den meisten Unternehmen angewandt, jedoch oft nicht gemäß
ihrer eigentlichen Definition. Bei DevOps und Continuous Integration besteht gleichermaßen das
Problem, das viele Unternehmen darunter den Einsatz von bestimmten Tools verstehen, was
jedoch den erfolgreichen Einsatz dieser Praktiken nicht garantiert (Luke & Prince, o.D.; Verona,
2016). Continuous Integration kann jedoch bei Beachtung der in Kapitel 5 beschriebenen
Maßnahmen einen entscheidenden Beitrag zur Software-Qualität leisten.

Besonders österreichische KMU können die Qualitätsvorteile von Continuous Integration gut
nutzen, da diese wie in Kapitel 4.1 erläutert oft weniger Personal und finanzielle Ressourcen zur
Verfügung haben, manuelle Tests hier also schwerer durchzuführen sind. Hier können durch die
ständige Sicherstellung hoher Software-Qualität die Dauer von und Kosten für manuelle Test-
Zyklen reduziert werden.

Die dargestellten Schlussfolgerungen bezüglich der qualitätssteigernden Maßnahmen von

Continuous Integration und wie diese für österreichische Software-KMU von Vorteil sind beruhen
ausschließlich auf Literaturrecherche. Hier könnte eine quantitative Studie ansetzen, welche die
Effektivität von Continuous Integration bezüglich Software-Qualität in mehreren österreichischen
KMU misst. Andererseits kann auch eine Fallstudie eines österreichischen KMU erstellt werden,
bei der einzelne Maßnahmen zur Erreichung hoher Software-Qualität durch Continuous

35
Integration umgesetzt und dabei Metriken zur Messung der Software-Qualität vor und nach der
Umsetzung dieser Maßnahmen erstellt werden. Danach kann durch einen Hypothesentest
mithilfe der gewonnenen Daten überprüft werden, ob eine signifikante Verbesserung der
Software-Qualität erkennbar ist.

36
Abkürzungsverzeichnis

ABKÜRZUNGSVERZEICHNIS

CI… Continuous Integration

VCS… Version control system (Versionsverwaltung)
mainline, trunk, master… Bezeichnungen für den Hauptentwicklungszweig eines VCS
TDD… Test-Driven Development (Testgetriebene Entwicklung)
IDE… Integrated development environment (Integrierte Entwicklungsumgebung)
GUI… Graphical User Interface (Grafische Benutzeroberfläche)
KMU… Kleine und mittlere Unternehmen
IKT… Informations- und Kommunikationstechnologie
DBA… Datenbankadministrator/in
E2E-Tests… End-To-End-Tests

37
Abbildungsverzeichnis

ABBILDUNGSVERZEICHNIS

Abbildung 1: POM Datei eines Maven Projekts (eigene Abbildung) .......................................................... 19

Abbildung 2: Ausführung von JUnit Tests in Maven (eigene Abbildung) ................................................... 21
Abbildung 3: Darstellung einer CI Pipeline (in Anlehnung an Duvall, Matyas & Glover, 2007) ................. 22

38
Literaturverzeichnis

LITERATURVERZEICHNIS

Beck, K., Martin, R. C., Fowler, M., Cunningham, W., Cockburn, A., Beedle, M. et al. (2001). Manifest für
Agile Softwareentwicklung. Zugriff am 13.12.2018 unter
http://agilemanifesto.org/iso/de/manifesto.html

Davis, J. & Daniels, K. (2016). Effective DevOps. Building a Culture of Collaboration, Affinity and Tooling
at Scale. Sebastopol, USA: O'Reilly.

Duvall, P. M., Matyas, S. & Glover, A. (2007). Continuous Integration. Improving Software Quality and
Reducing Risk. Boston, USA: Pearson Education.

Fowler, M. (2005). TestDrivenDevelopment. Zugriff am 7.1.2019 unter

https://www.martinfowler.com/bliki/TestDrivenDevelopment.html

Fowler, M. (2006a). Continuous Integration. Zugriff am 12.1.2019 unter

https://martinfowler.com/articles/continuousIntegration.html

Fowler, M. (2006b). SemanticDiffusion. Zugriff am 12.1.2019 unter

https://martinfowler.com/bliki/SemanticDiffusion.html

Fowler, M. (2006c). Xunit. Zugriff am 17.1.2019 unter https://www.martinfowler.com/bliki/Xunit.html

Fowler, M. (2009). FeatureBranch. Zugriff am 3.2.2019 unter

https://www.martinfowler.com/bliki/FeatureBranch.html

Fowler, M. (2017). ContinuousIntegrationCertification. Zugriff am 13.1.2019 unter

https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

Hammant, P. (o.D.). Five-minute overview - Trunk Based Development. Zugriff am 12.1.2019 unter
trunkbaseddevelopment.com: https://trunkbaseddevelopment.com/5-min-overview/

Humble, J. (2010). Continuous Delivery vs Continuous Deployment. Zugriff am 12.1.2019 unter

continuousdelivery.com: https://continuousdelivery.com/2010/08/continuous-delivery-vs-
continuous-deployment/

Humble, J. & Farley, D. (2011). Continuous Delivery. Reliable Software Releases Through Build, Test,
and Deployment Automation. Boston, USA: Pearson Education.

Hüttermann, M. (2012). DevOps for Developers. Integrate Development and Operations, the Agile Way.
New York, USA: Springer.

Kim, G., Humble, J., Debois, P. & Willis, J. (2016). The DevOps Handbook. How To Create World-Class
Agility, Reliability, & Security in Technology Organizations. Portland, USA: IT Revolution Press.

39
 Literaturverzeichnis

Luke, E. & Prince, S. (o.D.). No One Agrees How to Define CI or CD. Zugriff am 12.1.2019 unter
https://www.gocd.org/2017/05/09/continuous-integration-devops-research/

Neubauer, T. & Zoder, M. C. (2016). Mittelstandsbericht 2016. Wien, Österreich: Bundesministerium für
Wissenschaft, Forschung und Wirtschaft.

Perry, W. E. (1992). Quality concerns in software development. Information Systems Management, 9(2),
48-52.

Poppendieck, M. & Poppendieck, T. (2007). Implementing Lean Software Development. From Concept to
Cash. Boston, USA: Pearson Education.

Puppet Labs. (2015). Puppet Labs 2015 State of DevOps Report.

Schwaber, K. & Sutherland, J. (2017). The Scrum Guide.

Schwarz, T. [Lernzone GmbH]. (2014, 6. Oktober). Toyota Kata - auf dem Weg zur Lean Kultur
[YouTube]. Verfügbar unter https://www.youtube.com/watch?v=Y4tTVO9Oz_w

Shore, J. (2006). James Shore: Continuous Integration on a Dollar a Day. Zugriff am 12.1.2019 unter
https://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

Verona, J. (2016). Practical DevOps. Harness the power of DevOps to boost your skill set. Birmingham,
Großbritannien: Packt Publishing.

Walls, M. (2013). Building a DevOps Culture. DevOps is as much about culture as it is about tools.
Sebastopol, USA: O'Reilly.

40

View publication stats