Post on 14-Jul-2020
transcript
Continuous Delivery. Lessons (Not) Learned.
@spannebergXP Days 2015
Vorstellung
2
• Java Dev turned Automation Junkie
• CI/CD/Automation seit ~2007:Ant, Maven, Gradle, Bash, Jenkins, Puppet, Ansible, ...
• Banken, IT-Diensleister, Web-Platformen
• @codecentric München
TL;DR
3
4
Continuous Delivery ?
5
Continuous Delivery ?
Jenkins vs. Bamboo vs. ...
Private Cloud!
Docker FTW!!!11!
Puppet/Chef/Ansible ...
Microservices
Phoenix Server
DevOps
6
Continuous Delivery ?
Kultur
Prozesse
Commitment aller Beteiligten
ArchitekturManagement-Rückhalt
Strategie
Erfahrungsberichte
7
Ausgangssituation → Verlauf → Lehre
Story 1: Das Datingportal
8
Ausgangssituation:
→ Legacy Codebase (CORBA anyone?)→ Modernisierungen→ Dev-getriebene Einführung Continuous Delivery
Story 1: Das Datingportal
9
Verlauf:
→ Legacy Code → Legacy Pipeline→ Umsetzung (exkl.) duch 2 Mitarbeiter (dev)→ Feature-Druck nach 1. laufender Version→ Mitarbeiter machen wieder andere Dinge→ Probleme in der Pipeline. Probleme für alle.→ Ops zu wenig/zu spät mit im Boot. Keine gemeinsame Team-Mentalität
Story 1: Das Datingportal
10
Lehre:
Die Umsetzung von Continuous Delivery ist keine einmalige Angelegenheit
→ Reviews und Evaluierung neuer Techniken und Vorgehen→ Behandle deine CD-Pipeline und Infrastruktur wie deinen Code→ Wissen in den Teams. Bestenfalls kein CD-Team.
Story 1: Das Datingportal
11
Lehre:
Continuous Delivery braucht Rückhalt im Management
→ Bereitschaft Leuten Zeit für das Thema einzuräumen und kontinuierlich Zeit zu investieren→ Impact auf Teams ausserhalb Dev und Ops
Story 2: Die Bank
12
Ausgangssituation:
→ Management-Entscheidung: “Wir machen jetzt Scrum und Agile”→ Silo-Teams (HW, OS, VMs, DB, Ops, Dev1..n, Test, …)→ Orga: Projekt vs. Produkt→ (Nicht-) Entscheidungskultur (“das muss dann jmd entscheiden”, “da müssen wir noch einen Termin machen”)
Story 2: Die Bank
13
Verlauf:
→ Projekt zur Einführung = Wasserfall-Projekt (O RLY?)→ Silo-Teams für Einzel-Themen (Prozess, VCS+CI, DB, Testing, ...)→ fehlender Wille (Möglichkeit?) sich Prozessuell zu verändern→ am Besten selber Prozess wie vorher, nur alle 2 Wochen
Story 2: Die Bank
14
Lehre:
Continuous Delivery muss vom Team gewollt sein
→ Top-Down-Entscheidungen oft zum scheitern verurteilt→ bei CD müssen Teams/Einzelne mehr/neue Verantwortungen übernehmen und sich verändern wollen→ lieber in kleinen Teilen/Iterationen bottom-up arbeiten
Story 2: Die Bank
15
Lehre:
Continuous Delivery erfordert Veränderungen an Prozessen und Kultur/Organisation
→ wenn man auf einen schwergewichtigen Prozess wert legt sollte man es sich mit CD gut überlegen→ Impact auf die ganze Organisation
Story 3: Die Hotelsuchmaschine
16
Ausgangssituation:
→ (Greenfield) Rewrite bestehender Platform (Legacy Code und Braindrain)→ Devs im “Elfenbeinturm”→ Ops beschäftigt mit Tagesgeschäft
Story 3: Die Hotelsuchmaschine
17
Verlauf:
→ Team hat sich verspielt→ Keine You-build-it-you-run-it-Mentalität im Dev-Team→ Ops bei Rewrite nicht früh mit im Boot→ Resultat: enge Kopplung und Schwierigkeiten im realen Betrieb
Story 3: Die Hotelsuchmaschine
18
Lehre:
Continuous Delivery löst nicht deine Architektur-Probleme
→ Build / Deployment / Orchestrierung … sollten als 1st Class Citizens behandelt werden
19
Diskussion
Bildquellen
20
• https://www.flickr.com/photos/rdecom/4968163345• https://www.flickr.com/photos/slayerx/3330554699• https://www.flickr.com/photos/16210667@N02/8011900493• https://upload.wikimedia.org/wikipedia/commons/c/c0/I_want_you.jpg
Danke!
21
Feedback:
bastian.spanneberg@codecentric.de
@spanneberg