In diesem Vortrag erfahren Sie, warum sich der erste Ansatz einer zentralen CI/CD-Installation für alle Teams als problematisch erwies und durch dezentrale Pipelines ersetzt wurde. Danach lernen Sie die Tücken unserer Einführung einer eingekauften API-Management-Lösung kennen, und wieso sich der Kauf von großer On-Premise-Software nur schwer mit den agilen Prinzipien vereinbaren lässt. Der Zuhörer lernt zudem, wie wir im Team mit polyglotter Softwareentwicklung zu kämpfen haben und wie wir permanent gegen Wissensinseln ankämpfen. Zuletzt gehe ich darauf ein, wie wir mit umfassender Architekturdokumentation gestartet und gescheitert sind. Unser neuer Ansatz ist eine leichtgewichtige dezentrale Dokumentation mit AsciiDoc und ein im Team abgestimmter Toolstack, der auch vom Zuhörer adaptiert werden kann. Am Ende der Reise wird der Zuhörer einige Methoden und Tools kennen gelernt haben, um in einem Kontext zu überleben, der an vielen Stellen noch von klassischen Prozessen dominiert wird. Aber eines ist klar: Der Weg Richtung DevOps geht nicht plötzlich, es ist eine Reise mit Umwegen und Hindernissen. Die Reise ist es aber auf jeden Fall Wert!
4. Unsere Mission als Plattform
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB
Innovationsgeschwindigkeit erhöhen
API Ökosystem betreiben
Wissensaufbau für Developer im
Bereich Cloud/K8S
4
9. You build it, you run it, you are responsible
Lilienthal, Carola. Langlebige Software-Architekturen: Technische Schulden analysieren, begrenzen und abbauen.
dpunkt. verlag, 2019.
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 9
10. Jeder muss alles können!
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 10
14. 14
Beispiel für Team-Tool-Entscheidung
-> Diagramme
ü Speichern aller Diagramme als .drawio.png in Git
Repositories
ü Quelldatei=Zielformat
ü Zugriff für jeden auf jedem Endgerät
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB
15. 15
Beispiel für Einzel-Tool-Entscheidungen
-> Code Dev Tools
q Keine Projektdateien in Git
q .editorconfig (https://editorconfig.org/)
q Projekt muss ohne IDE ausführbar sein
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB
23. 23
Einführung von COTSS
v Tätigkeiten dauern seit ca. 27 Monaten an
v Bisher kein produktiver Nutzen
v Qualitätsprobleme
v Microservicearchitektur die durch komplizierte Automatisierung gemanaged wird
v DB hat den Hersteller dazu “überredet” OpenShift zu unterstützen
v Mehrfach Probleme entdeckt, die nur in OpenShift auftreten, da der Hersteller
den Support zwar zugesichert hat, aber nicht von Anfang an geplant hatte
v Abbruch der Installation auf OpenShift à Entscheidung für AWS EKS
v Viele “Monsterstories”, da das Zerteilen der technischen Integrationsaufgaben in
kleinere Stories häufig nicht sinnvoll möglich war. -> Wochenlange Laufzeit.
v Fehler die nicht nachvollziehbar waren, nur bei uns auftraten, und meistens nur in
Produktion.
v Ohne Konfigurationsänderungen unsererseits
Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB