Grundlagen von DevOps

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Dortmund
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: DevOps
Autor(en): Jannek Höbener, Tim Mertin, Timo Surmann, Philipp Sobanski
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS16
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin: 10.6.2016
Abgabetermin: 5.6.2016


Name des Autors / der Autoren: Jannek Höbener, Tim Mertin, Timo Surmann, Philipp Sobanski
Titel der Arbeit: "Grundlagen von DevOps"
Hochschule und Studienort: FOM Dortmund


Inhaltsverzeichnis


1 Einleitung

1.1 Einführung in die Thematik

Moderne Unternehmen der heutigen Welt sind auf den Einsatz von zuverlässiger Software angewiesen. Diese stellt eine Schnittstelle zur Lösung der alltäglichen Probleme dar und trägt daher essentiell zum Erfolg der Unternehmung bei. Daher muss das perfekte Zusammenspiel von Soft- und Hardware gegeben sein. Um dies zu erreichen müssen die Entwicklung (Development) und der Betrieb (Operations) schon früh im Entwicklungsprozess neuer Software zusammenarbeiten. Oftmals arbeiten die beiden Abteilungen aber eher gegeneinander und verlangsamen so den ganzen Entwicklungsprozess als auch die Bereitstellung der neuen Software. Dies kostet dem Unternehmen oftmals viel Zeit und Geld und kann dazu führen, dass das Unternehmen den Vorteil gegenüber einem Mitbewerber verliert. Zusätzlich dazu steht während der Entwicklung auch bereits die Qualitätssicherung im Fokus. Daher müssen diese drei Bereiche von Anfang an zusammenarbeiten Dadurch wird die erforderliche Agilität und Stabilität der neuen Software erreicht und durch die kontinuierliche Zusammenarbeit mit dem Betrieb und der Qualitätssicherung kann die Software nach der Fertigstellung schneller veröffentlicht werden. Diese neue Art der Softwareentwicklung wird DevOps genannt und stellt das Zusammenspiel von Entwicklung, Qualitätssicherung und Betrieb dar. Es müssen daher bestimmte Prozesse im Unternehmen mit Hilfe von Teams umgesetzt werden, um DevOps im eigenen Unternehmen erfolgreich einsetzen zu können.

1.2 Zielsetzung

Das Ziel dieser Arbeit ist es dem Leser die Grundlagen von DevOps näherzubringen. Es wird dargestellt was wichtig ist um DevOps in einem Unternehmen einzuführen und wie ein erfolgreiches DevOps-Team erstellt wird. Außerdem wird aufgezeigt, welche Prozesse es im Rahmen von DevOps gibt und welche Tools zur Umsetzung der Entwicklung nach DevOps genutzt werden können.

1.3 Aufbau

Als erstes wird die grundlegende Idee von DevOps erklärt und wie diese entstanden ist. Anschließend wird erklärt was gegeben sein muss um DevOps im Unternehmen einsetzen zu können und mit welchen Prozessen dies dann umgesetzt werden kann. Abschließend werden noch einige Tools erläutert die zur Entwicklung nach DevOps eingesetzt werden können.

2 Definition DevOps

2.1 Entstehung

Als in den 1960ern die ersten Computer in den Unternehmen eingesetzt wurden, wusste niemand, wie diese das Arbeitsleben begleiten sollten. Zu dieser Zeit "[...]dachten wenige über Prozessmodelle, arbeitsteilige Organisationsstrukturen oder aufwändige Governance-Modelle nach"[1]. Nach und nach sollten immer mehr kleinere Probleme mit Software gelöst werden, um bestimmte Funktionen des Geschäftsprozesses zu vereinfachen. Mit Hilfe der Fachabteilung wurde versucht dieses Problem mit entsprechender Software zu lösen. Da diese meist sehr komplex sein musste, führte es dazu dass Software bald teurer wurde als die Hardware. Auch nahm die Entwicklung dieser Software meist viel Zeit in Anspruch, sodass die Anfragen des Unternehmens bald die Leistungsfähigkeit der Fachabteilung überschritten. So hatte sich Mitte der 60er Jahre die Softwarekrise entwickelt. Dazu kam es aber auch, da es zu dieser Zeit wenig Personal gab, welches die benötigte Software konstruieren konnte. Und das geschah schon weit vor der Umsetzung ganzer Geschäftsprozesse, was demzufolge die nächste große Hürde darstellte[2].

Auf einer NATO-Konferenz im Jahre 1968 wurde die Problematik der Softwarekrise thematisiert und diskutiert. Als Resultat dieser Diskussion kann Software Engineering gesehen werden. Dies soll fortan ein Entwurfsmodell für die Softwareentwicklung sein. Dennoch steht zu dem Zeitpunkt noch nicht fest, wie dieses Modell wirklich aussehen soll. Die Erfinder des Software Engineerings einigen sich darauf, sich an einem bereits gelösten Problem vom Anfang des 20. Jahrhunderts zu orientieren. Henry Ford hatte zu der Zeit ein Muster entwickelt, um die Produktion von Autos enorm zu beschleunigen. Durch sein Muster konnte er die Produktion um bedeutsame Größenordnungen steigern, was dazu verhalf den Bedarf des großen Marktes zu decken. Einhergehend damit wurde die Produktion auch kosteneffizienter umgesetzt. Das Muster sah vor, den Produktionsprozess in kleinere Schritte zu spalten und diese dann von Spezialisten auf dem Gebiet ausführen zu lassen. Diese kleinen Schritte erfolgten an einem Fließband, welche alle Schritte der Produktion verband. Dadurch entstand ein Prozess, der beliebig erweitert oder gekürzt werden konnte. Die Kosten der Produktion wurden rapide gesenkt, zum einen wegen der Losgrößeneffekte und zum anderen war es nicht mehr nötig teure Experten einzustellen die das Auto komplett verstehen und zusammenbauen konnten. Es waren nun ausreichend Arbeitskräfte zu beschäftigen, die einen bestimmten Teil der Produktion gezeigt bekommen und diesen immer wieder ausführten. Diese grundlegenden Ideen nahmen die Erfinder des Software Engineerings auf und entwickelten so das nicht vorhandene Modell[2]. "Diese Ideen griffen die Begründer des Software-Engineerings auf und damit hielten Prozessmodelle, Arbeitsteilung und Spezialisierung Einzug in die IT: Es wurde zwischen Analyse, Design, Implementierung, Test, Inbetriebnahme und Betrieb unterschieden und man begann, die einzelnen Disziplinen weiter auszuarbeiten und zu spezialisieren."[1]

Abbildung 1 - Von der Softwarekrise zu DevOps
Abbildung 1 - Von der Softwarekrise zu DevOps[3]

Das Konzept wurde mit den wachsenden Herausforderungen in der IT- Branche über die Jahre immer weiterentwickelt und neu konzipiert. Aber die Softwarekrise wurde nie für überstanden erklärt, was sie genaugenommen auch nicht ist. Der Anspruch an neue Software ist immer weitergewachsen und so wurden auch immer neue Ziele von Software deklariert, die zunächst nicht umgesetzt werden können. Zum Beispiel darf die Entwicklung aufgrund der Schnelllebigkeit der Branche nicht zu lange dauern und muss wegen des großen Marktes zu einem günstigen Preis angeboten werden[4]. Laut Friedrichsen wurde dieser Zustand nach über 20 Jahren aber als normal angesehen[5]. Auch wegen der Schnelllebigkeit der Branche müssen diese Konzepte immer neu überdacht werden. So trug der Wandel des PCs vom Luxusgut hinüber zum Alltagsgegenstand in den frühen 90er Jahren unter anderem dazu bei, dass das Modell wieder angepasst werden musste. Mit hinzu kommt, dass die Systeme der Unternehmen immer vernetzter wurden und es somit notwendig war, Software für ganze Geschäftsprozesse zu entwickeln. Die IT hat sich heute so weit entwickelt, dass sie für ein Unternehmen essentiell geworden ist und ohne sie ein normaler Betrieb des Unternehmens nicht mehr denkbar ist. Für diese erneute Überarbeitung ist größtenteils die in den 1990ern entstandene agile Bewegung verantwortlich, die besser zu den veränderten Anforderungen an Software passt und die aus heutiger Sicht besser zu dem Aufbau der Unternehmen passt. Dabei geht die agile Bewegung laut Friedrichsen unter anderem auf folgende Punkte der Softwareentwicklung ein[5]:

  • Es hat eine Rückbesinnung von Verfahren auf den Geschäftswert stattgefunden
  • Entsprechend wurden Verantwortlichkeiten neu aufgeteilt, z.B. in Form eines Product Owners bei Scrum anstelle von Projekt- und Produktmanagern
  • Die Entwicklungszyklen sind deutlich kürzer geworden
  • Das flexible Reagieren auf geänderte Anforderungen wurde deutlich verbessert
  • Die Prozessmodelle wurden verschlankt
  • Die Hierarchien sind in der Regel flacher geworden
  • Routinetätigkeiten wurden stärker automatisiert, um mit den schnelleren Entwicklungszyklen besser umzugehen
  • Zusammen mit einer intensivierten Testautomatisierung führte dies zu einer besseren Softwarequalität
  • Alle Ansätze basieren auf einem Wertesystem, bei dem – im Unterschied zum Taylorismus – Menschen und Interaktionen im Vordergrund stehen

Aber auch diese Form der Softwareentwicklung beachtet eine grundlegende Eigenschaft der IT-Abteilung noch nicht: Die IT-Abteilung besteht meist aus zwei Fachrichtungen, der Entwicklung und dem Betrieb. Die agilen Prinzipien beziehen sich bislang aber nur auf den Bereich der Entwicklung. Dadurch sind die beiden Bereiche bei der Softwareentwicklung noch getrennt. Das heißt, dass in der Entwicklung bereits schnell und flexibel nach den Methoden der agilen Bewegung gearbeitet wird aber der Betrieb noch in den alten Strukturen des Software- Engineerings festhängt. Dadurch werden die Vorteile der agilen Entwicklung hinfällig, da ein Softwarerelease mit den herkömmlichen Methoden immer noch monatelang dauern kann. Des Weiteren ist es möglich, dass Bestandteile der Entwicklung, wie z.B. die Überwachbarkeit, in Folge der unterschiedlichen Arbeitsweisen auf der Strecke bleiben. Natürlich kann der Betrieb anhand dessen die Inbetriebnahme der neuen Software absichtlich verzögern. Aufgrund dieser Problematik hat der Belgier Patrick Debois im Jahre 2009 die sog. "DevOpsDays" in Belgien abgehalten. Ziel dieser Konferenz sollte es sein, eine Methodik zu entwickeln die Entwicklung und Betrieb weiter zusammenbringt. Daraus ist der Begriff "DevOps" entstanden, welcher aus Dev (engl. für Development – Entwicklung) und Ops (engl. für Operations – IT-Betrieb) besteht und seitdem für diese neue Methodik steht[5].

2.2 Definition

Den Begriff DevOps gibt es seit 2009. Dies ist bis heute gerechnet für die IT-Welt ein langer Zeitraum von 7 Jahren. Die meisten Themen sind da schon wieder überholt. Bei DevOps ist es anders. Auch nach dieser langen Zeit gibt es für DevOps keine feste Definition als solche. Nachfolgend werden hier einige Definitionen aufgelistet um zu verdeutlichen, wie unterschiedlich dieser Begriff verstanden werden kann und welch weites Spektrum darin zusammengefasst wird.

Laut Hüttermann ist DevOps weit verbreitet, aber viele verschiedene Arten von Inhalten sind mit diesem Wort verknüpft[6]. Weiter sagt Hüttermann, das DevOps ein Mix aus bekannten, fortgeschrittenen Praktiken und neuen, innovativen Ansätzen für bestehende Projekte ist[7].

Laut Ernest Mueller kann DevOps sehr wohl in einem Satz definiert werden: "DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support."[8]

Ähnlich wie Mueller sieht das auch Peschlow, der sich auf den Grundgedanken des Begriffes "DevOps" beruft: "Der Begriff setzt sich zusammen aus "Dev", der die Softwareentwickler (Developers) repräsentiert, und "Ops", der für den IT-Betrieb (Operations) steht. Die Kombination zum gemeinsamen "DevOps" symbolisiert intuitiv einen Schulterschluss zwischen Softwareentwicklern und IT-Betrieb."[9] Aber in seiner Publikation gibt Peschlow auch an, dass DevOps die Ideen von Agilen Operationen aufgegriffen hat und dadurch in den letzten Jahren verschiedene Ziele formuliert werden konnten[10].Die Ziele "[...] lassen sich in drei Bereiche einteilen: Zusammenarbeit, Automatisierung und Prozesse.“[11]

Das Ziel der Zusammenarbeit soll es sein, die agilen Prinzipien des Software-Engineerings abteilungsübergreifend einzusetzen und somit ein Mehrwert aus der Zusammenarbeit zu ziehen[12].

Das Ziel der Automation ist es laut Peschlow, "[...]die Automatisierung von Vorgängen im IT-Betrieb und die gemeinsame Nutzung von Tools zwischen Entwicklung und Betrieb zu fördern." [13]

Das Ziel im Bereich der Prozesse soll es sein, "[...]geeignete Prozesse für die Einführung und Nutzung von DevOps-Ideen zu definieren."[14]

In dieser Arbeit richten wir uns nach den Zielen von Peschlow und gehen auf die drei definierten Bereiche Zusammenarbeit in Form von den Teams, Prozesse und Automation in Form der Tools ein.

2.3 Missverständnisse

Aufgrund dessen das DevOps noch relativ jung ist und es noch keine feste Definition dafür gibt, wird der Begriff DevOps oft falsch verwendet bzw. falsch verstanden. Wir möchten hier einige Missverständnisse aufzeigen. Vielleicht wird der Begriff DevOps an sich dadurch auch noch klarer.

DevOps ist grundsätzlich das Zusammenwachsen von Entwicklung und Betrieb. Doch DevOps ist nicht nur das, sondern betrachtet die gesamte IT-Wertschöpfungskette. Natürlich werden nicht alle Teile der Kette gleichermaßen angepasst, denn viele Vorgänge werden z.B. aus der agilen Programmierung übernommen[15].

Einhergehend damit ist DevOps auch keine neue Abteilung oder Fachrichtung. Es ist ein Prinzip der Softwareentwicklung woran der Betrieb und die Entwicklung maßgeblich beteiligt sind. Daher gibt es auch keine neue Jobbezeichnung. Es werden z.B. weiterhin Entwickler eingestellt und in der Jobbeschreibung darauf hingewiesen das nach DevOps gearbeitet werden soll[16].

Oft wird angenommen, dass sich DevOps nur auf die Automatisierung von "Build und Deployment" bezieht. Die Automatisierung dieser zwei Bereiche nennt sich "Continous Delivery" und ist etwa zur gleichen Zeit wie DevOps entstanden und Thema geworden, wodurch sie oft verwechselt werden. Natürlich ist die Automatisierung der Prozesse auch Teil von DevOps, aber es ist nur ein Teil des großen Ganzen[15].

Um die Prinzipien von DevOps in der Entwicklung und dem Betrieb erfolgreich umzusetzen, werden viele Prozesse mit Hilfe von Tools geändert bzw. angepasst. Daher ist es ein großes Missverständnis, dass mit einem oder mehreren Tools DevOps einführen werden kann ohne die Logik dahinter zu verstehen, diese dienen lediglich als Hilfsmittel. Vielmehr müssen die Zusammenarbeit und die Kommunikation der beteiligten Personen gewährleistet sein und die Prozesse verbessert werden. Dies kann natürlich auch mit verschiedenen Tools erreicht werden[17].

2.4 Grundsätze

Anders als bei der Definition sind die Grundsätze von DevOps sehr klar definiert. Folgende Grundsätze können nach Haddad als essentiell für die Umsetzung von DevOps angesehen werden[18]:

  • Iterative
  • Incremental
  • Continuous
  • Automated
  • Self-service
  • Collaborative
  • Holistic

Dennoch lassen sie einen gewissen Spielraum für den Anwender. So ist es für ihn nicht erforderlich sich an alle diese Grundsätze zu halten.

Desweiteren sind die "Drei Wege des DevOps" von Gene Kim weitere Grundsätze die heutzutage als elementare Bestandteile von DevOps gesehen werden[15].

Abbildung 2 - Weg 1:Betrachtung der ganzen Wertschöpfungskette
Abbildung 2 - Weg 1:Betrachtung der ganzen Wertschöpfungskette[19]

Der erste Weg ist nach Kim auf Performance des ganzen Systems ausgelegt. Dabei wird die benötigte Funktion in der Entwicklung geschrieben und dann an den Betrieb weitergegeben, der es dann an den Endkunden in Form von Service weiterreicht[20]. Dabei wird aber die ganze Wertschöpfungskette betrachtet und ggfs. optimiert[15].

Abbildung 3 - Weg 2:Feedback wird in den Prozess aufgenommen
Abbildung 3 - Weg 2:Feedback wird in den Prozess aufgenommen[21]

Der zweite Weg nach Kim führt das Feedback in den Entwicklungsprozess ein. Das heißt, dass die Prozesse an sich verkürzt werden sollen und das Feedback verstärkt wird. Dadurch können kontinuierlich Korrekturen und Optimierungen an der Software vorgenommen werden[20].

Abbildung 4 - Weg 3:kontinuierliches Experimentieren
Abbildung 4 - Weg 3:kontinuierliches Experimentieren[22]

Der dritte Weg ist das ständige Experimentieren mit neuer Software. Mit den Ergebnissen der kontrollierten Experimente wird eine Kultur der kontinuierlichen Verbesserung aufgebaut[15].

2.5 Voraussetzungen

Im folgenden Abschnitt wollen wir auf die Voraussetzungen eingehen, die für ein erfolgreiches Einführen der DevOps Methoden gegeben sein müssen. Hier ist natürlich schwer zu sagen, wie diese auf jedes einzelne Unternehmen zutreffen, da DevOps so viel beinhalten kann und somit auch unterschiedliche Voraussetzungen gegeben sein müssen. Die nachfolgenden Voraussetzungen haben wir daher als essentiell angesehen und können im einzelnen Fall variieren.

Grundlegend sollte beachtet werden, dass das Einführen einer neuen Strategie immer ein schmaler Grat ist. Daher sollten den beteiligten Personen zunächst erstmal viele Freiheiten gewährt werden. So kann das Team festlegen, welche Tools für die Umsetzung benötigt werden, welche Prozesse abgeändert werden müssen und wie die Zusammenarbeit des neuen Teams am besten funktioniert[23].

Des Weiteren sollte vor der Einführung grob geklärt sein, wer welche Aufgabe im Team übernehmen soll. Anhand dessen sollte der Mitarbeiter dann ggfs. noch geschult werden, damit er die neuen Tätigkeiten nach der Einführung direkt wahrnehmen kann. Durch die Zusammenarbeit von Entwicklung und Betrieb ist es auch nötig, dass sich die Abteilung auch Grundkenntnisse in den jeweils anderen Fachrichtungen aneignet[23].

Um die Ergebnisse nach der Einführung sichtbar zu machen, sollte es das Ziel sein, möglichst viele Schritte der neuen Prozesse sichtbar zu machen. Dies kann durch die Auswahl der richtigen Tools und Werkzeuge gewährleistet werden, die z.B. einen Report anfertigen können. So kann zum einen die Geschäftsführung von den neuen Methoden überzeugt werden und zum anderen sieht das Team selber was den Erfolg des Projektes ausmacht. Sollte das Projekt nicht erfolgreich verlaufen, kann anhand dieser Daten auch analysiert werden[23].

Auch sollte im Team jeder Schritt kommuniziert werden und bei Unschärfen sollten andere Teammitglieder zur Rate gezogen werden. Durch diese konstante Zusammenarbeit hat jeder das gemeinsame Ziel vor Augen und jeder ist für das Gesamtprodukt verantwortlich[23].

Natürlich wird der erste Schritt das erarbeiten der neuen Prozesse sein, dennoch sollten die vier angesprochenen Punkte von Anfang an beachtet werden um dem Erfolg der Einführung von DevOps entgegenzukommen.

2.6 Nutzen

Doch was bringt DevOps dem Team, dem Unternehmen oder dem Kunden? Welcher Mehrwert kann daraus gezogen werden? Um diese Frage zu beantworten, muss DevOps aus drei verschiedenen Richtungen betrachtet werden.

Widmen wir uns zunächst dem Team an sich. Was haben die Teammitglieder einer DevOps Umgebung für einen Nutzen? Jedes Teammitglied muss unweigerlich auch ein bestimmtes Wissen in Bereichen der beteiligten Abteilungen aufbauen um das Projekt erfolgreich abschließen zu können. Dies ist ein großer Nutzen da viel Fachwissen in unterschiedlichsten Bereichen aufgebaut werden kann welches über den Bereich der eigenen Arbeit hinausgeht[24].

Abbildung 5 - Aufbau von Fachwissen der anderen Teams
Abbildung 5 - Aufbau von Fachwissen der anderen Teams[25]

Kommen wir nun zu dem Nutzen des Unternehmens. Laut Sharma gibt es für Unternehmen drei große Nutzen die ein Unternehmen aus DevOps ziehen kann. Als erstes nennt Sharma eine verbesserte Kundenerfahrung mit dem Produkt, wodurch sich der Kunde gerne langfristig an das Unternehmen als Ansprechpartner bindet. Gleichzeitig kann dadurch ein größerer Marktanteil aufgebaut werden. Um diese Erfahrung aufzubauen, muss das Unternehmen ständig Feedback von Kunden aufnehmen und auch darauf reagieren[26]. Als zweiten Punkt nennt Sharma eine höhere Innovationsfähigkeit des Unternehmens. Durch das ständige Feedback des Kunden können die Ressourcen besser auf die erfolgreicheren Produkte verschoben werden und somit schneller neue Innovationen auf den Markt gebracht werden[26]. Als dritten Punkt gibt Sharma an, dass dadurch der RoI verbessert wird. Durch die schnellere und effizientere Programmierung der Software kann diese früher beim Kunden eingesetzt werden und die Entwicklungskosten werden ausgeglichen[27].

Kommen wir zum Schluss noch auf den Nutzen für den Kunden. Dieser ist durch DevOps stark in den Entwicklungsprozess mit eingebunden und kann so das Team bereits in den Anfängen unterstützen und Erfahrungen aus der Praxis mit einfließen lassen. Dadurch ist das Endprodukt noch besser auf ihn abgestimmt. Auch kann er während der Entwicklung bereits bestimmte Teile der Software testen, sodass dies keine Zeit nach Fertigstellung in Anspruch nimmt. Hier wird die Entwicklungszeit verkürzt und somit kann der Kunde die Software schneller einsetzen bzw. auf den Markt bringen.

3 DevOps Team

3.1 Team-Struktur

Abbildung 6 - Aufbau eines DevOps-Teams
Abbildung 6 - Aufbau eines DevOps-Teams

Die Größe eines DevOps-Teams kann individuell von Projekt zu Projekt vom Unternehmen unterschiedlich eingeteilt werden. Es ist vom Unternehmen selbst abhängig, welche Variante bevorzugt wird. Beispielsweise gibt es bei dem Unternehmen "Amazon" eine "two pizza rule". Diese Regel besagt, dass ein Team nur so groß sein soll, das zwei Pizzen reichen um das gesamte Team satt zu bekommen. Hier gibt es natürlich Spielraum, was Größe der Pizza und des Hungers angeht, aber die Intention wird klar[28].

"Es sollte ein guter Mix aus den Bereichen "Betrieb", "Test" und "Entwicklung" sein. Die Kollegen sollten dabei einerseits über ausreichend fachliche Kompetenz und kommunikative Fähigkeiten verfügen, andererseits aber auch das große Ganze beziehungsweise den Business-Nutzen verstehen und in den Fokus stellen."[29]

Vorteile von kleinen Teams[28]:

  • Die Termine benötigen weniger Zeit im Allgemeinen, da es nicht so lange dauert, bis jedes Teammitglied seine Meinung zu einer Thematik geäußert hat
  • Vielen Leuten fällt es leichter ihre Meinung vor einer kleinen Gruppe zu äußern, als vor einer größeren Menschenmenge

