Continuous Delivery. Lessons (Not) Learned.

Transcript

1. Continuous Delivery. Lessons (Not) Learned. @spanneberg XP Days 2015
2. 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
3. TL;DR 3
4. 4 Continuous Delivery ?
5. 5 Continuous Delivery ? Jenkins vs. Bamboo vs. ... Private Cloud! Docker FTW!!!11! Puppet/Chef/Ansible ... Microservices Phoenix Server DevOps
6. 6 Continuous Delivery ? Kultur Prozesse Commitment aller Beteiligten Architektur Management- Rückhalt Strategie
7. Erfahrungsberichte 7 Ausgangssituation → Verlauf → Lehre
8. Story 1: Das Datingportal 8 Ausgangssituation: → Legacy Codebase (CORBA anyone?) → Modernisierungen → Dev-getriebene Einführung Continuous Delivery
9. 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
10. 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.
11. 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
12. 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”)
13. 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
14. 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
15. 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
16. Story 3: Die Hotelsuchmaschine 16 Ausgangssituation: → (Greenfield) Rewrite bestehender Platform (Legacy Code und Braindrain) → Devs im “Elfenbeinturm” → Ops beschäftigt mit Tagesgeschäft
17. 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
18. 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. 19 Diskussion
20. 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
21. Danke! 21 Feedback: bastian.spanneberg@codecentric.de @spanneberg