SlideShare ist ein Scribd-Unternehmen logo

DevOps Prinzipien im Zusammenspiel mit Kubernetes

QAware GmbH
QAware GmbH
QAware GmbHQAware GmbH

Fachposter, 2020: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Technische Hochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM). Bestellbar unter https://www.sigs-datacom.de/order/poster/DevOps_Prinzipien-Kubernetes.php (Dokument bitte herunterladen für bessere Lesbarkeit)

DevOps Prinzipien im Zusammenspiel mit Kubernetes

1 von 1
Downloaden Sie, um offline zu lesen
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.
!
?

Recomendados

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8sKontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8sQAware GmbH
 
Per Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API GatewaysPer Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API GatewaysQAware GmbH
 
Dataservices - Data Processing mit Microservices
Dataservices - Data Processing mit MicroservicesDataservices - Data Processing mit Microservices
Dataservices - Data Processing mit MicroservicesQAware GmbH
 
Mit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-LösungMit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-LösungQAware GmbH
 
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 NormalQAware GmbH
 
Kubernetes ist so viel mehr als ein Container Orchestrierer
Kubernetes ist so viel mehr als ein Container OrchestriererKubernetes ist so viel mehr als ein Container Orchestrierer
Kubernetes ist so viel mehr als ein Container OrchestriererQAware GmbH
 
Legacy-Software-Refactoring - Zielsetzungen für ein erfolgreiches Refactoring...
Legacy-Software-Refactoring - Zielsetzungen für ein erfolgreiches Refactoring...Legacy-Software-Refactoring - Zielsetzungen für ein erfolgreiches Refactoring...
Legacy-Software-Refactoring - Zielsetzungen für ein erfolgreiches Refactoring...Alex Sili
 

Más contenido relacionado

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 NightChristinaLerch1
 
Dev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei TechnosoftDev ops testautomatisierer bei Technosoft
Dev ops testautomatisierer bei TechnosoftBart 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 seinStephan 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 KapsStephan Kaps
 
In den sicheren Hafen jax2020
In den sicheren Hafen jax2020In den sicheren Hafen jax2020
In den sicheren Hafen jax2020Stephan Kaps
 
Kaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment RoadmapKaps - Continuous Deployment Roadmap
Kaps - Continuous Deployment RoadmapStephan Kaps
 
DevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der SchieneDevOps - Mehr Geschwindigkeit auf der Schiene
DevOps - Mehr Geschwindigkeit auf der SchieneVorname Nachname
 
Migration zum Zend Framework 3
Migration zum Zend Framework 3Migration zum Zend Framework 3
Migration zum Zend Framework 3Ralf 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-UmfeldQAware 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 InfrastrukturQAware 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
 
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 NormalQAware GmbH
 
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-Prozessx-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-PipelinesTobias 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-AnwendungenGjero 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 EntwicklungsperformanceOPEN 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 entwickelnMartin 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 LifeKremer 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 OWBMinerva 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 DevOpsmatfsw
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testenmradamlacey
 
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 CloudAarno 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 EntwicklungChristian 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 AnalyticsFabian 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 automatisierungstechnikAUVESY
 
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.pdfDNUG e.V.
 
Kontinuierliche Integration
Kontinuierliche IntegrationKontinuierliche Integration
Kontinuierliche IntegrationJohannes Weber
 
ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“QAware GmbH
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice ArchitekturenLeo 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

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 ArchitectureQAware 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 EngineeringQAware 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 PlaywrightQAware GmbH
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAsQAware 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
 
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 ZAPQAware 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
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysQAware 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
 
How to speed up Spring Integration Tests
How to speed up Spring Integration TestsHow to speed up Spring Integration Tests
How to speed up Spring Integration TestsQAware 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-ClusterAus 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-ClusterQAware GmbH
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertQAware GmbH
 
Policy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentPolicy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentQAware 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 EngineeringQAware GmbH
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisQAware GmbH
 

Mehr von QAware GmbH (20)

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!
 
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
 
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.
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API Gateways
 
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
 
How to speed up Spring Integration Tests
How to speed up Spring Integration TestsHow to speed up Spring Integration Tests
How to speed up Spring Integration Tests
 
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-ClusterAus 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
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniert
 
Policy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy AgentPolicy Driven Microservices mit Open Policy Agent
Policy Driven Microservices mit Open Policy Agent
 
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
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
 

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. ! ?