Vorteile von großen Teams:

  • Es werden mehrere Blickwinkel des Projektes betrachtet, da es hier mehrere Meinungen gibt
  • Die Testphasen werden gründlicher und in mehreren verschiedenen Arbeitsweisen getestet

Beide Varianten bieten also Vor- und Nachteile. Für welche Art von Team sich ein Unternehmen entscheidet hängt als von der Unternehmensphilosophie ab. Am Beispiel "Amazon" ist zu sehen, dass es hier klare Richtlinien in Bezug auf die Teamgröße geben kann.

Ein genereller Vorteil eines DevOps-Teams ist es auch, dass die Konflikte nun innerhalb eines Teams ausgetragen und gelöst werden können. Es gibt also kein "Schuldzuweisungs-Tennis", denn das Team muss als Ganzes für diesen Konflikt gerade stehen. Hier besteht also auch Einsparungspotenzial in den Punkten Zeit und Ärger. Durch das gemeinsame Angehen des Problems im Team wird wesentlich schneller eine Lösung des Problems gefunden[30]. "Durch den Dialog zwischen "Dev" und "Ops" werden auch nicht funktionale Eigenschaften der Systeme besser beachtet, also Fragen der Sicherheit, Stabilität, Pflege sowie Skalierbarkeit – Eigenschaften, die ein Produkt nachhaltig und robust machen."[31]

Auch externe Partner können die Verantwortung für den erfolgreichen Betrieb der Anwendung und der neuen Features übernehmen und nicht nur für das Bereitstellen neuer Funktionen[32]. Externe Partner sind häufig nur mit dem Projektmanager in Kontakt. Deshalb ist der externe Partner in Abbildung 6 herausgehoben.

3.2 Projektmanagement

Abbildung 7 - Ziele eines Projektmanagers
Abbildung 7 - Ziele eines Projektmanagers[33]

"Der Projektmanager ist derjenige, der bei einem Projekt im Unternehmen die Fäden in der Hand hat, die Schnittstelle, an der alle Stränge zusammentreffen. Er muss führen, organisieren, mit Budget umgehen und auch großem Druck standhalten können. Dabei darf er den Blick fürs große Ganze nicht verlieren."[34]

Für den Kunden dient der Projektmanager als Ansprechpartner und als beratende Stelle für die technische Machbarkeit. Er steht mit dem kompletten Team im engen Kontakt. Organisiert die verschiedenen Meetings und sorgt für eine geregelte Kommunikation zwischen den Teammitgliedern.

"Der Projektmanager steht immer unter großem Druck"[34], da er für die Vorgesetzten oder der Geschäftsführung der Hauptverantwortliche des Projektes ist[33]. "Der Projektmanager ist zuständig für die Planung, Umsetzung, Abnahme und Nachbereitung von Projekten."[34]

Die Kommunikationsfähigkeit des Projektmanagers ist die wichtigste Voraussetzung, um ein guten Projektablauf zu gewährleisten. Der Projektmanager muss stets transparent sein und offen für die Vorschläge der Teammitglieder.

3.3 Design

Das Design einer Software ist maßgeblich an dem Erfolg gebunden. Ein benutzerfreundliches und einfaches Design ist einer der Hauptgründe für den Erfolg einer Software. Es gibt verschiedene Ansätze, wie ein DevOps-Team das Thema Design bearbeiten kann. Im nachfolgenden wird kurz der Ansatz "Design Thinking erläutert. Der Ansatz "Design Thinking" baut auf die Bedürfnisse des Kunden auf. Soll dieser von dem neuen Produkt überzeugt werden, so sollte viel mit dem Kunden über seine Vorstellungen und Wünsche geredet werden. Anschließend kann die Vorgehensweise in sechs Schritte unterteilen werden[35]:

  1. Verstehen: Das DevOps-Team muss verstehen, was der Kunde für ein Problem hat und welchen Lösungsweg er gerne hätte. Hier steht der Projektmanager mit Rat und Tat zur Seite in Absprache mit dem Rest des Teams.
  2. Beobachten: Ist das Problem erkannt muss der Kundenprozess, der optimiert werden soll, gründlich beobachtet werden. Hierfür muss das tägliche Geschäft des Kunden gründlich analysiert werden. Die Beobachtung ist Grundlage für die erfolgreiche Umsetzung eines Projektes.
    Abbildung 8 - Design Thinking
    Abbildung 8 - Design Thinking[35]
  3. Sichtweise definieren: Nun müssen die gesammelten Beobachtungen analysiert werden und in verschiedene Sichtweisen definiert werden. "Verdeutlichen kann man das an einem einfachen Beispiel: Obwohl das ganze Jahr über Bier konsumiert wird, gehen die Leute bei Regen und Schnee nicht in den Biergarten. Die Einsicht daraus: Man kommt nicht nur wegen dem Bier in den Biergarten, sondern wegen der schönen Atmosphäre und um einen schöne Zeit mit Freunden zu haben."[36]
  4. Ideen finden: Anschließend werden im DevOps-Team Ideen gesammelt. Dies geschieht mittels Brainstorming o.Ä. Methoden. "Beim Brainstorming sind außenstehende Personen hilfreich, da sie oft neue Ideen mit einbringen."[36]
  5. Prototyping: Beim Prototyping geht es nicht um das Testen der Alpha-Version, sondern sie helfen "die Ideen zu veranschaulichen und innerhalb der Zielgruppe zu testen". "Der Nutzer soll ein Gefühl davon bekommen, wie die Idee oder das Produkt später funktionieren und aussehen könnte."
  6. Testen: Getestet werden so viele Prototypen, bis der Kunde sagt, dass es der eine werden soll. Wichtig ist hierbei, dass der Kunde zufrieden mit gesehenen Prototypen ist und die Idee dahinter versteht[35].

Als kurzes Fazit von "Design Thinking" lässt sich sagen, dass es nicht unbedingt ein Garant für den Erfolg ist. Aber durch die Einbeziehung des Kunden wird die Chance, dass dieser am Ende des Projektes mit dem Produkt zufrieden ist, erhöht.

3.4 Entwicklung

Die Entwickler in einem DevOps-Team arbeiten wesentlich direkter mit Ihren Ansprechpartnern zusammen, als "normale" Entwickler. Die Entwickler werden in jedes Meeting mit einbezogen und arbeiten eng mit dem Projektmanagern und den Designern zusammen.

Stichwort für die Entwicklung im DevOps-Team ist agile Entwicklung. Dabei geht es nicht nur um hilfreiche Tools, sondern auch um Softskills der Mitarbeiter. Das Augenmerk liegt hier auf Kommunikation und Transparenz[37]. Das "sind wichtige Aspekte der agilen Arbeitsorganisation".[38] "Ein Taskboard und ein "Daily meeting" sorgen nicht nur dafür, dass das Team seine Arbeitsschritte transparent macht, sondern fördern Verständnis für die Arbeit der anderen und sorgen dafür, dass das Team Probleme löst."[38]

Des Weiteren wird viel Wert darauf gelegt, dass die Software benutzbar und wartbar wird. In der agilen Entwicklung sollte es eine Arbeitsanweisung geben und selbstverständlich sein so zu arbeiten.[37]

Einen großen Unterschied für Entwickler macht die Häufigkeit der Releases im Jahr. In der agilen Entwicklung verfolgt DevOps den Ansatz mehrere kleinere Releases im Jahr zu veröffentlichen. DevOps verfolgt einen gegensätzlichen Ansatz zum klassischen "Big Bang" mit ein oder zwei großen Releases im Jahr. DevOps priorisiert häufigere und kleinere Releases, die das Kundenerlebnis direkt und sofort verbessern können. Dies wird auch "Continuous Delivery" genannt[39].

Auch im Punkto Anwendungstypen oder Entwicklersprache ist DevOps neutral. Es gibt natürlich bevorzugte Sprachen, aber grundsätzlich ist es mit jeder Entwicklersprache möglich[39].

Durch die enge Zusammenarbeit dieser Teams wird der ewige Streit in den IT-Abteilungen, wer Schuld hat und wer nicht aufgelöst, da das Team immer als Ganzes für ein Projekt verantwortlich ist[37].

3.5 Qualitätsmanagement

Auch die Qualitätssicherung muss, wie die Entwicklung auch, immer agiler in ihrer Arbeit und in ihren Methoden werden durch DevOps. Die Tests werden während "des Software-Entwicklungs-Lebenszyklus durchgeführt"[38] und nicht zu einem bestimmten Zeitpunkt des Projektes. Ein wichtiger DevOps-Ansatz der Qualitätssicherung ist "Continuous Integration". Dieser Ansatz bietet die Möglichkeit die Tests in einer isolierten Umgebung stattfinden zu lassen und die Ergebnisse sofort den Entwicklern mitzuteilen. Hier gibt es die Möglichkeit sofort auf Fehler zu reagieren und diese zu korrigieren. Diese Methode der frühen Fehlererkennung und Behebung ist sowohl nützlich, als auch günstig[39].

Abbildung 9 - Qualitätsmanagement Ebenen
Abbildung 9 - Qualitätsmanagement Ebenen [40]

Für Qualitätsmanager gibt es zwei Ebenen, auf denen sie sich bewegen. Die Strategische- und die Operative Ebene, wobei die strategische die klassische Ebene ist. Laut DIN ISO 8402 umfasst "das Qualitätsmanagement (QM) alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagements verwirklichen"[40]. "Die operative Ebene beschäftigt sich mit der Planung und Konzeption der Testfälle und Tests, der Steuerung der Testdurchführung sowie der Kommunikation innerhalb des Projektes."[41]

Trifft der Kunde während des Betriebs der Software auf einen Fehler muss er hier nie lange auf Support warten und kann dementsprechend zuverlässig mit der Software arbeiten. Ein Beispiel: Eingebundene Tests finden üblicherweise spät am Tag statt. Im Rahmen dessen gibt es eine grundsätzliche Wahl, den Einsatz aufgrund entdeckter Fehler zu verschieben oder limitierte Tests durchzuführen, die die Defekte riskieren, die während der Produktion entstehen. Bei einer DevOps-Methode würde das integrierte Testen bereits mehrere Stufen vorher stattfinden[39].

Die Qualitätssicherung steht im stetigen Austausch mit den Entwicklern. Der Projektmanager muss hier für ein gutes Arbeitsklima innerhalb des DevOps-Teams sorgen, damit hier die Kommunikation und Transparenz hochgehalten wird.

4 DevOps Prozesse

4.1 Umfeld der Prozesse

In einem Unternehmen gibt es eine große Vielfalt an Prozessen und Abläufen, welche in den Unternehmen definiert und dokumentiert werden. Jedes Unternehmen besitzt seine eigenen Definitionen und diese werden alle in unterschiedlichen Dokumenten oder auf Plattformen festgehalten.
Abbildung 10  - DevOps Lebenszyklus
Abbildung 10 - DevOps Lebenszyklus
Laut einer Ausarbeitung von Friedrichsen und Wolf ist der Begriff "DevOps" noch nicht lange in Unternehmen bekannt und daher existieren noch keine Standards oder Richtlinien die in den Unternehmen eingesetzt werden (vgl. Die Reise nach DevOps). Des Weiteren wird darauf hingewiesen, dass der Begriff ein breites Spektrum an Interpretationen zulässt. Die Sichtweise spielt bei der Betrachtung auf die Prozesse eine besondere Rolle, ebenfalls eine wichtige Rolle spielt die Aufgabe im Team [15].

Im Wesentlichen versucht DevOps die Prozesse von Betrieb und Entwicklung zusammenzuführen beziehungsweise, diese aufeinander abzustimmen. Laut Bass, Webber und Zhu werden die Prozesse Betrieb, Entwicklung, Build, Testing, Deployment, Ausführung als Hauptprozesse in DevOps definiert [28]. Friedrichsen und Wolf greifen ebenfalls Entwicklung, UX (als Betrieb), Testing und Service in Ihrer Arbeit als Prozesse auf [42].

4.2 Entwurf und Design

Der Prozess Entwurf und Design umfasst eine Art Aufbereitung der Anforderungen der betrieblichen Seite von DevOps. Im agilen Umfeld wurden spezielle Teams entwickelt die fachlich besonders hochqualitativ arbeiten können und schnellstmöglich auf Änderungen des Kunden reagieren können. Diese Spezifikationen der Anforderungen werden im weiteren Verlauf in erste Designs extrahiert und mit dem Kunden abgestimmt[43]. Aufgrund des agilen Wertesystems geschehen diese Abstimmungen fortlaufend.

Laut Bass, Weber und Zhu wird innerhalb des Prozesses Entwurf und Design, in der sogenannten "Inception Phase", noch umfangreicher auf Themen eingegangen. Neben der Erhebung von Anforderungen über Designs und Spezifikationen wird noch auf die Release-Planung eingegangen. Diese umfasst die Planung von Auslieferungen in gewissen Intervallen (Continous Delivery), das Dokumentieren von Abhängigkeiten unter den einzelnen Releases und eine Vorsorge bei Fehlern innerhalb der Auslieferung. Des Weiteren werden laut den Autoren innerhalb der Inception Phase geprüft, ob für die Nutzung der Software Fortbildungen oder Schulungen für die Mitarbeiter veranlasst werden müssen. Falls Auslieferungen entgegen des Testing doch Fehler aufweisen, müssen Notfallpläne/-prozesse definiert sein, welche in diesem Notfall eingreifen. Zudem weisen Bass, Weber und Zhu auf die Automatisierung der Auslieferungen hin welche eine Release-Planung in einigen Aspekten nicht in dem Umfang nötig macht [44].

Zusammengefasst würden im Bereich "Entwurf und Design" folgende in der aufgelisteten Reihenfolge entstehen:

Abbildung 11 - Prozessschritte von Entwurf und Design
Abbildung 11 - Prozessschritte von Entwurf und Design

4.3 Entwicklung und Testing

Aufgrund der großen Anteile der jeweiligen Prozesse innerhalb der jeweiligen Bereiche werden die Prozesse zunächst gesondert voneinander betrachtet und abschließend zu einem Prozess zusammengeführt. Aufgrund der nicht vorhandenen oder definierten Prozesse werden in den folgenden Prozessen die allgemein gültigen Verfahren angesprochen, welche jedoch innerhalb von DevOps genutzt werden.

4.3.1 Entwicklung

Für die Entwicklung ist es wichtig, dass alle Entwickler gemeinsam auf einer Grundlage arbeiten. Als Basis dafür existieren diverse Vorgehen oder auch Systeme die eigene Prozesse zur gemeinsamen Enwicklung (engl. Collaborative Development) unterstützen. In der Vergangenheit war es so, dass Entwickler den Quellcode lokal entwickelt haben, dass änderte sich in den 1980er, als das CVS (Concurrent Versions System) und in den 2000er das SVN (Subversion) eingeführt wurden [45].

CVS und SVN waren zentralisierte Lösungen wo Entwickler den Quellcode auschecken können um diesen dann lokal zu bearbeiten und dann zurück zum Server zu schicken [45].

Die aktuellste Lösung für den Ansatz der zentralisierten Entwicklung basiert auf der von GIT. Diese sieht vor, dass der Entwickler den für Ihn relevanten Quellcode aus der zentralen Lösung als Klon auf das lokale System kopiert. Aus diesem Klon leitet der Entwickler sogenannte "Branches" in den er Änderungen am Quellcode erstellt und lokal testen kann ob diese den Anforderungen entsprechen. Es besteht die Möglichkeit mehrere Branches zu erstellen um unabhängige Lösungen oder Fixes für den "Master Branch" (Hauptenwicklungslinie) zu entwickeln. Um mit dem Master Branch zu kommunizieren existiert eine GIT-Bash. Über diese kann der Entwickler gewisse Befehle ausführen um aktuelle Versionen vom Master Branch zu erhalten (pull-Befehl) oder seine eigenen Änderungen in den Master Branch zu übeführen (push-Befehl) [45].

Während des Prozesses der Entwicklung, werden einzelne Änderungen die lokal innerhalb eines Branches erstellt wurden mit bestimmten Versionen versehen, die es den Entwicklern ermöglicht, genau zu prüfen welcher Quellcode zu welcher Zeit von welchem Entwickler in den Master Branch überführt wurde. Die Versionierung erhält einen sogenannten "Commit", dieser Commit (dt. Kommentar) weist auf die Änderungen hin und beschreiben diese in einem kurzen Satz, um ein gemeinsames Verständnis Personen übergreifend zu ermöglichen[45].

Abbildung 12 - Prozessschritte Entwicklung
Abbildung 12 - Prozessschritte Entwicklung

4.3.2 Testautomatisierung in der Entwicklung

Aufgrund dessen, dass DevOps auf viele Automatisierungen zurückgreift, wird auch das Testing automatisiert. Hier herrscht jedoch noch keine klare Zuordnung wer die Testautomatisierung innerhalb des Projektes übernimmt, es kommt auf das vorhandene Personal und die jeweiligen Kenntnisse des eingesetzten Tool und der eingesetzten Programmiersprache an.

Hüttermann beruft sich auf eine Zusammenarbeit von Entwicklung und Betrieb und greift als Grundlage der Tests die Automatisierungspyramide auf. Diese besagt, dass im Prozess zunächst die Unit Tests geschrieben werden, darauf folgend die Service Tests und die UI Tests. Der Prozess des Testings wird auch in der Entwicklung ausgeführt. Der Prozess wird dann ausgeführt, wenn im Qualitätsmanagement keine Mitarbeiter mit Entwicklungskenntnissen vorhanden sind[46].

Unit Tests

Unit Tests sind unabhängige Testfälle, die keine weiteren Abhängigkeiten haben. Es werden spezifizierte Aufgaben getestet, die laut Hüttermann in Sets abgearbeitet werden. Das Verfahren wird auch White-Box-Testing genannt, da für die Tests ein Wissen über den geschrieben Quellcode vorhanden sein muss. Testfälle werden zuvor von der Qualitätssicherung geschrieben und dann von der Entwicklung umgesetzt. Dafür ist eine enge Zusammenarbeit zwischen Entwicklung und Qualitätssicherung nötig[47].

Service Tests

Im Zuge der Service Tests wird die Integration der Schnittstellen innerhalb einer Software getestet. Der Entwickler prüft damit, ob der geschrieben Quellcode, mit den anderen Schnittstellen kommuniziert und Informationen austauschen kann. Das Verfahren ist aufgrund der vorhandenen Kenntnisse über den Quellcode das White-Box-Testing und wird als zweiter Prozessschritt gesehen[48].

UI Tests

UI Tests sind nach Hüttermann, sogenannte Black-Box-Tests, da diese den geschriebenen Quellcode nicht kennen und die Funktionen der fertigen Software testen. Diese Tests werden auch funktionale Tests genannt und werden vom Qualitätsmanagement definiert. Die Entwicklung setzt diese Testfälle dann in der Automatisierung um und prüft ob das erwartete Ergebnis auftritt[49].

4.3.3 Testing

Nach den aktuellen anerkannten Richtlinien des ISTQB (International Software Testing Qualifications Board) werden im Wesentlichen die in Abbildung Nr. 13 aufgezeigten Prozesse im Qualitätsmanagement angewendet. Diese beziehen sich ebenfalls auf die DevOps Umgebung, da diese wiederum aus dem agilen Umfeld stammt.

Als Grundlage dient das von Linz und Spillner verfasste Werk "Basiswissen Softwaretest", welches den fundamentalen Testprozess aufgreift. Dieser Testprozess dient zur Strukturierung des Qualitätsmanagements und als allgemeine Grundlage für die Qualitätssicherung[50]. .

Abbildung 13 - Fundamentaler Testprozess
Abbildung 13 - Fundamentaler Testprozess

Testplanung und Teststeuerung

Im Verlauf der Testplanung werden die Ressourcen welche für das Testing vorgesehen sind verwaltet. Als wichtigstes Dokument während der Testplanung ist das Testkonzept, welches während der Planung erstellt wird. Innerhalb des Testkonzeptes wird die Teststrategie definiert, welche sich an der Risikobewertung der einzelnen Softwarebestandteile orientiert. Des Weiteren werden die einzelnen Tests einer ersten Priorisierung unterzogen und geprüft in wie weit diese aussagekräftig ist. Die Teststeuerung wird über den ganzen Testprozess hinweg eingesetzt und basiert auf den Kennzahlen die durch die Ausführung der Tests erhoben wurden[51].

Testanalyse und Testspezifikation

Die Testanalyse beginnt im Prozess mit der Analyse der Testbasis, die Testbasis ist die Grundlage aller vorhandenen Dokumente, die für die Entwicklung der Software aussagekräftig sind. Des Weiteren wird die Testbarkeit einzelner Module geprüft und die vorherige Risikoanalyse erneut hinzugezogen. Innerhalb der Testspezifikation werden zuerst logische Testfälle erstellt und in einem zweiten Schritt konkrete Testfälle. Hierbei ist darauf zu achten, dass eine Rückverfolgbarkeit zwischen den Anforderungen und den spezifizierten Testfällen vorhanden ist[52]. .

Testrealisierung und Testausführung

Während der Testrealisierung ist besonders auf die Protokollierung zu achten, da Tests ohne Protokollierung wertlos sind. Vor der Durchführung muss jedoch zunächst die Testumgebung, die Testdaten und die Vollständigkeit der zu testenden Teile geprüft werden. Getestet werden zunächst die Testfälle mit der höchsten Priorität und dann absteigend nach Priorität. Bei Abweichungen zum erwarteten Testergebnis sollten diese, wie oben erwähnt, dokumentiert werden und nach einer Behebung durch die Entwicklung erneut getestet werden[53]. .

Testauswertung und Bericht

Im Prozess der Testauswertung werden die zu Beginn festgelegten Kriterien, welche die Beendigung der Testausführung bestimmen, gegenüber dem Status verglichen. Ein konkretes Ende des Testings wird durch die Zeit und die Kosten definiert. Während des Berichts werden die Kosten mit den Aufwänden verglichen und geprüft in wie weit diese gerechtfertigt sind[54]. .

Abschluss der Testaktivität

Im Fokus des Abschluss der Testaktivitäten stehen besonders die Erfahrungen die während des Testings gesammelt wurden. Diese werden aufbereitet und analysiert um sie für spätere Projekte hinzuziehen zu können. Des Weiteren werden sämtliche Testmittel archiviert und die Dokumente abgeschlossen[55]. .

4.3.4 Zusammenführung Entwicklung und Testing

Entwicklung und Testing laufen während des kompletten Projektes parallel zueinander und sind in stetiger Kommunikation miteinander. Die jeweiligen Prozesse mit den Unterprozessen werden innerhalb des Projektes aufeinander abgestimmt und in jedem Unternehmen unterschiedlich behandelt. Da für DevOps kein grundlegendes Konzept existiert, sind die Unternehmen und Projektteams frei in der Wahl der Verfahren und Prozesse.

4.4 Deployment und Support

4.4.1 Deployment

In dem Prozess Verteilung (engl. Deployment) ist die Verteilung der Versionen auf diverse Systeme und Umgebungen gemeint. Dieser Prozess ist laut Bass, Weber und Zhu ein "Alles oder Nichts" Prozess. Mit der Auslieferung läuft ein System entweder normal weiter oder es ist nicht mehr Betriebsfähig. Dadurch können hohe Verluste entstehen [56].

Das Verfahren im Zuge von DevOps wird auch "Continous Delivery" und umfasst neben der Auslieferung an den Kunden auch die Auslieferung verschiedener Versionen auf die Entwicklungs- und Testsysteme. Nach Sharma werden hier automatisiert die benötigten Daten, Softwarekomponenten über ein Tool zusammengeführt, wodurch ein neuer Versionsstand entsteht, den vor allem das Qualitätsmanagement nutzen kann um manuelle Tests durchzuführen [57].

Als ein wichtiger Bestandteil des Deployments ist der zuvor festgelegte Releaseplan, der während der kompletten Entwicklungsphase beachtetet werden muss. Bevor ein Stand ausgeliefert werden kann, durchläuft er zunächst noch einige Stationen[57].

Abbildung 14 - Deployment Stationen
Abbildung 14 - Deployment Stationen

Blue/Green Auslieferung

Dieser Prozess beinhaltet die Auslieferung von zwei Versionen. Diese basieren auf zwei Zuständen, zum einen ein bereits geprüftes und abgenommenes System (stabil) und eine Version die aktuelle Fehlerbehebungen oder neue Umsetzungen nach Anforderungen beinhaltet. Die stabile Version wird auf ein gewisse Anzahl an Systemen ausgeliefert und die Version mit Fehlerbehebungen oder Neuerungen wird auf eine gewisse Anzahl von Systeme ausgeliefert. Anschließend wird geprüft ob das System mit den Fehlerbehebungen und Neuerungen ebenfalls in der Umgebung beim Kunden vollständig funktioniert[58].

Rolling Upgrade

Im Prozess des Rolling Upgrade Prozesses wird sofort auf das System eine Version mit Neuerungen und Fehlerbehebungen für eine stabile Version ausgetauscht. Es werden in gewissen Abständen die weiteren bereits vorhandenen Versionen abgelöst und in kurzen Iterationen die weiteren. Dieses Verfahren ist besonders kostenintensiv und zeifaufwändig und benötigt eine höhere Anzahl an Systemen[59].

4.4.2 Support

Der sogenannte Support, beschreibt hier laut Bass, Weber und Zhu die fortlaufende Betreuung der Systeme auf denen die Releases getestet und entwickelt werden. Nach einer erstmaligen Auslieferung werden fortlaufend die Weiteren Versionen mit den oben beschriebenen Methoden und Prozessen unterstützt.

4.5 Überwachung und Optimierung

Nach Zhu, Weber und Bass werden bestimmte Kennzahlen erhoben, die über die technischen und betrieblichen Vorgänge Aufschluss geben. Die Ziele die verfolgt werden sind folgende:

  • Sicherstellung von Fehlern und deren Gründe, auch wenn der Fehler bereits aufgetreten ist
  • Zur Identifizierung und Dokumentierung von Geschwindigkeitsproblemen auf dem System, der Software oder der Interaktion von Software und Systemen
  • Darstellung von Arbeitsaufkommen und Ressourcennutzung auf den Plattformen und dient zur Planung für spätere Entwicklungen
  • Verhalten der Benutzer soll identifiziert und protokolliert werden um gezielter zu entwickeln und betriebliche Aspekte wie Marketing besser platzieren zu können
  • Überwachung und Feststellung von möglichen Angreifern auf das System

Um Monitoring durchführen zu können müssen es die Entwickler bereits während der Entwicklungsphase mit eingebaut haben. Gemeint sind damit die sogenannten Erstellungen von Log-Dateien. Diese beinhalten Informationen von sämtlichen Aktionen und Reaktionen der Software in einem bestimmten Zeitraum. Nachdem die Entwicklung diese in der Software implementiert hat, können ausgewählte Tools für die jeweiligen Bereiche aufgesetzt werden. Jedes Team besitzt eigene Software um die benötigten Informationen vom System oder dem Kunden ab zu greifen. Die Entwicklung verfolgt die technischen Ziele, die oben aufgelistet wurden, um diese in späteren Optimierungen nutzen zu können. Anhand der erhobenen Daten können die Entwickler, nach einer Analyse der Daten, gezielt auf Schwächen im System und der Architektur reagieren und diese in Folge weiterer Entwicklungen berücksichtigen. Für die betrieblich orientierten Teams innerhalb eines Projektes werden sogenannte "Boards" erstellt um Kennzahlen zum Verhalten des Kunden anhand von Metriken und Diagrammen darzustellen. Zuvor werden die Daten von den betrieblichen Teams ebenfalls analysiert und können dann nach der zuvor erwähnten Aufbereitung an die Geschäftsführung weitergeleitet werden[60].

5 Plattformen und Tools für DevOps

5.1 Grundlagen

Abbildung 15 - DevOps ist nicht eine einzige "Tool-Suite"
Abbildung 15 - DevOps ist nicht eine einzige "Tool-Suite"[61]

Wie bereits in den vorangegangenen Kapiteln erläutert, ist es ein grundlegendes Ziel der DevOps-Bewegung die Lücke zwischen Entwicklung und Betrieb zu schließen. Prozesse sollen gemeinsam ausgeführt werden. Doch gerade in Hinsicht der eingesetzten Tools ist in den traditionellen IT-Betrieben eine klare Lücke zwischen Entwicklung und Betrieb zu erkennen. Es muss also Ziel sein, diese Lücke zu schließen und eine Zusammenstellung aus Tools zu finden, die von beiden Arbeitsgruppen akzeptiert wird und eingesetzt werden kann[62].

Einige Leute bevorzugen es jedoch über Tools anstelle von Mitarbeitern und Prozessen nachzudenken, wenn sie mit DevOps konfrontiert werden. Ohne ein Verständnis für die grundlegende Idee von DevOps, die Zusammenarbeit zu verbessern und Prozesse zu teilen, wird die Einführung neuer Tools scheitern. Einige Mitarbeiter werden das Gefühl bekommen, dass "bloß neue Tools eingeführt werden". Das große Ziel muss es also sein mit neuen Tools eine Zeitersparnis zu erzeugen, welche es den Mitarbeitern ermöglicht sich auf schwerwiegendere Probleme zu fokussieren[63].

Abbildung 15 beschreibt eine weitere Gefahr in der Einführung von DevOps-Tools. Sollte ein Tool versprechen, alle Bereiche von DevOps in sich zu vereinen, sollte es nicht weiter in Betracht gezogen werden[63].

Die im Folgenden vorgestellten Tools werden mit großer Wahrscheinlichkeit in vielen Unternehmen aktuell nicht eingesetzt. Oftmals werden deshalb bereits existierende Tools für DevOps instrumentalisiert und implementiert. Ein gutes Beispiel stellt hier die Versionsverwaltung dar. Jene wird in den meisten Fällen nur für Quellcode genutzt. Im Zuge der Einführung von DevOps können hier auch für den Betrieb relevante Dateien abgelegt werden[64].

Nachfolgendend werden anhand des in Abbildung 16 gezeigten DevOps Prozesses eine Auswahl an Tools vorgestellt. Die jeweiligen Tools stellen dabei eine Plattform für den jeweiligen Prozessschritt bereit.

Abbildung 16 - DevOps Prozess als unendlicher Zyklus
Abbildung 16 - DevOps Prozess als unendlicher Zyklus[65]

5.2 Planung

Wie bereits im Kapitel 4 angesprochen, implementiert DevOps Methoden der agilen Entwicklung. Ein wichtiger Bestandteil dieser ist die Planung der anstehenden Aufgaben in bestimmten Abschnitten.

Mit dem Produkt "Jira Software" hat Atlassian genau in diesem Bereich eine Lösung geschaffen[66]. JIRA Software ist in seiner grundlegenden Funktion ein Ticketsystem, welches allgemein am Häufigsten für "Software-Bug-Tracking" genutzt wird. Dank seiner erweiterten Anpassungsmöglichkeiten kann es jedoch für viele weitere Einsatzgebiete genutzt werden[67]. Dadurch ist es gerade in der agilen Entwicklung eine große Unterstützung. JIRA Software implementiert Scrum als eine agile Methode der Softwareentwicklung[68]. So können innerhalb des Tools Aufgaben angelegt werden, ein Sprint-Backlog verwaltet werden, Teamengagement und –geschwindigkeit identifiziert werden oder Berichte zum Fortschritt im Team erstellt werden[69].

Abbildung 17 - Worklow in JIRA Software
Abbildung 17 - Worklow in JIRA Software[70]

Die Abbildung 17 beschreibt einen Workflow in der JIRA Software, wenn im Team Scrum als agile Entwicklungsmethode eingesetzt werden. Dabei arbeiten Projektleitung ("Managers") und Entwicklung ("Users") zusammen. Die Projektleitung legt Projekte an und plant eine neue Version der zu entwickelnden Software. In bestimmten Abschnitten werden Sprints durchgeführt. Eine gängige Laufzeit eines Sprints ist hier eine Woche. Am Anfang dieser Woche wird der Sprint geplant. Während dieser Planung werden den einzelnen Entwicklern Aufgaben zugeteilt, die während der Laufzeit des Sprints zu erledigen sind. Am Ende eines Sprints wird dann eine Analyse der vergangenen Woche durchgeführt und neue Erkenntnisse, Probleme und deren Lösungsansätze festgehalten. Sind alle Planungspunkte der Version abgearbeitet, geht die neue Version in den Release. Am Ende des beschriebenen Prozesses wird das Projekt dann abgeschlossen[69].

Ein weiterer Bestandteil jeder Planungsphase ist es Wissen auszutauschen und festzuhalten. Atlassian hat auch für diese Anforderung eine geeignete Plattform namens "Confluence" entwickelt[71]. Es ist bereits seit langem auf dem Markt verfügbar und stellt damit ein frühes Beispiel einer webbasierten Wiki-Plattform dar. Es wird bereits von einer großen Anzahl an Unternehmen eingesetzt[72]. Confluence kann in der Cloud von Atlassian oder auf einem eigenen Server verwendet werden. Für kleine Teams von bis zu zehn Benutzern betragen die Kosten 10$ pro Monat. Überschreiten die Benutzer eine Anzahl von zehn steigen die monatlichen Kosten[73].

Mit Confluence werden unter anderem folgende Anwendungsfälle abgedeckt[74]:

  • Erstellung einer technischen Dokumentation
  • Aufbau einer Wissensdatenbank
  • Aufbau eines internen Wikis

Gerade die Softwareentwicklung kann diese Plattform nutzen um ihre tägliche Arbeit zu dokumentieren, erlangtes Wissen zu teilen oder Zugriff auf Produktanforderung zu erhalten. Diese Anforderungen werden dann wiederum von anderen Teams in Confluence eingepflegt. Dadurch wird eine erste Schnittstelle zwischen mehreren Abteilungen errichtet[75].

5.3 Entwicklung

Die Entwicklung steht im Zuge der Umsetzung von DevOps auch vor neuen Herausforderungen. So muss sich sich zunehmend mit Aspekten aus dem Betrieb auseinandersetzen. Das Aufsetzen von physikalischen oder virtuellen Maschinen oder die Absicherung von Systemen sind nur eine kleine Auswahl dieser neuen Aufgaben[76]. Doch auch hier kann mit der richtigen Auswahl von Tools eine Unterstützung gewährleistet werden.

Für viele Anwendungsfälle werden in der Softwareentwicklung immer wieder neue virtuelle Maschinen aufgesetzt. Mit ihnen werden Umgebungen oder Anforderungen simuliert. Ein großer Nachteil dieser Lösung ist die enorme Größe einer virtuellen Maschine. Diese bewegt sich häufig im einstelligen GByte-Bereich. Dadurch werden die Portabilität und auch die Weiterentwicklung mittels einer Versionsverwaltung enorm erschwert[77]. Hier unterstützt ein Tool namens Docker. Es wurde im März 2013 veröffentlicht[78]. Aktuell liegt es in der Version 1.4 vor[79]. Es ist ein Open-Source Projekt und unter der Apache Lizenz 2.0 lizensiert[80]. Docker stellt mit seiner Architektur Container zur Verfügung. In diesen Containern ist es möglich eine beliebige Applikation mit all ihren Abhängigkeiten zu betreiben. Es stellt damit eine einheitliche Entwicklungsumgebung bereit [78].

Abbildung 18 - Docker Architektur
Abbildung 18 - Docker Architektur[81]

Abbildung 18 gibt eine Übersicht über die Architektur von Docker. Im unteren Bereich ist das Host-System angesiedelt. Dies kann je nach Wahl eine dedizierte oder virtuelle Maschine mit Linux-Betriebssystem sein. Die Docker Engine wird dann auf dieser Maschine installiert und stellt die Funktionalitäten zum Erstellen, Ausliefern und Betreiben von Docker Containern bereit. Dieses Modell ermöglicht es, mehrere Programme in verschiedenen voneinander unabhängigen Containern zu starten. Dies resultiert in einer besseren Auslastung der Ressourcen des eigentlichen Host-Systems. Außerdem verhindert es fehlerhafte Wechselwirkungen, die in einem parallelen Betrieb der Anwendung auf einem System entstehen können. Die Docker Container werden aus Programmabbildungen erstellt. Diese werden auf einer Plattform wie dem "Docker Hub" verwaltet[82].

Neben einer vereinheitlichten Entwicklungsumgebung sollte auch der Quellcode in einer für andere Teams offenen Form verwaltet werden. So kann außer der Softwareabwicklung auch der Betrieb direkt auf den erstellten Quellcode zugreifen und ihn erweitern. Diese Plattform stellt Atlassian mit ihrem Produkt "Bitbucket" zur Verfügung. Es ist eine Quellcode-Versionsverwaltung auf der Basis von Git. Ein großer Vorteil dieses Tools ist es, dass es eine Verbindung zur JIRA Software besitzt. Dadurch ist es möglich, den erstellten Quellcode mit der jeweiligen geplanten Aufgabe zu verknüpfen.

Die Vorteile der Nutzung einer zentralen Quellcode-Versionsverwaltung sind vielfältig. So macht sie es als führendes Medium überflüssig, die einzelnen Maschinen jeweils manuell anzupassen[83]. Außerdem ist eine direkte Verbindung mit TeamCity umsetzbar. TeamCity lauscht nach Veränderungen in dem Git-Repository auf dem Bitbucket-Server. Erkennt es eine Veränderung wird automatisch der konfigurierte Build-Prozess gestartet. Das Tool TeamCity wird im Folgenden noch in dem Bereich "Kontinuierliche Integration" vorgestellt[84].

5.4 Kontinuierliche Integration

TeamCity ist ein Tool zur kontinuierlichen Integration (CI) von der Firma JetBrains. Wie bereits erwähnt, startet Teamcity nach Veränderung in der Quellcodeverwaltung einen konfigurierten Build-Prozess. Dieser Prozess impliziert eine Zusammenstellung des Quellcodes, die Ausführung von Unit-Tests und Integrationstests. Zum Abschluss wird der zusammengestellte und erfolgreich getestete Quellcode automatisch kompiliert. Auch eine abschließende Verteilung der kompilierten Software in eine Testumgebung kann über TeamCity realisiert werden[85].

TeamCity ist mit der "Professional Server License" kostenfrei zu nutzen. Es können in dieser Variante bis zu 20 Konfigurationen verwaltet werden und auf bis zu drei "Build agents" parallele Build-Prozesse durchgeführt werden[86].

Grundsätzlich ist der gesamte Build-Prozess davon abhängig, in welcher Programmiersprache die Software umgesetzt ist. TeamCity bietet hier die Unterstützungen von allen gängigen Sprachen. Java, C# und Ruby gehören dabei unter anderem zum gegebenen Funktionsumfang. Darauf aufbauend lassen sich auch viele Plugins zur individuellen Erweiterung einbinden. So wird eine auf die jeweiligen Anforderungen passende Lösung realisierbar. Auch Docker wird über ein vorhandenes Projekt bereits unterstützt. Es ist also möglich, die vorhandene Entwicklungsumgebung auch auf Testumgebungen kontinuierlich zu übertragen[87]. Zum Funktionsumfang gehört ebenfalls eine RESTful API [88]. Diese stellt Endpoints zur Ausführung von Remote-Aktionen zur Verfügung. Als Quellcodeverwaltung werden ebenfalls alle gängigen Plattformen unterstützt, auch die im Rahmen dieser Ausarbeitung angesprochenen Quellcodeverwaltung Git. Wie bereits angesprochen, sind spezielle "Build agents" für die Ausführung des Build-Prozesses zuständig. Diese können auf mehreren oder unterschiedlichen Rechnern installiert werden und unabhängig genutzt werden. Durch zur Laufzeit erstellte Statistiken lässt sich die Last ausgewogen auf mehrere "Build agents" verteilen. Neben den bereits vorgestellten Funktionen kann TeamCity auch direkt in mehrere Entwicklungsumgebungen integriert werden. Zwei Beispiele dafür sind die JetBrains IDE IntelliJ[89] und Microsofts Visual Studio[90][91][92].

5.5 Softwareverteilung

Am Ende des Build-Vorgangs von TeamCity steht der kompilierte Quellcode, der ebenfalls automatisiert auf die jeweiligen Umgebungen verteilt werden muss. Dadurch wird der komplett automatisierte Prozess von der Entwicklung bis zu dem Betrieb der Software beim Kunden realisiert. Ein manuelles Eingreifen der Entwicklung oder des Betriebs ist nicht mehr notwendig.

Das Produkt Octopus Deploy ermöglicht eine automatisierte Softwareverteilung[93]. Es kommuniziert über eine Schnittstelle direkt mit TeamCity[94]. Grundlegend ist Octopus Deploy ein benutzerfreundlicher und automatisierter Server zur Softwareverteilung. Er ist optimiert für .NET Applikationen. Ein Ziel dieses Tools ist es eine wiederholbare und vertrauenswürdige Softwareverteilung zu ermöglichen[95]. Obwohl es vom Grundsatz her für .NET optimiert wurde, unterstützt es jedoch auch weitere Technologien. Die Verteilung einer NodeJS[96] Applikation wird bereits offiziell in der Dokumentation des Produkts beschrieben[97]. Aktuell liegt Octopus Deploy in der Version 3.4 vor[98]. Für kleine Teams mit bis zu 5 Benutzern ist es auch im kommerziellen Umfeld kostenfrei zu betreiben. Steigt die Anzahl der Benutzer ist eine einmalige Lizenz zu erwerben. Der zu entrichtende Betrag startet hier bei einer Höhe von 700$[99].

Abbildung 19 - Funktionsweise Octopus Deploy
Abbildung 19 - Funktionsweise Octopus Deploy[100]

Der Octopus Deploy Server setzt auf bereits vorgestellte Tools auf. Im ersten Schritt checkt der Entwickler seinen Code in die Versionsverwaltung ein. Bitbucket wurde im Rahmen dieser Arbeit an dieser Stelle vorgestellt. Im weiteren Verlauf wird der Quellcode von TeamCity als Grundlage für seinen Build-Prozess genutzt. Nach erfolgreichem Abschluss des Build-Vorgangs wird in diesem Beispiel der kompilierte Quellcode in ein NuGet Paket[101] verpackt. An dieser Stelle setzt nun der Octopus Deploy Server ein. Seine Aufgabe ist es, diese Pakete an die jeweiligen Test-, Staging- und Produktionsserver weiterzugeben. Auf diesen Servern wird das NuGet Paket dann verarbeitet. Bei erfolgreichem Abschluss dieser Aktion wird die verteilte Applikation auf den jeweiligen Servern gestartet[100].

"We’ve gone from manual to automatic and we’re reaping the rewards. We’re continuously deploying our projects to various environments on a daily basis, our developers are spending more time coding and less time fixing broken deployments. As a result of all this our clients get to see our progress much sooner than before, and we’re able to get feedback much sooner than before."[102]

Automatisierte Softwareverteilung resultiert in einer regelmäßigeren Verteilung der Softwareprodukte auf verschiedenen Umgebungen mit einem wesentlich geringeren Aufwand. Die geschaffene Zeitersparnis gibt jedem Entwickler die Möglichkeit sich mehr auf das eigentliche kodieren zu fokussieren. Doch nicht nur intern bringt die automatisierte Softwareverteilung seine Vorteile mit sich. Auch für den Kunden ist die Veränderung spürbar. Aktualisierungen sind schneller als bisher realisierbar. Eine kontinuierliche und kurzfristige Reaktion auf gemeldete Probleme wird realisierbar[103].

5.6 Betrieb

Ist die Software nach Abschluss aller vorangegangen Prozessschritte letztendlich entwickelt, erstellt und verteilt so muss ein zuverlässiger Betrieb gewährleistet werden. Dafür sollte die Applikation und ihr Umfeld kontinuierlich überwacht werden. Die kontinuierliche Überwachung mittels Tools wie Nagios[104] oder Munin[105] geben eine detaillierte Einsicht in den Status des überwachten Systems, auf dem die Software ausgeführt wird[106]. Die so zur Verfügung gestellten Daten und Metriken können auch von anderen Bereichen außerhalb des Betriebs genutzt werden. Die Entwicklung kann anhand dieser Daten ihre Software Stabilität verleihen und auch die Qualitätssicherung ist damit in der Lage Maßnahmen zu erarbeiten[107].

Für die kontinuierliche Überwachung während des Betriebs werden je nach Größe der Umgebung eine große Anzahl an Informationen gesammelt. Werden neben der Informationsvielfalt noch mehrere Tools für verschiedene Systeme im eingesetzt, so stellt sich das Problem der Übersicht. Genau bei der Übersicht setzt ein sehr interessantes Tools namens BigPanda ein[108]. BigPanda ist eine Data Science Plattform, die es IT-Teams ermöglich eine effektive Problembehebung auch in großen und dynamischen Umgebungen. Skalierung, Geschwindigkeit und Fragmentierung sind hier so weit fortgeschritten, dass es für den Betrieb eine große Herausforderung ist den Überblick über den aktuellen Status aller Systeme zu wahren[109].

Abbildung 20 - BigPanda
Abbildung 20 - BigPanda[110]

BigPanda steht in der Mitte der zur kontinuierlichen Überwachung eingesetzten Tools. Neben Lösungen für das Monitoring (Nagios[111], Cloudwatch[112]) können unter anderem auch Tools aus dem Bereich der Planung (JIRA) oder Chat-Plattformen für die Kooperation im Team (Slack) eingebunden werden. Von den Monitoring-Systemen sammelt BigPanda Benachrichtigungen und stellt diese in einer übersichtlichen und vorgefilterten Form dar. Dadurch ist es dem Betriebsteam möglich, schnell auf Warnungen zu reagieren. Die weiteren eingebundenen Tools können zum Beispiel genutzt werden um als Reaktion auf eine aufgetretene Störung direkt eine Aufgabe im JIRA anzulegen oder das Team über eine Chat-Plattform direkt über das Problem zu informieren. Eine permanente Durchsicht aller Systeme im Einzelnen ist mit dem Einsatz von BigPanda nicht mehr notwendig[113].

5.7 Kontinuierliche Rückmeldung

Mit den bereits vorgestellten Tools ist es nun möglich einen maximal automatisierten Prozess von der Planung bis zum Betrieb der Software zu realisieren. Während jedem dieser Schritte werden verschiedene Informationen produziert. Informationen über die Performance, Stabilität oder Ergebnisse der Tests. Doch nicht nur durch die internen Prozesse werden Daten gesammelt. Auch der Endverbraucher produziert eine große Vielzahl an Daten, wenn er mit der Software interagiert[114].

Doch gerade diese Informationen der Endverbraucher sind nur mit Hilfe eines passenden Tools auszuwerten. Pendo ist eines dieser Tools. Die Firma Pendo wurde im Jahr 2013 gegründet. Ihr Ziel war es damals, ein Produkt zu entwickeln, welches die Gründe für den Erfolg einer Software analysiert. Pendo sammelt alle Verhaltensdaten der Anwender, analysiert diese und stellt sie in einer übersichtlichen und anpassbaren Form dar. Darüber hinaus bietet es Fragebögen an, die nahtlos in eine Anwendung integriert werden können. Mit Pendo lässt sich ebenfalls eine Hilfe für Anwender in der Software einbetten. Damit können dem Kunden bei Aktualisierungen zum Beispiel Hilfestellungen zu neuen Funktionen angezeigt werden. Um Pendo letztendlich einzusetzen, ist es notwendig sich auf der Herstellerseite zu registrieren. Im Anschluss an diese Aktion erhält man weitere Informationen zum Einsatz des Produkts[115].

5.8 Übersicht

Abbildung 21 - DevOps Tools im Zusammenhang
Abbildung 21 - DevOps Tools im Zusammenhang[65]

Insgesamt sind alle vorgestellten Tools so ausgewählt, dass sie nahtlos ineinandergreifen können. Die Abbildung 21 zeigt die Tools zum jeweiligen Prozessschritt nochmals im Überblick.

Confluence und JIRA erleichtern die Planung der Softwareprojekte. Docker und Bitbucket werden in der Entwicklung genutzt. Teamcity sorgt für die kontinuierliche Integration des entwickelten Quellcodes. Mit Octopus wird der kompilierte Quellcode auf die jeweiligen Server verteilt. Der Betrieb hat mit Hilfe von BigPanda jeder Zeit einen vollständigen Überblick über die eingesetzten Monitoring-Tools. Der unendliche DevOps-Prozess wird mit Hilfe von einer kontinuierlichen Rückmeldung mittels Pendo vollendet.

Abschließend ist noch festzuhalten, dass alle Tools nur ineinandergreifen können, wenn eine passende Technologie eingesetzt wird. Eine passende Technologie ist eine Web-Applikation auf Basis von NodeJS, da diese von allen Tools unterstützt wird.

6 Schlussbetrachtung

6.1 Fazit

DevOps wird in Deutschland und rund um den Globus immer bekannter. Immer mehr Unternehmen trauen sich das Projekt "DevOps" anzugehen. Andere hingegen schrecken noch vor der Tatsache zurück, dass die eigene IT-Abteilung komplett neu ausgerichtet werden muss[116]. Denn die Veränderung betreffen die drei große "Gestaltungsfelder der IT-Organisation: Governance, Arbeitsprozesse und Automatisierung."[117]

Die Grundlagen für eine Einführung von DevOps in Unternehmen sind durch ausreichend, qualitativ hochwertigen, Tools gegeben. Die Herausforderung für IT-Abteilungen steht in diesem Sinne auf der organisatorischen Seite. Hier muss das komplette Unternehmen mitziehen um den Veränderungsprozess möglichst einfach und schnell zu gestalten[116]. DevOps wird in vielen Entwicklungsteams "bei kleineren Projekten oder bei ad hoc benötigten Problemlösungen nach agilen Prinzipen"[118] schon angewandt. Es kommt häufig vor, dass bei kleineren Fehlern der IT-Betrieb auf den Entwickler zugeht und mit diesem eine schnelle Lösung findet[119]. "Für größere Projekte braucht es allerdings einen organisatorischen Rahmen und unterstützende Werkzeuge."[118]

Aus der Sicherheitsperspektive gibt es für das Thema DevOps geteilte Meinungen. Kritiker sehen bei unüberlegten Implementierungen "gravierende Risiken", "die möglicherweise den gesamten Geschäftsbetrieb des Unternehmens gefährden."[120] Befürworter von DevOps hingegen sehen die Sicherheitsvorteile "wie die verbesserte Kontrolle der Softwareverteilung sowie größere Nachvollziehbarkeit und erhöhte Transparenz."[120] Die Unternehmen müssen hier im Vorfeld geeignete Maßnahmen treffen, um die Vorteile von DevOps optimal nutzen zu können, ohne ein Risiko einzugehen. Bei der Einführung kann ein externer Vertreter für die Sicherheit ins Haus geholt werden [121]. "So werden Experteneinschätzungen zur Sicherheit und Compliance von Anfang an berücksichtigt und Sicherheitsrisiken sowie spätere Compliance-Probleme vermieden."[120]

6.2 Ausblick

Abbildung 22 - Häufigkeit der Suchanfragen zu "DevOps". (Quelle: Google Trends (Die Zahlen stellen das Suchinteresse relativ zum Höchstwert im Chart dar.  Diese Angaben spiegeln nicht das absolute Suchvolumen wieder)
Abbildung 22 - Häufigkeit der Suchanfragen zu "DevOps". (Quelle: Google Trends (Die Zahlen stellen das Suchinteresse relativ zum Höchstwert im Chart dar. Diese Angaben spiegeln nicht das absolute Suchvolumen wieder)[122]

Für einen Ausblick muss man nur auf Abbildung 22 schauen, um zu sehen wohin der Trend für "DevOps" geht. Die Anzahl der Suchanfragen steigt seit Jahren kontinuierlich. Durch die vielen Blogs, Talks und Konferenzen hat der Begriff "DevOps" mittlerweile einen festen Platz in der IT. "Diese Entwicklung ist nicht wirklich überraschend, denn der DevOps-Trend hat endgültig den kritischen Punkt eines typischen Hypes überschritten und setzt sich in einem selbstverstärkenden Erfolg weiter fort."[122]

"Der Bedarf an DevOps wird von der Geschwindigkeit des Marktes diktiert – Softwareentwickler müssen einfach schneller liefern, um in der heutigen Zeit profitabel zu bleiben", so Microsofts Produkt Manager Ed Blankenship im Rahmen eines Vortrags zum Thema."[123] Der Markt wird also immer schnelllebiger und flexibler. Die IT muss dieses Tempo ebenfalls halten und dabei eine Betriebsstabilität gewährleisten. "Diese Anforderungen an die IT können aber nur umgesetzt werden, wenn alle an der Wertschöpfungskette Beteiligten zusammenarbeiten."[124] Für genau diese Anforderungen steht "DevOps". Viele Startups setzen von Beginn an auf die Methode. Die größeren, bereits etablierten, Unternehmen zögern allerdings mit der Entscheidung und nehmen sich die Zeit die ersten Resultate anderer Unternehmen zu beobachten[125] . "Aber Fakt ist: Die Rahmenbedingungen, unter denen das klassische Software-Engineering entstanden sind, existieren in dieser Form nicht mehr. Trotzdem bestimmen die darauf aufbauenden veralteten Prinzipien noch immer die meisten IT-Organisationen. Die IT muss sich an die veränderten Rahmenbedingungen anpassen und DevOps ist ein wichtiger Baustein auf dem Weg dahin."[126]

7 Fußnoten

  1. 1,0 1,1 Friedrichsen & Wolf, S.10
  2. 2,0 2,1 vgl. Friedrichsen & Wolf, S.10
  3. vgl. Friedrichsen & Wolf, S. 10
  4. Friedrichsen & Wolf, S. 10f
  5. 5,0 5,1 5,2 vgl. Friedrichsen & Wolf, S. 11
  6. vgl. Hüttermann, S. 3
  7. vgl. Hüttermann, S. 4
  8. Ernest Mueller(2011)
  9. Peschlow, Abschnitt 2 (2016)
  10. vgl. Peschlow, Abschnitt 5 (2016)
  11. Peschlow, Abschnitt 5 (2016)
  12. vgl. Peschlow, Abschnitt 6 (2016)
  13. Peschlow, Abschnitt 7 (2016)
  14. Peschlow, Abschnitt 8 (2016)
  15. 15,0 15,1 15,2 15,3 15,4 15,5 vgl. Friedrichsen & Wolf, S.12
  16. vgl. Sharma, S. 9f.
  17. vgl. Hüttermann, S. 11
  18. vgl. Haddad (2014)
  19. Kim (2014)
  20. 20,0 20,1 vgl. Kim (2014)
  21. Kim (2014)
  22. Kim (2014)
  23. 23,0 23,1 23,2 23,3 vgl. Phillips (2016)
  24. vgl. Hüttermann, S. 27
  25. Hüttermann, S.27
  26. 26,0 26,1 vgl. Sharma, S. 5
  27. vgl. Sharma, S. 6
  28. 28,0 28,1 28,2 vgl. Bass,Weber, Zhu
  29. Flott (2016)
  30. Vgl. Dr. Fischer & Sommerhäuser (2016)
  31. Dr. Fischer & Sommerhäuser (2016)
  32. Vgl. Flott (2016)
  33. 33,0 33,1 Vgl. Petersen(2015)
  34. 34,0 34,1 34,2 Petersen(2015)
  35. 35,0 35,1 35,2 Vgl. Klotz(2013)
  36. 36,0 36,1 Klotz(2013)
  37. 37,0 37,1 37,2 Vgl. Wolf (2015)
  38. 38,0 38,1 38,2 Schlücker (2014)
  39. 39,0 39,1 39,2 39,3 Vgl. Schlücker (2014)
  40. 40,0 40,1 Vgl. Grebenstein(2014)
  41. Grebenstein(2014)
  42. vgl. Friedrichsen & Wolf (2015), S.12 ff.
  43. Sharma , S. 20 f.
  44. vgl. Bass, Webber & Zhu (2015), S. 26
  45. 45,0 45,1 45,2 45,3 vgl. Bass, Webber & Zhu (2015), S. 82 ff.
  46. Vgl. Hüttermann, S. 58
  47. Vgl. Hüttermann, S. 58 ff.
  48. Vgl. Hüttermann, S. 59
  49. Vgl. Hüttermann, S. 59
  50. Vgl. Linz & Spillner, S. 21 ff.
  51. Vgl. Linz & Spillner, S. 24 ff.
  52. Vgl. Linz & Spillner, S. 27 ff.
  53. Vgl. Linz & Spillner, S. 27 ff.
  54. Vgl. Linz & Spillner, S. 30 ff.
  55. Vgl. Linz & Spillner, S. 33 ff.
  56. Vgl. Bass, Weber, Zhu , S. 93 f.
  57. 57,0 57,1 Vgl. Sharma, S. 24 f.
  58. Vgl. Bass, Weber, Zhu , S. 95
  59. Vgl. Bass, Weber, Zhu , S. 96 f.
  60. Vgl. Bass, Weber, Zhu , S. 112 ff.
  61. DevOps for Developers (2012), S. 11 Figure 1-5.
  62. Vgl. DevOps for Developers (2012), "Introduction" Abs. 4
  63. 63,0 63,1 Vgl. DevOps for Developers (2012), S. 11
  64. Vgl. DevOps for Developers (2012), S. 12
  65. 65,0 65,1 Vgl. Sarah Zorah (2016)
  66. Vgl. JIRA
  67. Vgl. J. Fisher (2014), S. 1
  68. Vgl. JIRA Scrum
  69. 69,0 69,1 Vgl. JIRA Getting Started
  70. JIRA Getting Started
  71. Vgl. Confluence
  72. Vgl. Mike Gotta (2015), S. 11 f.
  73. Vgl. Confluence Pricing
  74. Vgl. Confluence Use Cases
  75. Confluence for Software Teams
  76. Vgl. Die DevOps Bewegung (2016), Abschnitt: "Was kommt mit DevOps auf uns zu?"
  77. Vgl. Golo Roden (2014)
  78. 78,0 78,1 Vgl. Docker
  79. Docker Release Note
  80. Vgl. Docker Github
  81. Container Security
  82. Vgl. Container Security, S. 3 Abschnitt: "Docker Overview" Absatz 1
  83. Vgl. DevOps for Developers (2012), S. 30
  84. Vgl. Teamcity
  85. Vgl. Manoj Mahalingam (2014), Abschnitt: "Introducation to TeamCity" Abs. 1-3
  86. Vgl. TeamCity Licence
  87. Vgl. TeamCity Virtual
  88. Vgl. Roy Thomas Fielding, Chapter 5
  89. Vgl. IntelliJ IDEA
  90. Vgl. Visual Studio
  91. Vgl. Manoj Mahalingam (2014), Abschnitt: "Features"
  92. Vgl. TeamCity Features
  93. Vgl. Octopus
  94. Vgl. Octopus Teamcity
  95. Vgl. Octopus Whitepaper, S. 2
  96. Vgl. NodeJS
  97. Vgl. Octopus NodeJS
  98. Vgl. Octopus Version
  99. Vgl. Octopus Pricing
  100. 100,0 100,1 Vgl. Octopus Whitepaper, S. 10
  101. Vgl. NuGet
  102. Tom Hall (Softwareentwickler bei der Firma Isobar), Octopus Whitepaper, S. 11
  103. vgl. Hall, S. 11
  104. Vgl. Nagios
  105. Vgl. Munin
  106. DevOps for Developers (2012), S. 45
  107. Vgl. DevOps for Dummies (2014), S. 13
  108. Vgl. BigPanda
  109. Vgl. BigPanda Gartner
  110. BigPanda Features
  111. Vgl. Nagios
  112. Vgl. Cloudwatch
  113. Vgl. BigPanda Features
  114. Vgl. Sarah Zorah (2016), Abschnitt: "6. Continuous feedback"
  115. Vgl. Pendo
  116. 116,0 116,1 Vgl. Jürgen Rühling (2013)
  117. Jürgen Rühling (2013)
  118. 118,0 118,1 Uwe Geier (2015)
  119. Vgl. Uwe Geier (2015)
  120. 120,0 120,1 120,2 Dr. Stefan Beißel (2014)
  121. Vgl. Dr. Stefan Beißel (2014)
  122. 122,0 122,1 Masroor Ahmad
  123. Verena Budde (2015)
  124. Friedrichsen & Wolf S.14
  125. Vgl. Friedrichsen & Wolf S.10 ff.
  126. Friedrichsen & Wolf S.15

8 Quellenverzeichnis & Literaturverzeichnis

  • Internetquellen
Maik Klotz http://t3n.de/news/design-thinking-6-schritten-507155/ (Aufgerufen: 22.05.2016, 15:30)
Melanie Petersen http://t3n.de/news/projektmanager-job-gehalt-658554/ (Aufgerufen: 27.05.2016, 16:10)
Karsten Flott http://www.heise.de/developer/artikel/DevOps-APM-und-der-Single-Point-of-Failure-3058558.html?artikelseite=2 (Aufgerufen 27.05.2016, 16:30)
Marcel Wolf http://www.heise.de/developer/artikel/Operations-heute-und-morgen-Teil-2-DevOps-im-Jahre-2015-2700954.html (Aufgerufen: 27.05.2016, 16:40)
Ina Schlücker http://www.it-zoom.de/it-director/e/kein-big-bang-in-der-software-entwicklung-8798/ (Aufgerufen: 24.05.2016, 14:30)
Dr. Thomas Fischer & Lea Sommerhäuser http://www.it-zoom.de/it-director/e/devops-bewegung-will-silodenken-beenden-12666/ (Aufgerufen: 27.05.2016, 13:15)
Kay Grebenstein http://www.developer-week.de/index.php/Blog/Der-agile-Testmanager-ein-Oxymoron (Aufgerufen: 27.05.2016, 16:50)
JIRA https://de.atlassian.com/software/jira (Aufgerufen am 30.05.2016, 17:45)
J. Fisher (2014) J. Fisher, D. Koning, A.P. Ludwigsen: Utilizing Atlassian Jira for large-scale development management, 2014, http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/tucobab03.pdf (Aufgerufen am 30.05.2016, 17:50)
JIRA Scrum https://de.atlassian.com/agile/scrum (Aufgerufen am 30.05.2016, 17:55)
JIRA Getting Started https://confluence.atlassian.com/jirasoftwarecloud/getting-started-with-jira-software-764477795.html (Aufgerufen am 30.05.2016, 17:44)
Confluence https://de.atlassian.com/software/confluence (Aufgerufen am 30.05.2016, 17:00)
Mike Gotta (2015) Mike Gotta, Nikos Drakos, Jeffrey Mann: Magic Quadrant for Social Software in the Workplace, 26.10.2015, https://www.gartner.com/doc/reprints?id=1-2QJAU20&ct=151027&st=sb (Aufgerufen am 30.05.2016, 18:00)
Confluence Pricing https://de.atlassian.com/software/confluence/pricing (Aufgerufen am 30.05.2016, 18:00)
Confluence Use Cases https://confluence.atlassian.com/doc/confluence-use-cases-283641068.html (Aufgerufen am 30.05.2016, 18:01)
Confluence for Software Teams https://confluence.atlassian.com/doc/confluence-for-software-teams-776656419.html (Aufgerufen am 30.05.2016, 18:02)
Die DevOps Bewegung (2016) Patrick Peschlow: Die DevOps Bewegung, Januar 2016, https://www.codecentric.de/wissen/publikationen/detail/?publikation=28575 (Aufgerufen am 30.05.2016, 18:10)
Golo Roden (2014) Golo Roden: Vagrant und Docker: Eine zeitgemäße Entwicklungsumgebung, 05.10.2014, http://www.heise.de/developer/artikel/Vagrant-und-Docker-Eine-zeitgemaesse-Entwicklungsumgebung-2411620.html (Aufgerufen am 30.05.2016, 18:10)
Docker https://www.docker.com (Aufgerufen am 30.05.2016, 18:15)
Docker Release Note https://docs.docker.com/v1.4/release-notes/ (Aufgerufen am 27.05.2016, 20:01)
Docker Github https://github.com/docker/docker/ (Aufgerufen am 27.05.2016, 20:20)
Container Security Whitepaper, 18.03.2015, https://www.docker.com/sites/default/files/WP_Intro%20to%20container%20security_03.20.2015%20(1).pdf (Aufgerufen am 30.05.2016, 18:20)
Teamcity https://www.jetbrains.com/teamcity/ (Aufgerufen am 30.05.2016, 18:25)
TeamCity Licence https://www.jetbrains.com/teamcity/buy/#license-type=new-license (Aufgerufen am 30.05.2016, 19:00)
TeamCity Virtual https://github.com/jonnyzzz/TeamCity.Virtual (Aufgerufen am 30.05.2016, 19:01)
TeamCity Features https://www.jetbrains.com/teamcity/features/ (Aufgerufen am 30.05.2016, 19:05)
Octopus https://octopus.com/ (Aufgerufen am 30.05.2016, 19:20)
Octopus Teamcity http://docs.octopusdeploy.com/display/OD/TeamCity (Aufgerufen am 30.05.2016, 17:29)
Octopus Whitepaper http://download.octopusdeploy.com/files/whitepaper-automated-deployment-octopus-deploy.pdf (Aufgerufen am 30.05.2016, 19:07)
Octopus NodeJS http://docs.octopusdeploy.com/pages/viewpage.action?pageId=3049551 (Aufgerufen am 30.05.2016, 19:08)
Octopus Version https://octopus.com/blog/octopus-deploy-3.4-eap (Aufgerufen am 30.05.2016, 19:10)
Octopus Pricing https://octopus.com/purchase (Aufgerufen am 30.05.2016, 19:11)
BigPanda https://www.bigpanda.io (Aufgerufen am 30.05.2016, 19:19)
BigPanda Gartner Joe Schwartz: Gartner Names BigPanda a 2016 ‘Cool Vendor’ in Availability and Performance, 05.05.2016, https://bigpanda.io/2016-05-05-bigpanda-gartner-cool-vendor (Aufgerufen am 30.05.2016, 19:25)
BigPanda Features https://www.bigpanda.io/features (Aufgerufen am 30.05.2016, 19:45)
Sarah Zorah (2016) Sarah Zorah: How to choose the right DevOps tools, 31.03.2016, http://blogs.atlassian.com/2016/03/how-to-choose-devops-tools/ (Aufgerufen am 30.05.2016, 19:50)
Pendo http://www.pendo.io/ (Aufgerufen am 30.05.2016, 19:55)
Ernest Mueller The Agile Admin: What is DevOps, 2011, https://theagileadmin.com/what-is-devops/ (Aufgerufen 25.05.2016, 15:13)
Chris Haddad DevOps = DevOps Principles + DevOps Practices, 2014, https://dzone.com/articles/devops-devops-principles (Aufgerufen 25.05.2016 16:52)
Gene Kim The Three Ways: The Principles Underpinning DevOps, 2014, http://itrevolution.com/the-three-ways-principles-underpinning-devops/ (Aufgerufen 25.05.2016 17:02)
Andrew Phillips How to get DevOps right, 2016, http://www.networkworld.com/article/3029638/application-development/how-to-get-devops-right.html (Aufgerufen 25.05.2016 22:01)
Verena Budde http://de.dice.com/nachrichten/devops-loesungen-als-neues-allheilmittel-eine-zwischenbilanz/ (Aufgerufen: 01.06.2016, 17:15)
Dr. Stefan Beißel https://www.kes.info/archiv/leseproben/2014/devops/ (Aufgerufen: 01.06.2016, 18:00)
Jürgen Rühling http://www.heise.de/developer/artikel/DevOps-in-Unternehmen-etablieren-2061738.html?artikelseite=4 (Aufgerufen: 01.06.2016, 18:30)
Uwe Geier http://www.heise.de/developer/artikel/DevOps-in-der-Praxis-2796388.html (Aufgerufen: 01.06.2016, 17:30)
Roy Thomas Fielding Roy Thomas Fielding: Architectural Styles and the Design of Network-based Software Architectures, https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf (Aufgerufen: 02.06.2016, 16:00)
IntelliJ IDEA https://www.jetbrains.com/idea/ (Aufgerufen: 02.06.2016, 16:05)
Visual Studio https://www.visualstudio.com/ (Aufgerufen: 02.06.2016, 16:06)
NodeJS https://nodejs.org/en/ (Aufgerufen: 02.06.2016, 16:14)
NuGet https://www.nuget.org/ (Aufgerufen: 02.06.2016, 16:16)
Nagios https://www.nagios.org/ (Aufgerufen: 02.06.2016, 16:18)
Munin http://munin-monitoring.org/ (Aufgerufen: 02.06.2016, 16:20)
Cloudwatch https://aws.amazon.com/de/cloudwatch/ (Aufgerufen: 02.06.2016, 16:20)
  • Literatur
DevOps for Developers (2012) Michael Hüttermann: DevOps for Developers; Auflage von 2012 (13. September 2012); Apress Verlag
Manoj Mahalingam (2014) Manoj Mahalingam S: Learning Continuous Integration with TeamCity; Auflage vom 26.08.2014; Packt Publishing
DevOps for Dummies (2014) Sanjeev Sharma: DevOps for Dummies, IBM Limited Edition; Auflage 2014; John Wiley & Sons, Inc. (111 River St., Hoboken, NJ 07030-5774)
Basiswissen Softwaretest (2012) Andreas Spillner, Tilo Linz: Basiswissen Softwaretest ; Auflage 2014; dpunkt.verlag
Die Reise nach DevOps (2012) Uwe Friedrichsen, Marcel Wolf: Die Reise nach DevOps: Auf dem Weg zu einer bedarfsgerechten IT; Auflage 2015; SIGS DATACOM GmbH (Lindlaustraße 2c, 53842 Troisdorf)
DevOps: A Software Architect's Perspective (2015) Len Bass, Ingo Weber, Liming Zhu; Verlag: Addison Wesley; Auflage: 01 (18. Mai 2015) ISBN-10: 0134049845

9 Abkürzungsverzeichnis

AbkürzungBedeutung
RoI Return on Investment

10 Abbildungsverzeichnis

Abb.-Nr.KapitelAbbildung
1 2.1 Von der Softwarekrise zu DevOps
2 2.4 Weg 1: Betrachtung der ganzen Wertschöpfungskette
3 2.4 Weg 2: Feedback wird in den Prozess aufgenommen
4 2.4 Weg 3: kontinuierliches Experimentieren
5 2.6 Aufbau von Fachwissen der anderen Teams
6 3.1 Aufbau eines DevOps-Teams
7 3.2 Ziele eines Projektmanagers
8 3.3 Design Thinking
9 3.5 Qualitätsmanagement Ebenen Selbst erstellt
10 4.1 DevOps Lebenszyklus vgl. DevOps for Dummies S.
11 4.2Prozessschritte von Entwurf und Design (Selbst erstellt)
12 4.3.1Prozessschritte Entwicklung (Selbst erstellt)
13 4.3.3 Fundamentaler Testprozess Andreas Spillner & Tilo Linz, vgl. Basiswissen Softwaretest S.21
14 4.4.1Deployment Stationen vgl. DevOps for Dummies S.
15 5.1DevOps ist nicht eine einzige "Tool-Suite"
16 5.1DevOps Prozess als unendlicher Zyklus
17 5.2Worklow in JIRA Software
18 5.3Docker Architektur
19 5.5Funktionsweise Octopus Deploy
20 5.6BigPanda
21 5.8DevOps Tools im Zusammenhang
22 6.2Häufigkeit der Suchanfragen zu "DevOps"
Persönliche Werkzeuge