Wie Sie DevOps für Ihr Unternehmen nutzen

DevOps hilft Unternehmen dabei, leistungsfähige End-to-End-Geschäftslösungen zu entwickeln. Die Besonderheit: Development und Betrieb arbeiten eng zusammen, um durch fortlaufendes Testing Fehlentwicklungen zu vermeiden. Erfahren Sie, welche Methoden DevOps im Detail auszeichnen und wie eine DevOps-Pipeline aufgebaut ist.

Definition: Was ist DevOps?

DevOps ist ein Ansatz zur Prozessoptimierung in der Software-Entwicklung. Er zielt darauf, Entwicklung und Betrieb stärker zu verzahnen, um eine bessere Zusammenarbeit zu erreichen. DevOps ist ein sogenanntes Kofferwort, welches sich aus den englischen Begriffen „Development“ und „Operations“ zusammensetzt.

Traditionell arbeiten Entwicklungsteams und Betriebsteams isoliert voneinander. Dieses Silodenken resultiert häufig in langen Software-Entwicklungszyklen, weil Anwendungen erst am Reißbrett entworfen und entwickelt werden, bevor sie in den Praxiseinsatz überführt werden. Stellt sich im operativen Betrieb dann heraus, dass die Software den Alltagsanforderungen nicht genügt, wird sie an die Entwicklung zurückgegeben und der Prozess beginnt von vorne. Das ist umständlich und verursacht hohe Kosten.

Diese Isolation betrifft nicht nur die organisatorische und zeitliche Abfolge bei der Software-Entwicklung. Sie ist auch räumlich zu verstehen, weil sich Entwicklungs- und Betriebsteams häufig auf separaten Etagen oder sogar in unterschiedlichen Gebäuden auf dem Firmengelände befinden. Diese Trennung vergrößert den Graben zwischen denjenigen, die den Code schreiben, und denjenigen, die ihn im Unternehmen zur Verfügung stellen.

Im Gegensatz dazu arbeiten bei einem DevOps-Modell das Entwicklungs- und das Betriebsteam über den gesamten Lebenszyklus der Anwendung hinweg zusammen. Das reicht von der Konzeption über die Erstellung eines „Minimum Viable Products“ (MVP) bis hin zum Rollout. Dabei rücken die beiden Teams nicht nur organisatorisch, sondern auch räumlich enger zusammen. Häufig teilen sie sich nun dieselbe Etage im Unternehmen. Das Resultat – Software kann schneller und zielführender entwickelt, getestet und freigegeben werden.

DevOps als Philosophie für die Software-Entwicklung kam zwischen 2007 und 2008 auf. Vordenker der DevOps-Bewegung sind John Allspaw, Paul Hammond und Patrick Debois. Verschiedene Publikationen verhalfen dem Thema zu mehr Bekanntheit. Zu den Klassikern zählen „Implementing Lean Software Development“ (2006) von Mary und Tom Poppendiek, „Continuous Delivery“ (2010) von Jez Humble und David Farley sowie „The Phoenix Project“ (2013) von Gene Kim, Kevin Behr und George Spafford.

Mittlerweile arbeiten mehrere große Unternehmen unter Verwendung der DevOps-Philosophie. Dazu zählen Amazon, Netflix, Adobe und Walmart.

Welche Methoden es gibt

DevOps zeichnet sich durch bestimmte Methoden aus. Einige der wichtigsten möchten wir Ihnen im Folgenden vorstellen.

Continuous Integration

Continuous Integration bedeutet, dass die einzelnen Elemente einer Anwendung fortlaufend in einem zentralen Repository zusammengeführt werden. Diese Elemente werden automatisch erstellt und getestet. Auf diese Weise wird das harmonische Zusammenspiel der einzelnen Bestandteile sichergestellt. Bugs werden frühzeitig entdeckt, statt sich langfristig unkorrigiert aufzustauen. Außerdem trägt die kontinuierliche Integration dazu bei, Software-Aktualisierungen zeitsparender durchzuführen. Das ist ein Vorteil für den Kunden, der schneller Zugriff auf Aktualisierungen erhält.

