Grundlagen von DevOps

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.

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.

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.

Definition DevOps

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]

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].

Der Beitrag steht im Original auf Winfwiki zur Verfügung http://winfwiki.wi-fom.de/index.php/Grundlagen_von_DevOps

Quellen:

1,0 1,1 Friedrichsen & Wolf, S.10
2,0 2,1 vgl. Friedrichsen & Wolf, S.10
vgl. Friedrichsen & Wolf, S. 10
Friedrichsen & Wolf, S. 10f
5,0 5,1 5,2 vgl. Friedrichsen & Wolf, S. 11

Bildquelle / Lizenz: