129 lines
4.8 KiB
Markdown
129 lines
4.8 KiB
Markdown
# Vortrag "Chaos Engineering"
|
|
- BUgra Derre von Dailmer TSS
|
|
- Daimler TSS -> Freitag Nachmittag frei für eigene Projekte
|
|
|
|
Sinnbild:
|
|
Der Affe stört SW-Engineers happy life. Er sorgt für chaotische Zustände
|
|
|
|
Lustige Frage: Wer würde sich trauen einen Herzschrittmacher für sich selbst zu programmieren , kaum Hände oben ;-)
|
|
|
|
Leslie Lamport:
|
|
Systemausfälle als Regel.
|
|
Verteilte Systeme führen dazu das das eigene System nicht mehr funktioniert, transitive unbekannte Abhängigkeiten!
|
|
|
|
|
|
Chaos kann man trainieren.
|
|
Chaos erzeugt nicht fehler es deckt sie auf.
|
|
|
|
Phasen des chaos
|
|
- Hypothesen formulieren (Szenarien)
|
|
- Experimentieren veränderungen vornhemen z.B. Latenzen einführen
|
|
- lernen
|
|
- anpassen
|
|
|
|
Methodik eher für Cloud Dienste?
|
|
Buchempfehlung - Release It
|
|
Gamedays - Vollautomatische Durchführung von Chaos tests die z.B. ein Team Treffen
|
|
-> SH ist unser Monkey ;-)
|
|
Schon durch das blosse durchdenken der Experimente können Fehler gefunden werden bzw. man erkennt ohne Experiment dass es fehlschalgen wird.
|
|
|
|
|
|
# Embedded raus aus dem Bett (Bosch) Harald Göttlicher
|
|
Cooler/ Netter Typ, Bosch Kollege , Zuständig für Coninous Delivery
|
|
Embedded Entwicklung hat spezielle Anforderung z.B. Hardwarebindung
|
|
|
|
Wer wenig oft liefert macht viel manuel und ist ineffizient
|
|
Niedriger Durchsatz
|
|
Hohe Fehlerraten weil große Releases mehr Inhalt haben was zum mehr Komplexität bedeutet
|
|
Aussagen basieren auf einem Report -> siehe state of devops report
|
|
|
|
Lernen von DevOps, passen diese Methoden für Embedded?
|
|
|
|
Vision : Monolithen in ganz viele einzelne Kompnenten aufteilen -> Microservices
|
|
Wir brauchen einen Paradigmenwechsel von Schichtenarchitektur zu Komponentenarchitektur für einzelne Funktionen. Schneide kleiner als du gedacht hast.
|
|
Viele Komponenten bedueten viel Aufwand für Automatisierung -> Lösung Automatisierung der Automatisierung. Es gibr auch tools dafür z.B. Ansible , Chef , Puppet
|
|
Umgebungen zum bauen in Container kapseln.
|
|
|
|
Der näcshte Schritt man denknt nicht mehr in layern sonder in Komponenten.
|
|
Inkrementeller Build, es wird eine BOM von letzter Version gemacht und ein Diff zur aktueller gemacht, es werden nur aktualiesierte Artefakte aktualisiert.
|
|
|
|
Tests müssen passend zu Komponenten geschnitten werden.
|
|
|
|
|
|
# Implementation Patterns Dr. Frank Gerhardt
|
|
Buch Implementation Patterns von Kent Beck
|
|
Implementation Patterns sind zwischen Desgin PAtterns und Style Guide
|
|
|
|
andere Leute sind wichtig , andere Perspektiven Berücksichtigen. So programmieren dass andere den Code auch verstehen.
|
|
|
|
Programmieren is wie Jeopodardy.
|
|
|
|
3 Werte & 6 Prinzipien:
|
|
|
|
## Werte
|
|
- Kommunikation , liteerate programming,
|
|
- Simplicity, keine goldenen Wasserhähne
|
|
- Flexibiiliät, kann auch missbraucht werden, es macht vorab keinen Sinn vorab zuviel zu abstrahieren. Keep options open
|
|
|
|
## Prinzipien
|
|
- locale consequences
|
|
- keine wiederholung
|
|
- logik anda data together
|
|
- symmetrie / Integriät
|
|
- ..
|
|
|
|
Kosten für code entstehen nicht in der Entwicklung sondern später beim erweitern und pflegen
|
|
|
|
Conditional, if / if / if / else sollten symmetrisch sein
|
|
|
|
Gemeinsame sprache entiwcklen verinfacht feedback in Code Reviewees
|
|
|
|
Message pattern: compute() input,process,output
|
|
|
|
single exit , nicht mehr relevant heute
|
|
|
|
|
|
Erkenntnis: Implementation pattterns viel wichtiger als Programmiersprachen Konzepte ( lambdas, predicates,)
|
|
|
|
|
|
# DSL mit Kotlin FRank Scheffler
|
|
Code in Github
|
|
Kotlin Konzepte: val macht immutable variablen, keine null Zuweisung wenn überhaupt denn Deklaration Fragezeichen?
|
|
String templating
|
|
Man Klassen Funktionen andichten (Extension Functions)
|
|
|
|
|
|
|
|
# Dr. Elmar Juergens / Meine Erfahrungen aus 10 Jahre Entwicklung von Qualitätsanalysen
|
|
- Gründer von Firma welche Qulaitätsanalysesoftware erstellt / nutzt
|
|
|
|
Software Inelligence
|
|
Test Gap Analyse -
|
|
Tickets können auch als Datenquelle zur Priosierung von zu testenden Modulen verwendet werden.
|
|
|
|
Die Herausforderung ist die Testfälle zu identifizieren die den geänderten Code durchlaufen. Optimiert den Testdurchlauf hinsitlich zeit.
|
|
Beim REview muss der Test nachgewiesen werden.
|
|
|
|
Nur auf dem master/develop branch alle tests durchführen, auf dem feature brach reicht es aus nur die impaktierten TEsts auszuführen, bei uns dauert es 20 Minuten und es wird immer gebaut.
|
|
|
|
|
|
Code peer reviews:
|
|
Review abgeschlossen wenn alle Probleme abgeschlossen sind.
|
|
Unit of review ist ticket! Jira Zustand für REview und Rework
|
|
|
|
Nutzen von Reviews:
|
|
- Code wird besser es kommt nichtmal drafau an funktionale FEhler zu finden
|
|
- Haupfaktor Wissenstransfer
|
|
|
|
|
|
|
|
# Zum Nachschlagen
|
|
- Kubernetes
|
|
- Circuit Breaker Pattern, wiederkehrende Verbindung die erfolglos sind behandeln -> fallback lösung
|
|
- Wie testet man einzelne Bundles?
|
|
- Dokumentation der einzelnen Bundles mit Sinn und Schnittstellen
|
|
- Mit Kotlin experimentieren
|
|
- Mit Predicates arbeiten
|
|
- Funktionale Interfaces
|
|
- Generics
|
|
- DSL Buch Fowler |