Continuous Delivery

Continuous Delivery ist die konsequente Fortsetzung von Continuous Integration. Hier werden nun alle Codeänderungen in eine Test- bzw. Staging-Umgebung übertragen. Es werden weiterführende automatisierte Tests durchgeführt, wie UI-, Last- und Integrationstests. Auf diese Weise steht den Entwicklern stets ein Erstellungsartefakt für die Bereitstellung zur Verfügung, welches bereits einen Testprozess durchlaufen hat.

Continuous Deployment

Während bei der Continuous Delivery eine manuelle Genehmigung notwendig ist, wird die Produktion beim Continuous Deployment automatisch aktualisiert. Beide Vorgehensweisen haben ihre Vor- und Nachteile, wie wir später im Zusammenhang mit der DevOps-Pipeline sehen werden.

Continuous Monitoring

Continuous Monitoring findet normalerweise am Ende eines DevOps-Zyklus statt, nachdem der Build bereits in die Produktion gegangen ist. Die automatischen Continuous-Monitoring-Systeme erheben wichtige Betriebsdaten in Echtzeit. Taucht ein Problem auf, alarmiert das System das zuständige Team, sodass dieses zeitnah eine Lösung entwickeln kann.

Infrastructure as Code (IaC)

Infrastructure as Code ( IaC) bedeutet, dass die Konfiguration der Systeme analog zur Programmierung von Software geschieht. Der verwendete Technologie-Stack wird automatisch über eine Anwendung bereitgestellt. Es wird also kein manueller Prozess zur Konfiguration diskreter Hardware-Geräte benötigt. Deswegen spricht man auch von programmierbarer Infrastruktur.

Infrastructure as Code trägt dazu bei, Hardware-Ressourcen zuverlässig und wiederholbar zur Verfügung zu stellen. Beispielsweise können Systemumgebungen in verschiedenen Versionen gespeichert werden. Das ist praktisch, um Neuentwicklungen in verschiedenen Testumgebungen zu überprüfen.

DevOps vs. Agile

DevOps und agiles Arbeiten werden oft im selben Atemzug genannt, wenn es um moderne Formen der Software-Entwicklung geht. Auch wenn sich die beiden Ansätze in einigen Punkten ähneln, gibt es doch Unterschiede. Die folgende Tabelle verschafft Ihnen einen Überblick.

Es ist jedoch keineswegs so, dass sich DevOps und Agile gegenseitig ausschließen. Im Gegenteil können sie sich innerhalb eines Unternehmens gut ergänzen. Agile kann beispielsweise in die Entwicklungsphase des DevOps-Zyklus integriert werden, um noch schneller neue Software-Features umzusetzen.

Die 8 Phasen einer DevOps-Pipeline

Für ein DevOps-Projekt werden typischerweise acht Phasen durchlaufen:

1. Planungsphase
2. Coding-Phase
3. Erstellungsphase
4. Testphase
5. Veröffentlichungsphase
6. Produktionsphase
7. Betriebsphase
8. Monitoring-Phase

Zusammengenommen ergeben diese Phasen eine sogenannte DevOps-Pipeline. Man kann sich diese wie eine Montagestrecke in einem Automobilwerk vorstellen. Hier wie dort muss das Produkt zuerst konzipiert, dann aus bestimmten Einzelteilen zusammengestellt und schließlich getestet und in Betrieb genommen werden.

Die genannten Phasen bauen aufeinander auf und sind nicht rollenspezifisch. Das bedeutet, dass jedes Teammitglied grundsätzlich an jeder Phase beteiligt ist. Es müssen auch nicht immer alle acht Phasen für jeden Entwicklungsprozess berücksichtigt werden. Die Anzahl und die Zusammenstellung der Phasen können je nach Projekt und nach Organisation variieren.

Im Folgenden stellen wir Ihnen die einzelnen Phasen im Detail vor.

1. Planungsphase

Die Planungsphase umfasst alle Vorbereitungen, damit die Entwickler mit dem Schreiben des Codes beginnen können. Der erste Schritt besteht darin, Kunden und andere Stakeholder zu interviewen. Was sind ihre Anforderungen an das geplante Produkt? Welche Features wünschen sie sich? Dieses Feedback wird dann zu einer sogenannten Product Roadmap verarbeitet. Unter Verwendung von Projektmanagement-Software wie Asana oder Jira wird diese Roadmap in Phasen und Milestones untergliedert. Weitere typische Elemente sind Epics (Beschreibungen von Anforderungen), Features (Funktionalitäten) und User-Stories (Mehrwert-Beschreibungen).

Anschließend werden die Roadmap-Elemente in einen Backlog von Aufgaben übersetzt, welche vom Team verarbeitet werden können. Diese können nun wiederum für die Planung von Sprints verwendet werden, also der Durchführung von intensiven, zeitlich begrenzten Entwicklungsphasen.

Grundsätzlich wirken alle Teammitglieder an der Erstellung dieses Plans mit; es sind jedoch besonders der Product Manager bzw. der Projektmanager, die hier gefragt sind.

2. Coding-Phase

In dieser Phase werden von den Entwicklern erste Code-Bestandteile geschrieben. Dies geschieht unter Verwendung von klassischer Entwicklungs-Software oder auch mithilfe von cloudbasierten Entwicklungsumgebungen. Diese Platform-as-a-Service-Lösungen vereinfachen die Kollaboration, insbesondere für geographisch verteilte Remote Teams.

Für den Erfolg der Coding-Phase ist es wichtig, dass teamübergreifend ein einheitlicher Coding-Stil angewendet wird. Außerdem sollte von Anfang an darauf geachtet werden, Sicherheitslücken zu schließen. Und nicht zuletzt sollten sogenannte Anti-Pattern vermieden werden, wie aufgeblähter Code.

3. Erstellungsphase

Hat ein Entwickler seine zugewiesene Aufgabe erledigt, wird sein Code in ein zentrales Repository überführt. Dafür stellt er einen sogenannten Pull Request, also eine Anfrage, den eigenen Code mit dem Gruppen-Code zu vereinen. Bevor dies geschieht, nimmt ein anderer Entwickler das neue Element genau unter die Lupe, um dessen Funktionsfähigkeit sicherzustellen. Der Fokus dieser Überprüfung liegt auf dem neuen Element selbst.

Parallel dazu wird durch den Pull Request ein automatischer Testprozess in Gang gesetzt, der stärker die globale Perspektive betrachtet. Hierfür wird testweise eine gemeinsame Codebasis erzeugt. Durch diese abgesicherte Integration wird das Zusammenspiel von bisherigem Code und dem neuen Element überprüft. Scheitert der Test, wird der betreffende Entwickler benachrichtigt, um nachzubessern.

Es ist diese Erstellungsphase, in welcher DevOps wirklich zum Tragen kommt. Indem neue Code-Bestandteile fortlaufend auf ihre Kompatibilität mit dem gemeinsamen Code-Repository überprüft werden, können Integrationsprobleme schon im Ansatz erkannt und behoben werden. Es kommt also nie Panik kurz vor Abschluss des Projekts auf, wenn sich herausstellt, dass etwas nicht wie vorgesehen funktioniert.

4. Testphase

Die bisher genannten Testdurchläufe sind jedoch nur der Anfang. Liegt ein erster Build vor, wird dieser in eine sogenannte Staging-Umgebung überführt. Hier werden nun weitreichendere Tests initiiert. Bei der Staging-Umgebung kann es sich beispielsweise um eine existierende Hosting-Umgebung handeln. Aber auch eine extra für den Entwicklungsprozess angelegte Umgebung ist möglich. Hier kommen die oben genannten Vorteile von Infrastructure as Code zum Tragen. Durch die Behandlung von Hardware als Software lassen sich leicht verschiedene Umgebungen erzeugen, zum Beispiel unter Verwendung von Virtual Machines.

Was nun folgt, ist eine Serie von Belastungsproben. Hierbei kommen durchaus auch manuelle Verfahren zum Einsatz, wie das User Acceptance Testing (UAT). Dafür verwenden die Test-User die geplante Software genauso, wie es der Endkunde tun würde, um Probleme aufzudecken.

Parallel dazu werden eine Vielzahl von automatisierten Tests durchgeführt, unter anderem:

• Tests, um den Effekt von früher vorgenommenen Änderungen zu überprüfen
• Tests zum Aufspüren von Sicherheitslücken, um die Gefahr von Cyberangriffen zu minimieren
• Tests, um die Performance der Anwendung zu überprüfen (Ladezeit, Latenz, Stabilität etc.)
• Tests, um die Belastbarkeit der Software einzuschätzen, zum Beispiel im Parallelbetrieb mit anderen Anwendungen

Verlaufen alle diese Tests zufriedenstellend, kann das DevOps-Team mit hoher Wahrscheinlichkeit davon ausgehen, dass der Build keine weitreichenden Bugs aufweist.

5. Veröffentlichungsphase

Diese Phase markiert einen Wendepunkt. Der Build ist bereit, um in die Produktivumgebung überführt zu werden.

Hier gibt es zwei Vorgehensweisen, den automatischen und den manuellen Einrichtungsprozess, zwischen denen sich die Macher in dieser Phase zu entscheiden haben.

Ein automatisches Deployment bietet sich vor allem für Organisationen an, die bereits über fest verankerte DevOps-Strukturen verfügen. Entwickler haben hier die Möglichkeit, neue Features zunächst zu verbergen, sodass der Kunde sie nicht sehen kann. Erst wenn diese wirklich einsatzbereit sind, werden sie dann auch sichtbar gemacht. Auf diese Weise können Software-Unternehmen in kurzer Abfolge mehrere aufwendige neue Features publik machen. Das wirkt sich positiv auf das Marketing aus.

Aber auch das manuelle Deployment hat seine Vorteile. Die veröffentlichende Instanz behält mehr Kontrolle über das Software-Produkt. Das bedeutet, dass nur bestimmte Entscheidungsträger autorisiert sind, den jeweiligen Release zu veranlassen. So könnte es gewünscht sein, dass ausgesuchte Features erst dann veröffentlicht werden, wenn ein bestimmter Milestone erreicht ist, wie eine Mindestanzahl von Usern. Hier kann granularer auf Marktveränderungen reagiert werden, als das beim automatisierten Release der Fall ist.

6. Produktionsphase

Der fertige Build wird nun in die Produktion gegeben. Auch hier kommt wieder Infrastructure as Code zum Einsatz, um analog zu den früheren Testumgebungen eine Produktivumgebung zu erstellen. Ist diese bereits, werden alle bisherigen Anfragen durch den Hosting-Service an die neue Umgebung umgeleitet. Sollte zu irgendeinem Zeitpunkt ein Problem auftreten, kann die Umleitung zurückverlegt werden, bis das Problem behoben ist. Man spricht hier von einem sogenannten Blue-Green-Ansatz.

7. Betriebsphase

Die neue Anwendung ist live und die User können auf sie zugreifen. In dieser Phase ist besonders das Operations-Team gefragt, um einen stabilen, reibungsfreien Betrieb sicherzustellen. Von Vorteil ist, dass die Anwendung automatisch mitskaliert. Steigt die Anzahl der User oder ergeben sich zu bestimmten Tageszeiten Lastspitzen, „zieht“ sich das Programm automatisch mehr Ressourcen.

In dieser Phase sollte außerdem darauf geachtet werden, das Feedback der User einzuholen. Selbst die besten Entwickler können nicht genau vorhersagen, was sich der Anwender im Detail wünscht. Durch die Erhebung von Feedback, das dann in zukünftige Versionen der Software eingearbeitet wird, lässt sich dieses Problem beheben.

8. Monitoring-Phase

