DevOps für Dummies

Emily Freeman

• Verlag: Wiley-VCH
• Jahr: 2019
• ISBN drucken: 9783527716241
• eBook-ISBN: 9783527823192
• Auflage: 1
• Thema: Computer Science
• Thema: Project Management

Arbeiten auch Sie nach DevOps-Prinzipien? Sollen oder wollen Sie umstellen? Was ist wichtig? Worauf kommt es an? Das Ziel von DevOps ist, dass Softwareentwicklung und IT-Auslieferung Hand in Hand arbeiten. Das ermöglicht schnellere Release-Zyklen und schont die Ressourcen. Wie das im Einzelnen geht, zeigt dieses Buch. Es stellt eine Roadmap für die Umstellung zur Verfügung, nennt notwendige Management- und Technologie-Entscheidungen und -Tools und scheut auch nicht davor zurück, notwendige Unternehmenskulturänderungen zu benennen, damit der Sprung ins DevOps-Gewässer gelingt.

Teil II

Eine Pipeline einrichten

IN DIESEM TEIL …

• Den Softwareentwicklungslebenszyklus als linearen Prozess betrachten
• Alle Personen an den Planungstisch einladen
• Ihr System so gestalten, dass es flexibel und belastbar ist
• Designentscheidungen während der Arbeit dokumentieren
• Sprachen, Frameworks und Programmiermuster wählen
• Tests aller Art automatisieren
• CI/CD und kleinteilige Deployment-Strategien

Kapitel 6

Den neuen Entwicklungslebenszyklus übernehmen

IN DIESEM KAPITEL

• Die Schritte im Entwicklungslebenszyklus verstehen
• Administrative Aufgaben im Entwicklungszyklus »nach links« schieben

In diesem Kapitel beschreibe ich das, was oft als Softwareentwicklungslebenszyklus oder Pipeline bezeichnet wird. Obwohl zwischen den beiden Konzepten einige feine Unterschiede bestehen können (je nachdem, mit wem Sie darüber sprechen) verwende ich die Begriffe Entwicklungslebenszyklus und Entwicklungspipeline synonym.

Die Tech-Branche verwendet den Begriff Software Development Life Cycle (SDLC), um den Prozess von der Ideenfindung für ein neues Produkt, eine neue Anwendung oder ein neues Feature bis hin zur tatsächlichen Bereitstellung der neuen Software beim Kunden in einer Produktionsumgebung zu beschreiben. Ich spreche eigentlich lieber von Delivery als von Development, weil dieser Begriff jede Andeutung vermeidet, dass Entwickler die Stars im Softwarelebenszyklus wären, was die unseligen alten Konzepte von Silos und Trennlinien zwischen Entwicklern und Ops-Leuten verstärken würde.

Es gibt viele Iterationen des Entwicklungslebenszyklus mit verschiedenen Schritten. Einige davon umfassen mehr Schritte als meine, andere wiederum weniger. In diesem Kapitel erkläre ich, wie DevOps den Ansatz des Entwicklungslebenszyklus beeinflusst. Ich erkläre auch kurz die unterschiedlichen Phasen dieses Lebenszyklus, denen in diesem Buchteil jeweils noch ein eigenes Kapitel gewidmet ist.

Alle an einen Tisch bitten

Der wichtigste Zweck bei der Ausarbeitung des Entwicklungsprozesses ist die Bereitstellung eines Rahmens, in dem alle arbeiten können. Ihre Entwickler passen vielleicht nicht perfekt in eine Phase der Pipeline und erledigen nur ein wenig Arbeit; in diesem Szenario würden nur weitere Silos entstehen, wobei die Entwickler in einem Abschnitt einfach ihren Job erledigen und dann zum nächsten übergehen. Das ist genau das Gegenteil von dem, was Sie erreichen wollen.

Stattdessen erstellen Sie ein Erfolgsrezept für Ihr Team: eine Möglichkeit, den Entwicklungsprozess wie einen Algorithmus – oder ein Kochrezept – so aufzuschlüsseln, dass jeder versteht, wie Ihr Unternehmen und Ihre DevOps-Kultur die beste Software entwickelt und diese schnell und zuverlässig an Ihre Kunden liefert.

Dieses Pipeline-Framework, das Sie entwickeln werden, ist ein Verfahren, durch das all Ihre Entwickler neue Fähigkeiten erlernen und in verschiedenen Phasen einsteigen können. Der wichtigste Vorteil der Entwicklungspipeline ist, dass sie alle zum Mitmachen einlädt. Jeder bekommt die Möglichkeit, sich nach eigenem Ermessen zu engagieren und bei Interesse neue Fähigkeiten zu erlernen. Sie sorgt auch dafür, dass Ihr Team eine gemeinsame Sprache spricht. Sie können dieselben Konzepte mit denselben Worten diskutieren, und das ist entscheidend für eine reibungslose Kommunikation.

Abbildung 6.1 zeigt einen typischen DevOps-Softwareentwicklungslebenszyklus.

Abbildung 6.1: Die DevOps-Toolchain

Prozesse umwandeln: Von der Linie zum Kreis

Entwicklungsprozesse haben sich in den letzten Jahrzehnten aus gutem Grund radikal verändert. In den 1960er Jahren leitete Margaret Hamilton das Entwicklerteam, das die Software für die Mission Apollo 11 entwickelte. Man schießt Menschen nicht iterativ in den Weltraum – zumindest nicht in den 1960er Jahren. Das ist kein Softwarebereich, in dem sich »fail fast« als Ansatz der Wahl aufdrängt. Es geht um Leben, und nicht zu vergessen um Milliarden von Dollar.

Hamilton und ihre Kollegen mussten Software nach der Wasserfallmethode entwickeln. Abbildung 6.2 zeigt ein Beispiel für einen Wasserfall-Entwicklungsprozess (der geradlinig verläuft), und Abbildung 6.3 fügt die Phasen hinzu. Beachten Sie, dass alle Pfeile in eine Richtung zeigen. Sie markieren einen klaren Anfang und ein klares Ende. Wenn Sie fertig sind, sind Sie fertig. Oder?

Abbildung 6.2: Lineare Wasserfallentwicklung

Abbildung 6.3: Die Wasserfall-Entwicklungspipeline

Nein. So sehr die meisten Leute gerne Abstand von Teilen ihrer Codebasis nehmen würden, so selten bekommen sie dieses Privileg in der Regel.

Die von Hamilton und ihrem Team entwickelte Software war ein durchschlagender Erfolg (ich finde es immer noch unglaublich, dass sie in Assembler und ohne Hilfsmittel wie Fehlermeldungen gearbeitet haben). Aber nicht alle Projekte waren ebenso erfolgreich. Später, als der Wasserfall versagte, war Agile erfolgreich. (Wie in Kapitel 1 erwähnt, entstand DevOps aus der Agile-Bewegung heraus.) Agile versucht, die gerade Linie des Wasserfalls zu einem Kreis zu biegen. So entsteht ein endloser Kreislauf, durch den sich Ihr Entwicklungsteam iterativ und kontinuierlich verbessern kann. Abbildung 6.4 zeigt, wie Sie sich den zirkulären Entwicklungslebenszyklus vorstellen können.

Abbildung 6.4: Ein zirkulärer Entwicklungslebenszyklus

Häufig werden die verschiedenen Schleifen durch die Produkte beeinflusst, die bestimmte Anbieter verkaufen. Wenn der Anbieter beispielsweise Infrastruktursoftware und -werkzeuge verkauft, betont er wahrscheinlich diesen Teil des Entwicklungslebenszyklus, vielleicht mit Schwerpunkt auf Bereitstellung, Überwachung und Wartung Ihrer Software.

Ich möchte Ihnen nichts verkaufen. Die Phasen, auf die ich mich konzentriere, sind aus meiner Entwicklersicht die entscheidenden. Dazu kommen noch jene, die den Leuten am meisten Schwierigkeiten bereiten, wenn ich Unternehmen darin unterrichte, ihre Softwareentwicklung besser zu verwalten und DevOps einzusetzen.

Die fünf Phasen des Softwareentwicklungslebenszyklus, um die es in diesem Teil des Buchs geht, sind:

• Planung: Die Planungsphase Ihres DevOps-Entwicklungsprozesses ist vielleicht der Schlüssel zu Ihrer DevOps-Mission. Sie stellt die Weichen für Ihren zukünftigen Erfolg oder Misserfolg. Dies ist auch die günstigste Zeit, um alle zusammenzubringen, also Stakeholder, Vertrieb und Marketing, Technik, Produktion und andere. In Kapitel 7 geht es um die Planungsphase.
• Design: In den meisten Unternehmen vermischen sich die Entwurfs- und die Programmierphase. Diese monströse Vermischung von Design und Code lässt dann keine Trennung der Architekturstrategie von der Umsetzung mehr zu. Wenn Sie aber Entscheidungen zu Datenbankdesign, API-Logistik und wichtiger Infrastruktur erst am Ende der Entwicklungspipeline treffen – oder sie, was vielleicht noch schlimmer ist, den einzelnen Entwicklern, die an separaten Funktionen arbeiten, überlassen, werden Sie schnell feststellen, dass Ihre Codebasis genauso siloisiert ist wie Ihr Entwicklungsteam. Kapitel 8 behandelt die Entwurfsphase.
• Programmierung: Die eigentliche Entwicklung von Features steht im Rampenlicht des Prozesses und genießt die ganze Ehre. Meiner Meinung nach ist dies jedoch einer der unwesentlichsten Schritte im Entwicklungslebenszyklus. In vielerlei Hinsicht handelt es sich einfach nur um die Ausführung der vorangehenden Abschnitte Ihrer Pipeline. Wenn die gelungen ist, sollte die Programmierung ein relativ einfacher und unkomplizierter Vorgang sein.
  Wenn Sie selbst Entwickler sind und beim letzten Satz nach Luft geschnappt haben, weil Sie es mit Hunderten von willkürlichen und schwer zu behebenden Bugs zu tun hatten, dann kann ich Ihnen das sehr gut nachfühlen. Programmieren ist ein hartes Geschäft. Nichts an der Softwareentwicklung ist einfach. Aber wenn Sie Planung, Design und Architektur beherrschen (und sie von der eigentlichen Implementierung von Code trennen), stellen Sie damit sicher, dass die schwierigsten Entscheidungen der Softwareentwicklung abstrahiert werden. Kapitel 9 behandelt die Programmierphase.
• Erprobung: Die Tests sind ein Bereich Ihrer Pipeline, in den sich Experten aus allen Fachbereichen einbringen können. Sie erhalten dabei eine einmalige Gelegenheit, mehr über Tests, Wartungsfreundlichkeit und Sicherheit zu erfahren. Viele verschiedene Arten von Tests stellen sicher, dass Ihre Software erwartungsgemäß funktioniert. Kapitel 10 behandelt die unterschiedlichen Typen von Tests für diese Phase.
• Bereitstellung: Die Bereitstellungsphase ist vielleicht am engsten mit dem Betriebsablauf verbunden. Traditionell nimmt Ihr Ops-Team den von Ihren Entwicklern entwickelten und von Ihrem Qualitätssicherungsteam getesteten Code und gibt ihn an die Kunden weiter – damit hat es die alleinige Verantwortung für den Veröffentlichungsprozess. DevOps hat auf diese Phase des Entwicklungsprozesses einen enormen Einfluss. Das Deployment ist außerdem einer der Bereiche, in denen die meisten Automatisierungswerkzeuge zu finden sind. Aus Sicht von DevOps liegt Ihre Priorität darin, den Bereitstellungsprozess zu vereinfachen, sodass jeder Entwickler in Ihrem Team in der Lage ist, seinen Code bereitzustellen. Dies heißt nicht, dass der IT-Betrieb kein einzigartiges Wissen hat oder dass Ops-Teams aufgelöst werden könnten.
  Die Ops-Leute werden immer über einzigartiges Wissen zu Infrastruktur, Lastausgleich und dergleichen verfügen. Wenn Sie dem Ops-Team die manuelle Aufgabe der Softwarebereitstellung abnehmen, kann das an anderer Stelle viel Zeit und Geld sparen. Sie haben dann Zeit, die Zuverlässigkeit und Wartungsfreundlichkeit Ihrer Anwendung zu verbessern. In Kapitel 11 bespreche ich, wie Sie Ihren Bereitstellungsprozess glätten und eine Umgebung für Continuous Integration and Continuous Delivery (CI/CD) schaffen können.

Der wichtigste Aspekt eines Delivery-Lifecycles innerhalb des DevOps-Frameworks ist, dass es sich um eine echte Schleife handelt. Wenn Sie am Ende sind, stehen Sie bereits wieder am Anfang. Wenn Sie irgendwo auf dem Weg dorthin Supportfeedback von Kunden erhalten, springen Sie in ei...

Inhaltsverzeichnis

• Cover
• Über die Autorin
• Vorwort
• Inhaltsverzeichnis
• Einleitung
• Teil I: DevOps entmystifizieren
• Teil II: Eine Pipeline einrichten
• Teil III: Den Kreis schließen
• Teil IV: Kaizen: die Kunst der kontinuierlichen Verbesserung
• Teil V: Werkzeuge für Ihre DevOps-Praxis
• Teil VI: Der Top-Ten-Teil
• Stichwortverzeichnis
• End User License Agreement