Slide 1

Slide 1 text

Continuous Delivery. Lessons (Not) Learned. @spanneberg XP Days 2015

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

TL;DR 3

Slide 4

Slide 4 text

4 Continuous Delivery ?

Slide 5

Slide 5 text

5 Continuous Delivery ? Jenkins vs. Bamboo vs. ... Private Cloud! Docker FTW!!!11! Puppet/Chef/Ansible ... Microservices Phoenix Server DevOps

Slide 6

Slide 6 text

6 Continuous Delivery ? Kultur Prozesse Commitment aller Beteiligten Architektur Management- Rückhalt Strategie

Slide 7

Slide 7 text

Erfahrungsberichte 7 Ausgangssituation → Verlauf → Lehre

Slide 8

Slide 8 text

Story 1: Das Datingportal 8 Ausgangssituation: → Legacy Codebase (CORBA anyone?) → Modernisierungen → Dev-getriebene Einführung Continuous Delivery

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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”)

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Story 3: Die Hotelsuchmaschine 16 Ausgangssituation: → (Greenfield) Rewrite bestehender Platform (Legacy Code und Braindrain) → Devs im “Elfenbeinturm” → Ops beschäftigt mit Tagesgeschäft

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Story 3: Die Hotelsuchmaschine 18 Lehre: Continuous Delivery löst nicht deine Architektur- Probleme → Build / Deployment / Orchestrierung … sollten als 1st Class Citizens behandelt werden

Slide 19

Slide 19 text

19 Diskussion

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Danke! 21 Feedback: [email protected] @spanneberg