In der letzten Phase des DevOps-Zyklus geht es darum, Finetuning zu betreiben. Dies geschieht, indem unter Verwendung von Analytics Daten erhoben werden. Die Daten betreffen das Nutzerverhalten, die Performance der Anwendung, häufige Fehlermeldungen usw.

Außerdem ist nun ein guter Zeitpunkt, um den DevOps-Prozess Revue passieren zu lassen. Gab es an irgendeiner Stelle Bottlenecks, welche die Produktivität beeinträchtigten? Und wie können wir diese für den nächsten Produktionszyklus ausräumen? Alle diese Informationen und Einsichten werden dann an den Product Manager zurückgespielt, der sie für den nächsten Durchlauf berücksichtigt.

Vorteile

DevOps bietet Unternehmen zahlreiche Vorteile gegenüber klassischen Entwicklungsansätzen.

Mehr Agilität

Durch DevOps lassen sich Entwicklungsprozesse wesentlich beschleunigen, sodass schneller auf Marktveränderungen reagiert werden kann. Hiervon profitieren auch Ihre Kunden, indem sich die Time-to-Market verkürzt. Insgesamt erhöht das die Agilität Ihrer Organisation.

Mehr Eigenverantwortung

Mit DevOps-Konzepten werden Ihre Teams in die Lage versetzt, Softwareprojekte in vollständiger Eigenverantwortung abzuwickeln. Auf diese Weise sparen Sie sich nicht nur Zeit, weil Sie Ihre Mitarbeitenden nicht ständig mikromanagen müssen; Sie erhöhen auch die Zufriedenheit, weil sich Ihre Teammitglieder ernst genommen fühlen.

Mehr Praxistauglichkeit

DevOps arbeitet unter Verwendung kurzer Feedback-Zyklen. Neue, von Usern gewünschte Funktionen werden rasch hinzugefügt; Bugs werden umgehend behoben. Durch diese rapiden Iterationen passt sich die Software schnell den tatsächlichen Alltagsanforderungen der Anwender an. Das resultiert in mehr Praxistauglichkeit.

Mehr Stabilität

Methoden wie Continuous Integration und Continuous Delivery tragen dazu bei, die Stabilität von Neuentwicklungen zu erhöhen. Jede Änderung an der Software wird in Echtzeit auf ihre Funktionalität überprüft. Das trägt wesentlich zu einer positiven User-Erfahrung bei.

Mehr Skalierbarkeit

Weil DevOps auf konsistente Prozesse und Automatisierung setzt, können Sie Ihre Systeme flexibel skalieren. Das betrifft sowohl die Infrastruktur als auch die Bereitstellung. Besonders profitieren davon Unternehmen in Wachstumsbranchen. Nicht nur, dass die Entwicklungs-, Test- und Produktivumgebungen mitwachsen; auch das Risiko wird gering gehalten, indem sich der Ausbau an der tatsächlichen Unternehmensgröße orientiert.

Mehr Kollaboration

Bei DevOps arbeiten das Entwicklungsteam und das Operations-Team eng zusammen. Sie nutzen kombinierte Workflows und übernehmen gemeinsam Verantwortung für Projekte und Outcomes. Ein Beispiel dafür ist die Erstellung von Code, der bereits für die Umgebung optimiert ist, in welcher er ausgeführt wird. Durch die enge Verzahnung der Teams wird außerdem die Anzahl der benötigten Übergaben reduziert.

Mehr Motivation

Die DevOps-Kultur überträgt ein hohes Maß an Eigenverantwortung an die beteiligten Teammitglieder. Mitarbeitende schätzen diese weitgehenden Befugnisse, bringen sich stärker ein als bisher und erleben insgesamt mehr Motivation bei der Arbeit.

Mehr Sicherheit

Ein wesentlicher Bestandteil jeder modernen IT-Strategie ist die Einhaltung der IT-Compliance. DevOps bietet hier zahlreiche Lösungen an, wie automatisierte Compliance-Prozesse, granulare Steuerungsroutinen und Tools zur Konfigurationsverwaltung. Indem Richtlinien so in Code übersetzt werden, erreichen Sie eine bessere Erfüllung der IT-Compliance.