Hugendubel.info - Die B2B Online-Buchhandlung 

Merkliste
Die Merkliste ist leer.
Bitte warten - die Druckansicht der Seite wird vorbereitet.
Der Druckdialog öffnet sich, sobald die Seite vollständig geladen wurde.
Sollte die Druckvorschau unvollständig sein, bitte schliessen und "Erneut drucken" wählen.
E-BookEPUB0 - No protectionE-Book
459 Seiten
Deutsch
Rheinwerk Verlag GmbHerschienen am05.03.20241. Auflage
DevOps bedeutet nicht, dass Entwickler und Admins nun die gleichen Jobs erledigen. DevOps bedeutet auch nicht, dass man beim Programmieren tägliche neue Tools einsetzen muss, es keine geplanten Deployments mehr gibt und Software nur noch in Containern läuft. DevOps ist viel größer: Es verspricht eine neue Kultur der Zusammenarbeit sowie bessere Prozesse und Workflows. So liefern Sie Änderungen schneller aus und sorgen für kürzere Feedback-Schleifen zwischen Usern, Operations und Developern.
In zahlreichen Projekten hat Sujeevan Vijayakumaran gelernt, was in der Entwicklung und im Betrieb moderner Software gut funktioniert. Mit vielen Beispielen und Praxistipps zeigt er Ihnen, wie Sie eine moderne und zeitgemäße Arbeitsumgebung für Ihre IT-Projekte schaffen und die DevOps-Transformation in Ihrem Team gelingt.

Aus dem Inhalt:

Effizientes Zusammenarbeiten beim Programmieren
Schlanke Build-Prozesse
Frühe, schnelle und automatisierte Qualitätssicherung
Schnellere Releases erstellen und deployen
Den Dienst betreiben und überwachen
Sicherheit und Compliance unter einen Hut bringen
Continuous Integration: Tools richtig einsetzen
Continuous Delivery praktisch umsetzen
Monitoring und Observability für mehr Durchsicht
Mit DevOps-Plattformen die Toollandschaft vereinfachen
Jenseits von Kultur und Toolsmehr
Verfügbare Formate
BuchGebunden
EUR39,90
E-BookEPUB0 - No protectionE-Book
EUR39,90

Produkt

KlappentextDevOps bedeutet nicht, dass Entwickler und Admins nun die gleichen Jobs erledigen. DevOps bedeutet auch nicht, dass man beim Programmieren tägliche neue Tools einsetzen muss, es keine geplanten Deployments mehr gibt und Software nur noch in Containern läuft. DevOps ist viel größer: Es verspricht eine neue Kultur der Zusammenarbeit sowie bessere Prozesse und Workflows. So liefern Sie Änderungen schneller aus und sorgen für kürzere Feedback-Schleifen zwischen Usern, Operations und Developern.
In zahlreichen Projekten hat Sujeevan Vijayakumaran gelernt, was in der Entwicklung und im Betrieb moderner Software gut funktioniert. Mit vielen Beispielen und Praxistipps zeigt er Ihnen, wie Sie eine moderne und zeitgemäße Arbeitsumgebung für Ihre IT-Projekte schaffen und die DevOps-Transformation in Ihrem Team gelingt.

Aus dem Inhalt:

Effizientes Zusammenarbeiten beim Programmieren
Schlanke Build-Prozesse
Frühe, schnelle und automatisierte Qualitätssicherung
Schnellere Releases erstellen und deployen
Den Dienst betreiben und überwachen
Sicherheit und Compliance unter einen Hut bringen
Continuous Integration: Tools richtig einsetzen
Continuous Delivery praktisch umsetzen
Monitoring und Observability für mehr Durchsicht
Mit DevOps-Plattformen die Toollandschaft vereinfachen
Jenseits von Kultur und Tools
Details
Weitere ISBN/GTIN9783836291019
ProduktartE-Book
EinbandartE-Book
FormatEPUB
Format Hinweis0 - No protection
Erscheinungsjahr2024
Erscheinungsdatum05.03.2024
Auflage1. Auflage
ReiheRheinwerk Computing
Seiten459 Seiten
SpracheDeutsch
Dateigrösse7503 Kbytes
Artikel-Nr.12256150
Rubriken
Genre9200

Inhalt/Kritik

Inhaltsverzeichnis
1. Einleitung ... 15

1.1 ... Kultur ... 17
1.2 ... Technik ... 17
1.3 ... Mein Weg zu DevOps und zu diesem Buch ... 18
1.4 ... Zielgruppe ... 20
1.5 ... Die Struktur des Buches ... 21
1.6 ... Feedback ... 21
1.7 ... Danke! ... 22

2. Was ist DevOps? ... 23

2.1 ... DevOps: Das große Ganze ... 24
2.2 ... Missverständnisse rund um DevOps ... 37
2.3 ... Der DevOps-Lifecycle ... 44

3. Die Beispielfirma ... 49

3.1 ... schick-gekleidet.de ... 50
3.2 ... Das Entwicklungsmodell ... 50
3.3 ... Das Business-Team -- Anforderungsanalyse ... 51
3.4 ... Das Architekturteam -- Design der Anwendung ... 52
3.5 ... Die Entwicklungsteams ... 52
3.6 ... Das Qualitätssicherungsteam ... 55
3.7 ... Das Betriebsteam -- Das Ops aus DevOps ... 56
3.8 ... Das Infrastrukturteam ... 59
3.9 ... Das Security-Team ... 60
3.10 ... Fazit ... 61

4. Projektmanagement und Planung ... 63

4.1 ... Der erste Schritt: Das agile Mindset ... 63
4.2 ... Projektmanagement für alle? ... 67
4.3 ... Fazit ... 75

5. Kollaboration beim Coden ... 77

5.1 ... Die typischen Probleme bei der Verwaltung des Sourcecodes ... 78
5.2 ... Die Organisation des Codes verbessern ... 86
5.3 ... An Git führt nichts vorbei ... 88
5.4 ... Code-Reviews und Pair Programming ... 97
5.5 ... Inner Sourcing -- Code im Unternehmen teilen ... 109
5.6 ... Fazit ... 120

6. Continuous Integration und der Build Prozess ... 121

6.1 ... Die typischen Probleme im Build-Prozess ... 121
6.2 ... Modernes Build-Management ... 128
6.3 ... Continuous Integration ... 131
6.4 ... CI-Server und die Pipelines ... 136
6.5 ... DRY und KISS: »Don't repeat yourself« und »Keep it simple, stupid!« ... 142
6.6 ... Ein Überblick über CI-Server ... 145
6.7 ... Fazit ... 165

7. Die Qualität sicherstellen ... 167

7.1 ... Die typischen Probleme beim Testing ... 167
7.2 ... Testen als Teil des DevOps-Prozesses ... 172
7.3 ... Fazit ... 187

8. Continuous Delivery und Deployment ... 189

8.1 ... Die typischen Probleme beim Release-Management ... 189
8.2 ... Continuous Delivery und Deployment implementieren ... 196
8.3 ... Build-Management für Deployments ... 210
8.4 ... Rollbacks, Kanarienvögel und Feature Flags ... 217
8.5 ... Deployment-Ziele -- Wohin mit dem Deployment? ... 226
8.6 ... Fazit ... 242

9. Den Dienst betreiben ... 245

9.1 ... Die typischen Probleme beim Betreiben der Dienste ... 245
9.2 ... Aufbrechen der stark gekoppelten Infrastruktur-Architektur ... 250
9.3 ... Cloud-Computing ... 258
9.4 ... Stärkere Zusammenarbeit von Dev und Ops ... 269
9.5 ... Konfigurationsmanagement: Everything as Code ... 276
9.6 ... Chaos-Engineering ... 286
9.7 ... Reliability Engineering ... 291
9.8 ... Fazit ... 294

10. Vom Monitoring zur Observability ... 295

10.1 ... Keine Sichtbarkeit bei schick-gekleidet.de ... 296
10.2 ... Mit Durchblick kommt Weitsicht ... 304
10.3 ... Tools für Monitoring, Observability und Tracing ... 312
10.4 ... Verfügbarkeit ... 333
10.5 ... Fazit ... 337

11. Security und Compliance ... 339

11.1 ... Sicherheit stört den agilen Wasserfall ... 340
11.2 ... DevOps mit getrenntem Security-Team ... 343
11.3 ... DevSecOps: Sicherheit in DevOps einbauen ... 347
11.4 ... Werkzeuge für mehr Sicherheit ... 355
11.5 ... Supply-Chain-Security ... 365
11.6 ... Compliance ... 372
11.7 ... Fazit ... 383

12. Die DevOps-Transformation erfolgreich umsetzen ... 385

12.1 ... Die DevOps-Kultur einführen ... 385
12.2 ... Mit DORA-Metriken den DevOps-Erfolg messbar machen ... 401
12.3 ... Value Stream Mapping ... 408

13. DevOps-Plattformen ... 417

13.1 ... Toolchain-Komplexität ... 418
13.2 ... DevOps-Plattformen im Überblick ... 424
13.3 ... Fazit ... 428

14. Jenseits von Kultur und Tools ... 429

14.1 ... Die Rolle von AI in DevOps ... 429
14.2 ... DataOps, MLOps -- was es sonst noch alles gibt ... 438
14.3 ... DevOps als Job ... 441
14.4 ... Fazit ... 454

Index ... 455mehr
Leseprobe


2    Was ist DevOps?

DevOps ist schon lange kein Hype mehr. Viele Personen machen »irgendetwas mit DevOps« und haben ihre Meinungen und Einschätzungen dazu. Fragt man sie, was genau hinter diesem Wort steckt, hört man zwar oft zunächst eine Erklärung, was sich hinter diesem Begriff verbirgt und wofür DevOps gut ist, aber genaueres Nachfragen offenbart dann eher eine Mischung aus gefährlichem Halbwissen, einer losen Aufzählung von expliziten Technologien und Buzzwords.

Gut, dass Sie dieses Buch lesen: Sie scheinen Interesse am Thema zu haben, dürften sicherlich schon etwas darüber gehört haben und wollen sich jetzt ein genaueres Bild machen, ob DevOps auch was für Sie etwas ist. Gute Idee!

Falls Sie vielleicht etwas skeptischer sind, dann ist das natürlich auch gut. Ich bin kein großer Fan von Buzzwords und Superlativen. Und genauso halte ich es auch hier: Natürlich ist nicht alles super und schön, sobald man DevOps-Prinzipien umsetzt. Natürlich ist nicht alles schlecht, sobald mal keine DevOps-Prinzipien umsetzt. Natürlich ist auch weiterhin nicht alles DevOps, nur weil man DevOps dranschreibt.

Häufig kann ich es den Leuten gar nicht übelnehmen, wenn sie keine klare Vorstellung von der Idee hinter DevOps haben und dementsprechend skeptisch sind. Mittlerweile schreiben viele Firmen »DevOps« an ihre Produkte oder an die Job-Titel ihrer Mitarbeitenden, weil es gleich viel moderner klingt. Was früher »Agile« und »Scrum« war, ist heute »DevOps«. Hauptsache, es wirkt so, als ob man mit der Zeit geht.

Ob in solchen Firmen die DevOps-Umsetzung wirklich beispielhaft gelungen ist, kann man teilweise von außen erkennen, teilweise aber auch nicht. Mein Lieblingsbeispiel ist der »DevOps-Engineer«, den gefühlt jede Firma sucht, die sich moderner aufstellen will. Praktisch für diejenigen, die sich auf diese Stellen bewerben: Diese Jobs werden meistens anständiger bezahlt, als wenn kein DevOps dranstehen würde. Bitte verstehen Sie mich nicht falsch: Es gibt einige triftige Gründe, einen Job mit »DevOps-Engineer« zu betiteln! Leider steckt nur meist nicht das dahinter, was man erwartet. Dieses Thema wird in Abschnitt 14.3 näher betrachtet.

Steigen wir jetzt also in das Thema direkt ein, und schauen wir uns an, was DevOps überhaupt ist.
2.1    DevOps: Das große Ganze

DevOps als Ganzes ist im Wesentlichen eine Arbeitskultur. Es ist keine Technik, kein Tool, keine Job-Bezeichnung und, ja, es ist im Grunde auch keine Team-Bezeichnung, obwohl es sich von den beiden Begriffen Development und Operations ableitet, mit denen klassischerweise die Entwicklung und der Betrieb bezeichnet werden. Um erfolgreich nach den DevOps-Prinzipien arbeiten zu können, müssen die Prinzipien dieser Kultur möglichst umfassend in der Firma gelebt werden.

Das heißt also: Nicht nur die einzelnen Teams sollten nach DevOps-Prinzipien arbeiten, sondern die ganze Firma, denn ansonsten sind ihre Erfolgschancen gering. Daher ist es nicht sinnvoll, wenn einzelne Teams als »DevOps-Teams« bezeichnet werden und andere Teile wiederum gar nicht existieren. Schließlich geht es um das große Ganze und nicht um einzelne Teams.

Außerdem ist DevOps unabhängig von den Tools, die verwendet werden. Wer sich wundert, warum ich das hier abermals erwähne: Das ist essenziell und wird - obwohl es bekannt ist - immer wieder ignoriert. Es ist nämlich andersherum: Die Tools unterstützen die Prozesse, was wiederum die Menschen unterstützt. Es wäre also ein falscher Ansatz, die Prozesse umzustellen, nur weil man überzeugt ist, dass man endlich Kubernetes in der Firma einführen sollte.

Während die agile Software-Entwicklung eine gute Basis darstellt, geht es bei DevOps darum, den ganzen Software-Development-Lifecycle (SDLC) zu betrachten. Dieser beginnt mit der Projektplanung, geht mit dem Programmieren und dem Ausrollen an die Endnutzer weiter, um anschließend das Feedback aus dem Betrieb für die weiteren Entwicklungsarbeiten zu nutzen. Eigentlich könnte man auch gleich vom Software-Delivery-Lifecycle sprechen, schließlich ist ein Development ohne Delivery reichlich witzlos.

Grundsätzlich geht es bei DevOps darum, den agilen Software-Entwicklungsprozess deutlich auszuweiten. Die agile Software-Entwicklung zielt darauf ab, dass nicht alles im Voraus haargenau geplant wird, sondern dass in kürzeren Iterationen und in Inkrementen gearbeitet wird, um flexibler mit den sich ändernden Anforderungen zurechtzukommen. Ein etwas tieferer Einstieg in die agile Software-Entwicklung erfolgt gleich in Abschnitt 4.1.

Obwohl DevOps eigentlich eine gelebte Kultur sein soll, kann man sich ihr natürlich theoretisch nähern und versuchen, sie durch Definitionen zu fassen. Es muss Ihnen aber klar sein, dass diese Zusammenfassungen immer nur Ideale und Abstraktionen darstellen, die Sie konkret an Ihre Umgebung anpassen müssen.

Dennoch ist es sinnvoll, diese Prinzipien zu kennen, da sie ein gutes Gerüst bilden, an dem Sie sich bei der Umsetzung orientieren können. In der Praxis haben sich zwei Methodiken und Definitionen etabliert. Das sind einmal die Grundwerte von DevOps, nämlich das CA(L)MS-Modell sowie die sogenannten Drei Wege, wobei der Begriff meistens im englischen Original genutzt wird: The Three Ways.

Beide Aspekte werden Sie im Laufe des Buches immer wieder erkennen, und ich werde mich wiederholt auf diese Punkte zurückbesinnen, damit bei den jeweiligen Aspekten klar ist, wozu ein jeder gehört. Lassen Sie uns nun zunächst erst mal in die Prinzipien einsteigen, damit klar ist, worum es geht, ohne uns allzu sehr in den Details zu verlieren. Sowohl CA(L)MS als auch The Three Ways nähern sich DevOps auf unterschiedlichen Arten.
2.1.1    CA(L)MS

Das CA(L)MS-Modell enthält die Leitprinzipien von DevOps. Aber jetzt erst einmal einen Schritt zurück: Wofür steht überhaupt CA(L)MS?

CA(L)MS ist eine Abkürzung von vier oder fünf Werten:

C für Culture


A für Automation


L für Lean


M für Measurement


S für Sharing


Die Thematik rund um »Lean« wird oft als optional betrachtet, weswegen die Grundwerte als CAMS und die Erweiterung als CALMS zu finden ist.

Abbildung 2.1     Das CALMS-Modell

Bei Ihrer DevOps-Transformation hilft Ihnen das CALMS-Modell, da es betont, dass alle Aspekte gleichmäßig aufgebaut werden und somit gemeinsam wachsen müssen. Sie stehen auf dem Fundament der Kultur, denn ohne diese geht es nicht.

Auf jeden dieser Punkte gehe ich hier zunächst einmal relativ oberflächlich ein. In den folgenden Kapiteln werde ich allerdings immer wieder auf die einzelnen Bestandteile des CALMS-Modells verweisen, damit klarer ist, was die einzelnen Aspekte jetzt mit DevOps zu tun haben und wo sie sich in dem CALMS-Modell wiederfinden.
C für Culture
Das C steht für Culture, also Kultur. Hier ist vordergründig die Arbeitskultur gemeint: Wie erfolgt die Zusammenarbeit im Team und innerhalb der Organisation, ganz unabhängig von den verschiedenen Rollen und Aufgabengebieten im Team?

Ein Team, das nach den DevOps-Prinzipien arbeitet, besteht stark vereinfacht gesprochen im Wesentlichen aus Entwicklung (Dev) und Betrieb (Ops), die zusammenarbeiten und nicht, wie so häufig, gegeneinander antreten. Anstatt dass beide Teams getrennt voneinander in Silos hocken und mit großen, hohen Wänden voneinander abgeschottet sind, setzen sich beide Gruppen bei ihren Aufgaben für ein gemeinsames Ziel ein.

Aber hier kommt es schon zum ersten Problem: Die Entwickler müssen neue Features entwickeln, die möglichst wenig Fehler aufweisen. Das Hauptaugenmerk des Betriebsteams liegt auf dem sicheren und stabilen Einsatz der Software, die vom Entwicklungsteam geschrieben wurde.

Die Kultur des Teams ist entscheidend, da alle Menschen aus dem Team nicht nur organisatorisch, sondern auch hinsichtlich der Ziele zusammengeführt werden müssen. Für beide Gruppen ist es wichtig, beide Aufgaben zu erfüllen.

Ein klassisches Entwicklungsteam kann die neuen Features nicht ausrollen, weil das Deployment zu kompliziert und fehleranfällig ist. Hier ist Teamwork gefragt, nicht »Works for me«.

Ein wesentlicher Aspekt ist das häufige Ausrollen von Releases, um die Zeit von der Fehlerkorrektur bis zum Ausrollen möglichst kurz zu halten. Für diese Aufgabe ist Automatisierung notwendig. Und diese hilft auch nur dann, wenn man sich auch wirklich traut, die Software auszurollen. Hier spielen noch weitere Aspekte hinein, wie ausführliche Tests, um sicher und regelmäßig Änderungen veröffentlichen zu können.

Und genau deshalb ist es wichtig, dass nicht nur diese beiden Gruppen an der Arbeitskultur...

mehr