6 Best Practices für DevOps bei unternehmensweiten Transformationen

Unternehmen können es sich nicht länger leisten, die schnellen Veränderungen in der Art und Weise, wie Software ausgeliefert wird, zu ignorieren. DevOps hat sich als Bewegung herauskristallisiert, um sich der akuten Mängel des Lebenszyklus in der Produktentwicklung anzunehmen – hinausgezögerter Bereitstellungen, ineffektiver Tests, isolierter Kommunikation und Teams, die in der Routine stecken bleiben, anstatt hochwertige Arbeit zu leisten.

In einem der früheren Artikel , haben wir bereits den genauen Mehrwert von DevOps und die wichtigsten Prinzipien erläutert, auf denen dieser Ansatz basiert. Die darin genannten Grundsätze sollten durch entsprechende Praktiken unterstützt werden, die eine schnellere Softwareentwicklung, bessere Codequalität, einen aktiveren Wissensaustausch und die Zusammenarbeit fördern.

DevOps ist eine unternehmensweite Kultur, die durch die Einführung entsprechender Best Practices kontinuierlich gepflegt werden muss.

1. Continuous Delivery

Continuous delivery bezeichnet eine Softwareentwicklungspraxis, bei der Produkteigentümer jederzeit Produktänderungen vornehmen können, ohne die Produktleistung, Qualität oder Benutzererfahrung zu beeinträchtigen.

Alle neuen Codeänderungen werden aus der in der Versionskontrolle gespeicherten System- / Anwendungskonfiguration heraus erstellt, getestet und für die Freigabe in der produktionsähnlichen Umgebung automatisch vorbereitet. Die Bereitstellung in der Produktion kann je nach Geschäftsanforderungen manuell oder automatisch erfolgen.

Durch Continuous Delivery können Unternehmen neue Funktionen freigeben, Fehler beheben oder serverseitige Konfigurationsänderungen im Hintergrund vornehmen, ohne die Leistung des Produkts zu beeinträchtigen.

Das Ziel von Continuous Delivery ist, den Code zu jedem beliebigen Zeitpunkt in einem bereitstellbaren Zustand verfügbar zu haben. Das Projekt selbst kann somit vielleicht erst halb fertig sein, aber die angebotenen neuen Funktionen sind bereits geprüft, getestet, fehlerfrei und einsatzbereit, wann auch immer sie benötigt werden.

Bei Infopulse sind die Rahmenbedingungen für Continuous Delivery folgendermaßen:

• Zuerst werden die Hauptaufgaben von den Entwicklern in kleine Updates unterteilt. Diese Updates, die ursprünglich in der Versionskontrolle erstellt wurden, werden nach ihrer Fertigstellung in einer produktionsähnlichen Umgebung bereitgestellt.
• Nach der Übergabe des neuen Codes erhält das Team sofort das Feedback zu verschiedenen automatisierten Testfällen (aus Abnahmetests, Leistungstests, Regressionstests, Sicherheitstests usw.), das von den entsprechenden Tools generiert wird.
• Wenn ein automatisierter Test aus irgendeinem Grund fehlschlägt, wird der verantwortliche Entwickler den Fall manuell untersuchen und Korrekturen vornehmen.
• Weitere automatisierte Tests können bei Bedarf vor der endgültigen Freigabe der Funktionen angewandt werden.

Das Grundprinzip von Continuous Delivery ist die Zusammenführung des Entwicklungs- und des Testteams in einem einheitlichen Prozess. Sie sind natürlicherweise in den Auslieferungsablauf integriert, wodurch der Produktzeitplan verkürzt wird und die Qualitätsstandards garantiert eingehalten werden.

Die Praktiken von Continuous Delivery werden oft mit Continuous Deployment in Verbindung gebracht. Letzteres ist ein separater Prozess, der Teil Ihres Workflows sein kann (oder auch nicht). Continuous Deployment setzt voraus, dass jede Änderung oder Aktualisierung des Produkts ohne manuelle Kontrolle durch einen DevOps-Ingenieur automatisch für die Produktion bereitgestellt wird.

