SlideShare ist ein Scribd-Unternehmen logo
IT-Probleme lösen. Digitale Zukunft gestalten.
DevOps Prinzipien im Zusammenspiel mit Kubernetes Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck
Inhaltliche Mitwirkung: Dr. Josef Adersberger, QAware GmbH
Continuous Release
• Feature Rollout
• Release Patterns ausführen
(siehe Grafiken rechts)
Continuous Deployment
• Deployment in Production Stage
• Post-Deployment Checks
• Kompatibilitäts-Tests
...
Build + Test + Package + Deploy
Wertschöpfungsketten-bezogene KPI
DevOps Performance Metrics [2]
• Change Lead Time: Code commited to change released to end-users
• Deployment Frequency: Deployments to production
• Change Fail Rate: Percentages of deployments resulting in degraded service
• Time to Restore (MTTR)
Flow Metrics [3]
• Velocity: Items completed over a given period of time
• Efficiency: Item in active state vs. in waiting state from start to completion
• Time: Average time between start and completion of an item
• Load: Number of items currently in progress
• Distribution: Distribution of items of features, defects, risks (SecComp), debt
Ergebnis-bezogene KPI
• Qualitätsschulden-Analysen und automatisierte Tests [1]
• Net Promotor Score [4]
• Hypothesen-Tests [5]
• User Feedback
• Business KPI!
[1] https://martinfowler.com/articles/is-quality-worth-cost.html
[2] DORA: 2019 Accelerate State of DevOps Report
https://cloud.google.com/devops/state-of-devops
[3] https://go.tasktop.com/Flow-Metrics-Ebook-Ungated.html
[4] https://hbr.org/2003/12/the-one-number-you-need-to-grow
[5] David J. Bland, Alex Osterwalder, Testing Business Ideas
i Überblick gebräuchlicher Key Performance Indicators (KPI) i Kubernetes
Kubernetes ist ein Open-Source-System zur
Automatisierung der Bereitstellung, Skalie-
rung und Verwaltung von Container-Anwen-
dungen. Es zielt darauf ab, eine „Plattform
für das automatisierte Bespielen, Skalieren
und Warten von Anwendungscontainern auf
verteilten Hosts“ zu liefern. Es kann so Fla-
schenhälse im DevOps Cycle minimieren und
Infrastructure as Code für Test- und Produk-
tivumgebungen ermöglichen, sowie die au-
tomatisierte Erhebung von Telemetriedaten
mittels Service Meshs vereinfachen.
Code
Repository
API/CLI
horizontal skalierbar
Image
Registry
z. B.. Quay.io,
JFrog Artifactory
DockerHib, …
Service Meshs
z.B.. Linkerd,
Istio …
Deployed Services
Container Orchestrator
z.B.. Kubernetes, Docker Swarm, Normand, …
z. B.. Prometheus, Grafana,
ELK-Stack, etc,
Telemetriedaten erheben
Eine zentrale Telemetrie-Infrastruktur aufbauen
Geschäftslogik und Infrastruktur erzeugen verteilte
Events, Logs und Metriken, die in einem zentralen
Service konsolidiert werden.
Anwendungen systematisch loggen
Anwendungen müssen ausreichend Telemetrie-
daten erzeugen und an die Telemetrie-Infrastruktur
angebunden werden. Jedes entwickelte Feature
sollte auch geeignet instrumentalisiert werden.
Self-Service Zugriff auf Telemetriedaten
Damit jeder Probleme auch finden und beheben
kann, muss auch jeder Metriken erstellen, generie-
ren, anzeigen und analysieren lassen können.
Code
Code
Code
Code
Code
Architektur
Eine DevOps-konforme Architektur sollte risikoarme
Releases ermöglichen und sich evolutionär von Release
zu Release weiterentwickeln lassen.
Eine Architektur sollte aus lose gekoppelten autonomen
Komponenten bestehen, die von autarken Teams betreut
und betrieben werden können und kleine Batches von
Entwicklungen zulassen.
Automatisierte Tests
Eine Deployment-Pipeline stellt sicher,
dass jeglicher Code der in die Versions-
verwaltung eingecheckt wird, automatisch
gebaut und in einer produktivähnlichen
Umgebung mittels automatisierter Unit-,
Akzeptanz-, Integrationstests und Post-
Deployment-Checks getestet wird. So lassen
sich Build-, Test- oder Integrati- onsfehler
bereits beim Einführen einer Änderung
erkennen und beheben. Resul- tierender
Code ist immer in einem auslie- ferbaren
Zustand.
Releaserisiken reduzieren
Umgebungsbasierte Release-Strategien: Beim Blue/Green Deployment
hat man zwei Produktiv-Releases. Doch nur eines bedient Kunden. Funk-
tioniert ein Release nicht, kann notfalls auf das funktionierende Release
zurückgeschaltet werden. Canary-Releases funktionieren ähnlich,
nur werden Features erst wenigen, und dann sukzessive immer mehr
Nutzern bereitgestellt. Sollten Probleme auftreten, wird wieder zurück
gerollt. Bei Rolling-Updates werden Deployment Units inkrementell
aktualisiert.
Anwendungsbasierte Releases: Feature Schalter ermöglichen das
selektive ein-/ausschalten von Features abhängig von Last oder sons-
tigen Erwägungen. Features können notfalls auch wieder abgeschaltet
werden, wenn diese sich nicht bewähren.
DevOps Prinzipien des Feedback
i Continuous-Begriffe
Continuous Delivery
• Deployment in QA Stage
• Akzeptanztests
• Performance-Tests
...
Feature schafft
Mehrwert für
Nutzer
Continuous Integration
Shift Left QS (frühes Testen):
• statische Analyse
• Unit Tests
• Kompatibilitätstests
• License Checks
• Vulnerability Analysis
…
Code-Änderung
API/CLI
t
t
FLASCHENHÄLSEMINIMIEREN
Flaschenhälse folgen häufig diesen Mustern:
• Langwieriges (manuelles) Erstellung von Test- und Produktiv-
Umgebungen => Erstellung von Umgebungen im Self-Service auf
Anforderung.
• Langwieriges (manuelles) Code-Deployment => Automatisiertes
Deployment mittels Deployment Pipelines.
• Langwieriges (manuelles) Einrichten und Durchführen von Tests =>
Automatisiertes und parallelisiertes Testen, so dass die Testrate mit
der Code-Entwicklungsrate mithält.
• Zu stark gekoppelte Architekur (lokale Änderungen müssen mit
vielen abgestimmt werden) => Lose gekoppelte Architektur (z.B.
Microservices) um Änderungen sicherer und mit mehr Autonomie
durchführen zu können.
WORKINPROCESSBESCHRÄNKEN
Unterbrechungen sind bei der Herstellung physischer Güter sehr
kostenintensiv, denn häufig muss die aktuelle Arbeit abgebrochen,
ggf. entsorgt und Maschinen umgerüstet werden.
Das Unterbrechen von Technologiemitarbeitern ist ebenfalls teuer,
allerdings wesentlich einfacher (ein Anruf, eine Mail, eine Nachricht,
etc.). Studien haben gezeigt, dass sich die Zeit zum Erledigen selbst
einfacher Aufgaben (wie dem Sortieren geometrischer Formen)
beim Multitasking deutlich verlängert.
Multitasking sollte daher reduziert werden, indem man Obergrenzen
für Kanban-Spalten (Arbeitsstationen) festlegt und die Anzahl an
Spalten (Übergaben) möglichst klein hält, um zu vermeiden, dass
zwischen zu vielen Schritten und Kontexten hin und her gesprungen
wird.
DevOps Prinzipien des Flow
ARBEITSICHTBARMACHEN
Bei Technologiearbeit (anders als in der Produktion) kann Arbeit
häufig mit einem „Mausklick“ bewegt werden. Weil das so einfach
ist, werden manche Arbeitspakete zwischen Teams wie Pingpong
hin und her bewegt, ohne das nennenswerter Wert erzeugt wird oder
dies im Arbeitsalltag unmittelbar auffällt.
Um zu erkennen, wo Arbeit gut fließt und wo nicht, kann man auf
visuelle Arbeitsboards (z.B.. Kanban-Boards) zurückgreifen. Ein
Kanban-Board sollte immer die gesamte Wertkette umfassen, d.h.
bis ein Feature in einer Anwendung erfolgreich produktiv läuft.
Telemetriedaten erheben
Je länger Entwickler isoliert in Branches arbeiten, desto
(exponentiell) schwieriger wird es, alle Änderungen
wieder zusammenzuführen.
Continuous Integration hat daher zum Ziel, die Entwick-
lungsbranches einzelner Entwickler mittels Trunk-
basierter Entwicklungspraktiken und kleinen Batch-
größen idealerweise täglich zusammenzuführen.
Commits, die sich dabei nicht automatisiert deployen
lassen, sollten auch nicht in die Versionsverwaltung
eingecheckt werden können.
Continuous Integration
A/B-Tests
sind eine Testmethode zur Bewertung von Varianten eines Systems, bei der
die Originalversion gegen leicht veränderte Versionen getestet werden. Ziel
ist Nutzerreaktionen mit einer Kontrollgruppe zu vergleichen.
A/B-Tests in Feature-Testing integrieren
In modernen UX-Praktiken werden häufig Besuchern einer Website eine von
zwei Versionen einer Seite angezeigt. Mittels einer statischen Analyse des
Folgeverhaltens (Conversion Rates) kann objektiv geprüft werden, ob eine
Änderungen einen Effekt im Nutzerverhalten gebracht hat, oder nicht. Mit Hilfe
von Feature-Schaltern lässt sich genau steuern wie groß der Anteil von Kun-
den ist, die eine Testversion eines Experiments erhalten.
Hypothesengetrieben entwickeln
Mit Statistik potenzielle Probleme erkennen
Probleme können bei normalverteilten Ereignissen mit einfachen aber be-
währten statistischen Verfahren (wie Mittelwert und Standardabweichung)
identifiziert werden. Unterliegen Ereignisse keiner Normalverteilung kann
man auf glättende Verfahren (gleitende Durchschnitte), periodische/saisonale
Verfahren (Kolmogorow-Smirnow, etc.) zurückgreifen.
Nur bei signifikanten Ereignissen automatisiert warnen
Entfernen sich Metriken statistisch signifikant von ihren Normalwerten, so
sollten automatisierte Warnungen ausgelöst werden, da dies Vorboten eines
Produktivzwischenfalls sein können. Hierfür ist solides statistisches Wissen
über die Verteilung entsprechender Ereignisse erforderlich.
Telemetriedaten analysieren
Telemetriedaten erhebenTelemetriedaten erheben
A B
Telemetry
Service
Rolling Upgrade
1. 2. 3.
Canary Releases
traffic
traffic
Capacity
Production
traffic
t
Blue/Green
Deoloyment
traffic
Hot Standby
1. AVB Testing
2. Rolling Upgrade
3. Blue/Green
DevOps ist die Kultur, die Entwicklung (Dev) und
den Betrieb (Ops) von Anwendungen besser mitei-
nander zu integrieren, um kurze Release-Zyklen,
zuverlässige Inbetriebnahmen und eine hohe Ver-
fügbarkeit zu erreichen. Dies wird durch eine ver-
besserte Kooperation und einen höheren Automa-
tisierungsgrad erreicht.
i DevOps
Release Patterns
PROBLEMESOFORTLÖSEN
Werden Probleme im Produktivsystem erkannt, sollte die Problemlö-
sung höhere Priorität als die weitere Entwicklung von Features be-
kommen. Die Entwicklungspipeline sollte gestoppt werden. Probleme
sollten nie umgangen werden oder deren Lösung verschoben werden,
um zu vermeiden, dass sich ein Problem fortsetzt und zu exponentiell
steigendem Aufwand für dessen Behebung zu einem späteren Zeit-
punkt führt.
Damit dies funktioniert ist eine fehlerverzeihende Kultur erforderlich,
die die Lösung des Problems in den Mittelpunkt stellt und nicht den
Verursacher zur Rechenschaft zieht.
PROBLEMEFRÜHERKENNEN
Komplexe Systeme sind nicht vollständig von einer einzelnen Person
überschau- und verstehbar, da sie aus einer Vielzahl eng miteinan-
der verbundener Komponenten bestehen, deren Wechselwirkungen
nicht immer vorhersehbar sind. Daher sollten Annahmen, die beim
Design getroffen wurden, kontinuierlich geprüft werden. Z.B.. durch
Experimentieren mit einem Softwaresystem in der Produktion (Chaos
Engineering), um Vertrauen in die Fähigkeit des Systems aufzubauen,
turbulenten und unerwarteten Bedingungen standzuhalten. Ferner
benötigt man für Feedback-Schleifen im Produktivsystem kontinuier-
lich und automatisiert erhobene Telemetriedaten.
PROBLEMEPROFESSIONELL
VERANTWORTEN
Erstaunlicherweise erhöht in komplexen Systemen das Hinzufügen
zusätzlicher Kontrollschritte und Genehmigungsprozesse die Wahr-
scheinlichkeit für zukünftige Fehler, da Entscheidungen von Personen
getroffen werden müssen, die weit weg vom Problemraum sind.
Besser ist es, wenn Entwickler Verantwortung auch für den operati-
ven Betrieb haben (you build it, you run it). Dadurch liegt die Verant-
wortung für Qualität, Zuverlässigkeit sowie die Entscheidungsbefug-
nis dort, wo auch die Arbeit erledigt wird und die meiste technische
Expertise vorhanden ist. Durch dieses direkte Feedback aus Ops wird
das Lernen im Devs beschleunigt und zukünftige Probleme sind bes-
ser abschätzbar und konstruktiv vermeidbar.
!
?

Weitere ähnliche Inhalte

Was ist angesagt?

Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
ChristinaLerch1
 
Dev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei TechnosoftDev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei Technosoft
Bart Zwager
 
Kaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes seinKaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes sein
Stephan Kaps
 
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
DevOpsCon 2016 - Continuous Security Testing - Stephan KapsDevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
Stephan Kaps
 
In den sicheren Hafen jax2020
In den sicheren Hafen jax2020In den sicheren Hafen jax2020
In den sicheren Hafen jax2020
Stephan Kaps
 
Kaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment RoadmapKaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment Roadmap
Stephan Kaps
 
DevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der SchieneDevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der Schiene
Vorname Nachname
 
Migration zum Zend Framework 3
Migration zum Zend Framework 3Migration zum Zend Framework 3
Migration zum Zend Framework 3
Ralf Eggert
 
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-UmfeldEnterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
QAware GmbH
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
QAware GmbH
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
QAware GmbH
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
Steffen Gebert
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
QAware GmbH
 
TDD für Testmuffel
TDD für TestmuffelTDD für Testmuffel
TDD für Testmuffel
Hendrik Lösch
 
Automatisierung von Security Test im Build-Prozess
Automatisierung von Security Test im Build-ProzessAutomatisierung von Security Test im Build-Prozess
Automatisierung von Security Test im Build-Prozess
x-celerate
 
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-PipelinesContinuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
Tobias Schneck
 
OpenShift-Build-Pipelines: Build ► Test ► Run!
OpenShift-Build-Pipelines: Build ► Test ► Run!OpenShift-Build-Pipelines: Build ► Test ► Run!
OpenShift-Build-Pipelines: Build ► Test ► Run!
Tobias Schneck
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
Gjero Krsteski
 
Technische Gründe für schlechte Entwicklungsperformance
Technische Gründe für schlechte EntwicklungsperformanceTechnische Gründe für schlechte Entwicklungsperformance
Technische Gründe für schlechte Entwicklungsperformance
OPEN KNOWLEDGE GmbH
 
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
punkt.de GmbH
 

Was ist angesagt? (20)

Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
Dev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei TechnosoftDev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei Technosoft
 
Kaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes seinKaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes sein
 
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
DevOpsCon 2016 - Continuous Security Testing - Stephan KapsDevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
 
In den sicheren Hafen jax2020
In den sicheren Hafen jax2020In den sicheren Hafen jax2020
In den sicheren Hafen jax2020
 
Kaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment RoadmapKaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment Roadmap
 
DevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der SchieneDevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der Schiene
 
Migration zum Zend Framework 3
Migration zum Zend Framework 3Migration zum Zend Framework 3
Migration zum Zend Framework 3
 
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-UmfeldEnterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
Enterprise CI/CD: Continuous Integration & Delivery im Enterprise-Umfeld
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
 
TDD für Testmuffel
TDD für TestmuffelTDD für Testmuffel
TDD für Testmuffel
 
Automatisierung von Security Test im Build-Prozess
Automatisierung von Security Test im Build-ProzessAutomatisierung von Security Test im Build-Prozess
Automatisierung von Security Test im Build-Prozess
 
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-PipelinesContinuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines
 
OpenShift-Build-Pipelines: Build ► Test ► Run!
OpenShift-Build-Pipelines: Build ► Test ► Run!OpenShift-Build-Pipelines: Build ► Test ► Run!
OpenShift-Build-Pipelines: Build ► Test ► Run!
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
 
Technische Gründe für schlechte Entwicklungsperformance
Technische Gründe für schlechte EntwicklungsperformanceTechnische Gründe für schlechte Entwicklungsperformance
Technische Gründe für schlechte Entwicklungsperformance
 
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
 

Ähnlich wie DevOps Prinzipien im Zusammenspiel mit Kubernetes

Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickeln
Martin Seibert
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
Aberla
 
Continuous Delivery as a Way of Life
Continuous Delivery as a Way of LifeContinuous Delivery as a Way of Life
Continuous Delivery as a Way of Life
Kremer Consulting
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
Minerva SoftCare GmbH
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
matfsw
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
mradamlacey
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Aarno Aukia
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
Christian Baranowski
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Fabian Niesen
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
AUVESY
 
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Nico Orschel
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Marc Bless
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DNUG e.V.
 
Kontinuierliche Integration
Kontinuierliche IntegrationKontinuierliche Integration
Kontinuierliche Integration
Johannes Weber
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
Hendrik Lösch
 
ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“
QAware GmbH
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice Architekturen
Leo Lindhorst
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Peter Affolter
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Virtual Forge
 

Ähnlich wie DevOps Prinzipien im Zusammenspiel mit Kubernetes (20)

Continous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickelnContinous Deployment - Schneller entwickeln
Continous Deployment - Schneller entwickeln
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
 
Continuous Delivery as a Way of Life
Continuous Delivery as a Way of LifeContinuous Delivery as a Way of Life
Continuous Delivery as a Way of Life
 
Objektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWBObjektbasierte Versionierung und Lifecycle Management für den OWB
Objektbasierte Versionierung und Lifecycle Management für den OWB
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
 
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 
Kontinuierliche Integration
Kontinuierliche IntegrationKontinuierliche Integration
Kontinuierliche Integration
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
 
ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice Architekturen
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
 

Mehr von QAware GmbH

Frontends mit Hilfe von KI entwickeln.pdf
Frontends mit Hilfe von KI entwickeln.pdfFrontends mit Hilfe von KI entwickeln.pdf
Frontends mit Hilfe von KI entwickeln.pdf
QAware GmbH
 
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
QAware GmbH
 
50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf
QAware GmbH
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
QAware GmbH
 
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN MainzFully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
QAware GmbH
 
Down the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile ArchitectureDown the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile Architecture
QAware GmbH
 
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
QAware GmbH
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
QAware GmbH
 
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit PlaywrightDer Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
QAware GmbH
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAs
QAware GmbH
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
QAware GmbH
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
QAware GmbH
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
QAware GmbH
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
QAware GmbH
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
QAware GmbH
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
QAware GmbH
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
QAware GmbH
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
QAware GmbH
 

Mehr von QAware GmbH (20)

Frontends mit Hilfe von KI entwickeln.pdf
Frontends mit Hilfe von KI entwickeln.pdfFrontends mit Hilfe von KI entwickeln.pdf
Frontends mit Hilfe von KI entwickeln.pdf
 
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
 
50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN MainzFully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
 
Down the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile ArchitectureDown the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile Architecture
 
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit PlaywrightDer Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAs
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
 

DevOps Prinzipien im Zusammenspiel mit Kubernetes

  • 1. IT-Probleme lösen. Digitale Zukunft gestalten. DevOps Prinzipien im Zusammenspiel mit Kubernetes Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck Inhaltliche Mitwirkung: Dr. Josef Adersberger, QAware GmbH Continuous Release • Feature Rollout • Release Patterns ausführen (siehe Grafiken rechts) Continuous Deployment • Deployment in Production Stage • Post-Deployment Checks • Kompatibilitäts-Tests ... Build + Test + Package + Deploy Wertschöpfungsketten-bezogene KPI DevOps Performance Metrics [2] • Change Lead Time: Code commited to change released to end-users • Deployment Frequency: Deployments to production • Change Fail Rate: Percentages of deployments resulting in degraded service • Time to Restore (MTTR) Flow Metrics [3] • Velocity: Items completed over a given period of time • Efficiency: Item in active state vs. in waiting state from start to completion • Time: Average time between start and completion of an item • Load: Number of items currently in progress • Distribution: Distribution of items of features, defects, risks (SecComp), debt Ergebnis-bezogene KPI • Qualitätsschulden-Analysen und automatisierte Tests [1] • Net Promotor Score [4] • Hypothesen-Tests [5] • User Feedback • Business KPI! [1] https://martinfowler.com/articles/is-quality-worth-cost.html [2] DORA: 2019 Accelerate State of DevOps Report https://cloud.google.com/devops/state-of-devops [3] https://go.tasktop.com/Flow-Metrics-Ebook-Ungated.html [4] https://hbr.org/2003/12/the-one-number-you-need-to-grow [5] David J. Bland, Alex Osterwalder, Testing Business Ideas i Überblick gebräuchlicher Key Performance Indicators (KPI) i Kubernetes Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalie- rung und Verwaltung von Container-Anwen- dungen. Es zielt darauf ab, eine „Plattform für das automatisierte Bespielen, Skalieren und Warten von Anwendungscontainern auf verteilten Hosts“ zu liefern. Es kann so Fla- schenhälse im DevOps Cycle minimieren und Infrastructure as Code für Test- und Produk- tivumgebungen ermöglichen, sowie die au- tomatisierte Erhebung von Telemetriedaten mittels Service Meshs vereinfachen. Code Repository API/CLI horizontal skalierbar Image Registry z. B.. Quay.io, JFrog Artifactory DockerHib, … Service Meshs z.B.. Linkerd, Istio … Deployed Services Container Orchestrator z.B.. Kubernetes, Docker Swarm, Normand, … z. B.. Prometheus, Grafana, ELK-Stack, etc, Telemetriedaten erheben Eine zentrale Telemetrie-Infrastruktur aufbauen Geschäftslogik und Infrastruktur erzeugen verteilte Events, Logs und Metriken, die in einem zentralen Service konsolidiert werden. Anwendungen systematisch loggen Anwendungen müssen ausreichend Telemetrie- daten erzeugen und an die Telemetrie-Infrastruktur angebunden werden. Jedes entwickelte Feature sollte auch geeignet instrumentalisiert werden. Self-Service Zugriff auf Telemetriedaten Damit jeder Probleme auch finden und beheben kann, muss auch jeder Metriken erstellen, generie- ren, anzeigen und analysieren lassen können. Code Code Code Code Code Architektur Eine DevOps-konforme Architektur sollte risikoarme Releases ermöglichen und sich evolutionär von Release zu Release weiterentwickeln lassen. Eine Architektur sollte aus lose gekoppelten autonomen Komponenten bestehen, die von autarken Teams betreut und betrieben werden können und kleine Batches von Entwicklungen zulassen. Automatisierte Tests Eine Deployment-Pipeline stellt sicher, dass jeglicher Code der in die Versions- verwaltung eingecheckt wird, automatisch gebaut und in einer produktivähnlichen Umgebung mittels automatisierter Unit-, Akzeptanz-, Integrationstests und Post- Deployment-Checks getestet wird. So lassen sich Build-, Test- oder Integrati- onsfehler bereits beim Einführen einer Änderung erkennen und beheben. Resul- tierender Code ist immer in einem auslie- ferbaren Zustand. Releaserisiken reduzieren Umgebungsbasierte Release-Strategien: Beim Blue/Green Deployment hat man zwei Produktiv-Releases. Doch nur eines bedient Kunden. Funk- tioniert ein Release nicht, kann notfalls auf das funktionierende Release zurückgeschaltet werden. Canary-Releases funktionieren ähnlich, nur werden Features erst wenigen, und dann sukzessive immer mehr Nutzern bereitgestellt. Sollten Probleme auftreten, wird wieder zurück gerollt. Bei Rolling-Updates werden Deployment Units inkrementell aktualisiert. Anwendungsbasierte Releases: Feature Schalter ermöglichen das selektive ein-/ausschalten von Features abhängig von Last oder sons- tigen Erwägungen. Features können notfalls auch wieder abgeschaltet werden, wenn diese sich nicht bewähren. DevOps Prinzipien des Feedback i Continuous-Begriffe Continuous Delivery • Deployment in QA Stage • Akzeptanztests • Performance-Tests ... Feature schafft Mehrwert für Nutzer Continuous Integration Shift Left QS (frühes Testen): • statische Analyse • Unit Tests • Kompatibilitätstests • License Checks • Vulnerability Analysis … Code-Änderung API/CLI t t FLASCHENHÄLSEMINIMIEREN Flaschenhälse folgen häufig diesen Mustern: • Langwieriges (manuelles) Erstellung von Test- und Produktiv- Umgebungen => Erstellung von Umgebungen im Self-Service auf Anforderung. • Langwieriges (manuelles) Code-Deployment => Automatisiertes Deployment mittels Deployment Pipelines. • Langwieriges (manuelles) Einrichten und Durchführen von Tests => Automatisiertes und parallelisiertes Testen, so dass die Testrate mit der Code-Entwicklungsrate mithält. • Zu stark gekoppelte Architekur (lokale Änderungen müssen mit vielen abgestimmt werden) => Lose gekoppelte Architektur (z.B. Microservices) um Änderungen sicherer und mit mehr Autonomie durchführen zu können. WORKINPROCESSBESCHRÄNKEN Unterbrechungen sind bei der Herstellung physischer Güter sehr kostenintensiv, denn häufig muss die aktuelle Arbeit abgebrochen, ggf. entsorgt und Maschinen umgerüstet werden. Das Unterbrechen von Technologiemitarbeitern ist ebenfalls teuer, allerdings wesentlich einfacher (ein Anruf, eine Mail, eine Nachricht, etc.). Studien haben gezeigt, dass sich die Zeit zum Erledigen selbst einfacher Aufgaben (wie dem Sortieren geometrischer Formen) beim Multitasking deutlich verlängert. Multitasking sollte daher reduziert werden, indem man Obergrenzen für Kanban-Spalten (Arbeitsstationen) festlegt und die Anzahl an Spalten (Übergaben) möglichst klein hält, um zu vermeiden, dass zwischen zu vielen Schritten und Kontexten hin und her gesprungen wird. DevOps Prinzipien des Flow ARBEITSICHTBARMACHEN Bei Technologiearbeit (anders als in der Produktion) kann Arbeit häufig mit einem „Mausklick“ bewegt werden. Weil das so einfach ist, werden manche Arbeitspakete zwischen Teams wie Pingpong hin und her bewegt, ohne das nennenswerter Wert erzeugt wird oder dies im Arbeitsalltag unmittelbar auffällt. Um zu erkennen, wo Arbeit gut fließt und wo nicht, kann man auf visuelle Arbeitsboards (z.B.. Kanban-Boards) zurückgreifen. Ein Kanban-Board sollte immer die gesamte Wertkette umfassen, d.h. bis ein Feature in einer Anwendung erfolgreich produktiv läuft. Telemetriedaten erheben Je länger Entwickler isoliert in Branches arbeiten, desto (exponentiell) schwieriger wird es, alle Änderungen wieder zusammenzuführen. Continuous Integration hat daher zum Ziel, die Entwick- lungsbranches einzelner Entwickler mittels Trunk- basierter Entwicklungspraktiken und kleinen Batch- größen idealerweise täglich zusammenzuführen. Commits, die sich dabei nicht automatisiert deployen lassen, sollten auch nicht in die Versionsverwaltung eingecheckt werden können. Continuous Integration A/B-Tests sind eine Testmethode zur Bewertung von Varianten eines Systems, bei der die Originalversion gegen leicht veränderte Versionen getestet werden. Ziel ist Nutzerreaktionen mit einer Kontrollgruppe zu vergleichen. A/B-Tests in Feature-Testing integrieren In modernen UX-Praktiken werden häufig Besuchern einer Website eine von zwei Versionen einer Seite angezeigt. Mittels einer statischen Analyse des Folgeverhaltens (Conversion Rates) kann objektiv geprüft werden, ob eine Änderungen einen Effekt im Nutzerverhalten gebracht hat, oder nicht. Mit Hilfe von Feature-Schaltern lässt sich genau steuern wie groß der Anteil von Kun- den ist, die eine Testversion eines Experiments erhalten. Hypothesengetrieben entwickeln Mit Statistik potenzielle Probleme erkennen Probleme können bei normalverteilten Ereignissen mit einfachen aber be- währten statistischen Verfahren (wie Mittelwert und Standardabweichung) identifiziert werden. Unterliegen Ereignisse keiner Normalverteilung kann man auf glättende Verfahren (gleitende Durchschnitte), periodische/saisonale Verfahren (Kolmogorow-Smirnow, etc.) zurückgreifen. Nur bei signifikanten Ereignissen automatisiert warnen Entfernen sich Metriken statistisch signifikant von ihren Normalwerten, so sollten automatisierte Warnungen ausgelöst werden, da dies Vorboten eines Produktivzwischenfalls sein können. Hierfür ist solides statistisches Wissen über die Verteilung entsprechender Ereignisse erforderlich. Telemetriedaten analysieren Telemetriedaten erhebenTelemetriedaten erheben A B Telemetry Service Rolling Upgrade 1. 2. 3. Canary Releases traffic traffic Capacity Production traffic t Blue/Green Deoloyment traffic Hot Standby 1. AVB Testing 2. Rolling Upgrade 3. Blue/Green DevOps ist die Kultur, die Entwicklung (Dev) und den Betrieb (Ops) von Anwendungen besser mitei- nander zu integrieren, um kurze Release-Zyklen, zuverlässige Inbetriebnahmen und eine hohe Ver- fügbarkeit zu erreichen. Dies wird durch eine ver- besserte Kooperation und einen höheren Automa- tisierungsgrad erreicht. i DevOps Release Patterns PROBLEMESOFORTLÖSEN Werden Probleme im Produktivsystem erkannt, sollte die Problemlö- sung höhere Priorität als die weitere Entwicklung von Features be- kommen. Die Entwicklungspipeline sollte gestoppt werden. Probleme sollten nie umgangen werden oder deren Lösung verschoben werden, um zu vermeiden, dass sich ein Problem fortsetzt und zu exponentiell steigendem Aufwand für dessen Behebung zu einem späteren Zeit- punkt führt. Damit dies funktioniert ist eine fehlerverzeihende Kultur erforderlich, die die Lösung des Problems in den Mittelpunkt stellt und nicht den Verursacher zur Rechenschaft zieht. PROBLEMEFRÜHERKENNEN Komplexe Systeme sind nicht vollständig von einer einzelnen Person überschau- und verstehbar, da sie aus einer Vielzahl eng miteinan- der verbundener Komponenten bestehen, deren Wechselwirkungen nicht immer vorhersehbar sind. Daher sollten Annahmen, die beim Design getroffen wurden, kontinuierlich geprüft werden. Z.B.. durch Experimentieren mit einem Softwaresystem in der Produktion (Chaos Engineering), um Vertrauen in die Fähigkeit des Systems aufzubauen, turbulenten und unerwarteten Bedingungen standzuhalten. Ferner benötigt man für Feedback-Schleifen im Produktivsystem kontinuier- lich und automatisiert erhobene Telemetriedaten. PROBLEMEPROFESSIONELL VERANTWORTEN Erstaunlicherweise erhöht in komplexen Systemen das Hinzufügen zusätzlicher Kontrollschritte und Genehmigungsprozesse die Wahr- scheinlichkeit für zukünftige Fehler, da Entscheidungen von Personen getroffen werden müssen, die weit weg vom Problemraum sind. Besser ist es, wenn Entwickler Verantwortung auch für den operati- ven Betrieb haben (you build it, you run it). Dadurch liegt die Verant- wortung für Qualität, Zuverlässigkeit sowie die Entscheidungsbefug- nis dort, wo auch die Arbeit erledigt wird und die meiste technische Expertise vorhanden ist. Durch dieses direkte Feedback aus Ops wird das Lernen im Devs beschleunigt und zukünftige Probleme sind bes- ser abschätzbar und konstruktiv vermeidbar. ! ?