Continuous Delivery sieht keine automatisierte Bereitstellung vor. Technologisch ist es möglich, neue Änderungen automatisch zu implementieren, aber das Deployment kann aus unternehmerischen Gründen manuell geplant werden.

Bildquelle

Die kontinuierliche Integration ist eine weitere optionale Praktik des Continuous-Delivery-Frameworks. Dabei wird angenommen, dass alle Entwickler den Code mehrmals am Tag an einen zentralen Zweig im Repository absenden. Das Ziel ist hier, die aktuellste Version des Quellcodes an einer Stelle zu verwalten, sodass jedes Teammitglied die letzte Codeversion überprüfen oder abrufen kann, um mögliche Konflikte zu vermeiden. Durch die kontinuierliche Integration wird die Zeit verkürzt, die für die Validierung neuer Updates benötigt wird, und die Software- / Code-Qualität verbessert, Fehler werden schneller lokalisiert und behoben.

2. Microservices-Architektur

Eine einzelne Anwendung wird nicht mehr als ein Monolith angesehen. In der Microservices-Architekturpraxis unterteilt man das gesamte Produkt in eine Reihe kleiner Dienste und Funktionen. Die Design-Architektur ist so entwickelt, dass jeder Dienst seine eigenen Prozesse ausführen und mit anderen Diensten interagieren kann, indem er Leichtbaumechanismen wie APIs (Schnittstellen zur Anwendungsprogrammierung) nutzt.

Die Hauptidee besteht darin, ein großes Produkt in einzelne Dienste zu zerlegen, die einem Zweck dienen. Auf diese Weise wird Ihr Produkt modularer, weil jeder der Dienste unabhängig von den anderen verstanden, entwickelt und getestet werden kann, ohne dass das gesamte Produkt kompromittiert wird. Die gesamte Architektur wird so im Laufe der Zeit resistenter gegen Verfallserscheinungen.

Die Schlüsselprinzipien einer Microservices-Architektur lauten wie folgt:

• Jeder Dienst ist unabhängig einsetzbar, dezentral, und mit Hilfe von automatischen Tools und Prozessen erstellt und freigegeben.
• Dienste (oder Gruppen von Diensten) sind bei Bedarf leicht zu ersetzen oder zu widerrufen.
• Je nach Ihren aktuellen Geschäftsanforderungen können die Dienste mit verschiedenen Programmiersprachen, Datenbanken, Software- und Hardwareumgebungen entwickelt werden.
• Dienste sind nach bestimmten Anwendungsfällen gruppiert, z. B. Abrechnung, Front-End, Logistik etc.

Eine auf Microservices basierende Architektur verschafft bessere Agilität und ermöglicht den Unternehmen, ihr Produkt mit geringeren Kosten und in kürzerer Zeit ohne Aufwand zu skalieren. Da die Microservice-Architektur Teil des Continuous-Delivery-Frameworks ist, kann man damit Anwendungsänderungen durch Umentwicklung und Neuimplementierung von nur einem Dienst oder einer begrenzten Anzahl von Diensten umzusetzen.

3. Kommunikation und Zusammenarbeit

Die DevOps-Kultur überbrückt die Kluft zwischen verschiedenen Teams durch verstärkte Zusammenarbeit, Transparenz und Wissensaustausch. Das Schichtenprinzip besagt, dass dieselben Personen, die eine Anwendung entwickeln, an der Freigabe und am Betrieb beteiligt sein sollen.

Flächendeckende Nutzung entsprechender Tools und automatisierter Lieferprozesse fördern bereits eine engere Zusammenarbeit zwischen den beiden verschiedenen Entitäten (Entwicklung und Betrieb). Das Zusammenführen von Workflows und Abläufen sollte dabei allerdings nicht der letzte Punkt sein.

Die DevOps-Kultur basiert auf den Säulen des Teilens und des aktiven Wissensaustauschs. Wie der Grundsatz des Dritten Weges besagt: Ihre Teams sollen mit den richtigen Werkzeugen für kontinuierliches Experimentieren und lebenslanges Lernen ausgestattet sein. Streben Sie nach einer Umgebung, die den Wissensaustausch maximiert und die Kommunikation zwischen verschiedenen Teams – Entwicklung, Betrieb, Marketing, Vertrieb und sogar Kundensupport – fördert. Jede Person in Ihrem Unternehmen sollte die allgemeinen Geschäftsziele verstehen und ihr Projekt und ihre Aufgabe darauf ausrichten.

Arbeiten Sie an der Erstellung und Pflege von Unternehmens-Wikis, in denen alle Produktaspekte detailliert dargestellt und die aktuellen Best Practices, Produktwerte und Projektziele kontinuierlich kommuniziert werden. Erstellen Sie Dokumente, die Folgendes beschreiben:

• Informationsarchitektur: alle Benutzeroberflächen, Wireframes, Mock-ups und andere UX-Materialien.
• Design-Spezifikationen: Markenfarben, Schriftarten, erforderliche Abmessungen, ästhetische Faktoren und so weiter. Beschreiben Sie so genau, wie nur möglich.
• Produktbeschreibung: wichtigste Produkteigenschaften und Anforderungen, gesamte Geschäftslogik zum Produkt und Vorschläge zu den zukünftigen Funktionen.
• Entwicklungshandbuch Informationen über alle von Ihnen verwendeten Schlüsseltechnologien, die aktuelle Architektur, Richtlinien zur Qualitätssicherung, Schlüsselwerkzeuge, den gesamten Softwareentwicklungszyklus (SDLC).

Wenn Sie ein verteiltes Team managen oder einen Teil Ihrer Betriebsabteilung ausgelagert haben, können Sie folgende Methoden nutzen, um den Wissensaustausch zwischen den internen und den externen Mitarbeitern zu fördern:

Bildquelle

Jedes Teammitglied soll leicht erfahren können, was gerade passiert.

4. Automatisierte Infrastruktur

Infrastructure as Code (IaC) bedeutet, dass jeder Schritt der Infrastrukturerstellung (einschließlich Serverübertragung, Betriebssysteminstallation / -konfiguration usw.) mit entsprechenden Skripten vorgenommen werden kann. Die Bereitstellung und Verwaltung der Infrastruktur erfolgt mit dem Code und unter Anwendung von Versionskontrolle und Continuous Delivery.

Die Koordinierung der Infrastruktur sollte nicht an eine einzelne Maschine oder einen Cluster gebunden sein, sondern kann für beliebig viele Knoten kopiert und repliziert werden. Verschiedene Teammitglieder können die Konfigurationen im Laufe des Entwicklungslebenszyklus mit Hilfe von standardisierten Mustern ändern und verbessern.

Beliebte DevOps-Tools wie Puppet und Chef können Ihnen dabei helfen, Ihr Setup zu betreiben und zu optimieren, indem sie automatisch erforderliche Skripts generieren, die die Infrastructure as Code unterstützen.

Systemadministratoren können weiterhin ihren Code zur Automatisierung von Betriebssystem- und Hostkonfigurationen, standardmäßigen Betriebsaufgaben und zusätzlichen allgemeinen Prozessen verwenden. Dies reduziert die Anzahl der manuellen Vorgänge, die die Mitarbeiter ausführen müssen, ihre Zeit wird somit für wertvollere Aufgaben frei.

5. Chaos Engineering

Die Hauptidee von Chaos Engineering besteht in der Annahme, dass moderne verteilte Softwareanwendungen für unerwartete turbulente Bedingungen entwickelt werden müssen. Daher müssen solche Systeme von vornherein so entworfen sein, dass sie bei unerwarteten Problemen und Schwachstellen in Produktionsumgebungen bestehen können.

Chaos Engineering fußt auf vier Grundprinzipien, die Entwicklungsteams zur Untersuchung von Schwachstellen in Softwaresystemen anwenden:

• Definition eines stabilen Zustands, also eines bestimmten messbaren Leistungswertes Ihres Systems, der für sein normales Verhalten steht.
• Annahme, dass dieser stabile Zustand so bleibt, wie er ist und zwar sowohl in der Kontrollgruppe als auch in der Versuchsgruppe.
• Hinzufügen der Variablen, die reale Ereignisse wie Serverausfälle oder -abstürze, Festplattenfehlfunktionen, Netzwerkverbindungsprobleme usw. darstellen.
• Versuch der Widerlegung der ursprünglichen Hypothese durch die Suche nach einem Unterschied im stabilen Zustand zwischen der Kontrollgruppe und der Versuchsgruppe.

Ermutigen Sie Ihr Team, mit einem spontanen Ausfall von nicht kritischen Diensten und Systemen zu experimentieren. Das Entwicklungsteam soll an diesen Aufgaben üben, schnelle, automatisierte Lösungen für solche Fälle zu erstellen, die sich schrittweise von den unkritischen Diensten wegbewegen und sich auf die kritischen Dienste und eine Kombination verschiedener Fehler konzentrieren.

Das Ziel von Chaos Engineering ist einfach: So trainieren Ihre Teams, eine Architektur und Systeme zu erstellen, die sich bei Fehlern automatisch anpassen können, ohne die Kernfunktionalität der Software zu beeinträchtigen.

Netflix gilt als Pionier des Chaos Engineering. Das Unternehmen hat 2008 damit begonnen, seine Rechenzentren in die Cloud zu migrieren, und hat ein gewisses Maß an Stabilitätstests in die Produktion aufgenommen. Später haben sich ihre internen Experimente zu einem Open-Source-Projekt namens Chaos Monkey entwickelt – einem Tool, das Gruppen von Systemen (Diensten) nach dem Zufallsprinzip auswählt und eines der Systeme in dieser Gruppe herunterfährt. Der “Ausfall” wird zu bestimmten Zeiten und in bestimmten Intervallen durchgeführt, so dass immer Mitarbeiter anwesend sind, die das Problem und die Systemleistung untersuchen.

Durch das Hinzufügen eines Fehlerelements zu dem Mix konnte das Netflix-Team seine Entwickler dazu bewegen, Systeme zu entwickeln, die im Falle eines Ausfalls autonom funktionieren können, und von Anfang an eine belastbare Designarchitektur zu erstellen.

Doch obwohl Chaos Engineering eine bahnbrechende Methode ist, mit der man robuste, gegen viele Fehlertypen gerüstete Systeme erstellen kann, ist sie für Organisationen in frühen Stadien der DevOps-Einführung möglicherweise nicht geeignet.

6. Transformationale Führung

DevOps fördert eine umfassende organisationsweite Transformation, die über das Zusammenbringen der Entwicklungs- und des Betriebsteams hinausgeht. Die IT-Führung muss ebenfalls grundlegende Umgestaltung erfahren. Es wird prognostiziert, dass 50% der CIOs, die ihre Kompetenzen nicht weiterentwickeln werden, bis 2020 das digitale Führungsteam verlassen müssen.

Gewinnerteams sollten von engagierten Führungskräften mit transformationalen Stil geleitet werden, denjenigen, die in der Lage sind, andere zu ihrer besten Arbeitsleistung zu inspirieren und zu motivieren, indem sie an ihre Grundwerte und ihre Zielstrebigkeit appellieren. Transformationale Führung sollte sowohl auf der mittleren als auch auf der leitenden Ebene stattfinden, damit ein flächendeckender organisatorischer Wandel gefördert wird. Das Hauptziel besteht darin, die Teams dazu zu bringen, sich mit der Organisation bzw. dem Projekt, für das sie arbeiten, zu identifizieren und die wichtigsten Geschäftsziele des Unternehmens zu unterstützen.

Andere DevOps-Praktiken werden, langfristig gesehen, ohne die aktive und ständige Unterstützung der neuen Führungskräfte untergehen.
Das Infopulse-Team freut sich darauf, Sie bei Ihrer Transformation zu unterstützen. Unsere DevOps-Berater können Ihnen bei der Umsetzung von neuen DevOps-Projekten helfen oder laufende Projekte im Einklang mit den Best Practices für DevOps umgestalten und managen, umfassende Schulungen für Ihre Mitarbeiter anbieten und Ihrem Unternehmen einen neuen Wettbewerbsvorteil verschaffen.

Kontaktieren Sie uns heute noch und wir unterstützen Sie gerne bei Ihrem DevOps-Projekt.