Continuous Delivery ist keine Technologie (W-JAX 2013)

1. Continuous Delivery ist keine Technologie Marco Kisperth, Jörg Müller
2. Marco Kisperth der Product Owner @kisperth Jörg Müller der Techniker @joergm
3. Unser Product Owner hatte eine Vision!
4. Update der Anwendung mindestens
 einmal pro Stunde möglich
5. Features werden während der Umsetzung laufend ausgerollt
6. Ein System für Produktion, Akzeptanz, Preview und Schulung
7. Wir hatten erstmal gewaltige Zweifel!
8. „Jeder Commit automatisch auf Produktion!“
10. Wer bezahlt den Aufwand für die automatisierte Testabdeckung?
11. Wie soll so ein automatisches Deployment funktionieren?
12. Jetzt sollen If-Bedingungen für neue Features in den Code?
13. Warum wollte der Product Owner so etwas?
14. Nur ein genutztes Feature
 ist ein gutes Feature
15. Keine goldenen Wasserhähne
16. Features in kleinen Schritten zur Verfügung stellen
17. Weniger Komplexität
18. Mehr Zufriedenheit
19. Was mussten wir tun, damit es funktioniert?
20. Kein extra QA
21. Operations im Team
22. Support durch Business Analysten und Developer
23. Alle Verantwortung und Fähigkeiten mussten in ein Team
24. Technologisch brauchten wir eine Deployment Pipeline
25. Automatisierte Test-Stages aber nur ein Stage für Menschen
26. Der Test-Modus ersetzt das Preview- System test
27. Feature Switches sind nötig, aber seltener, als man denkt
28. Kanban statt Scrum pull
29. Commanders Intent
 Acceptance Tests Kommunikation ! keine detaillierte Spezifikation !#?
30. Community mit Anwendern und Entscheidern aufbauen
31. Anwendungs-Controlling
32. Die Anwendung informiert selber
 über Änderungen neu
33. Wie weit sind wir damit gekommen?
34. 500.000 Zeilen Code
 (Java, Javascript, Groovy, XML, HTML)
35. 21.000 Unit Tests & 400 Selenium Test
36. Fehler schnell beheben ist wichtiger als vermeiden
37. 17 „Entwickler“, 3 BA, 1 UX, 1 PO
38. Klassische Rollenbilder gemischt
39. Was hat es in uns verändert?
40. „Das ist mein Produkt“
41. Test Driven Development
42. Refactoring in small steps
43. Agile Methoden und Continous Delivery greifen perfekt ineinander!
44. Keine Abstimmung zum Rollout nur Freischalten ist Entscheidung des Product Owners
45. Feature oder Bugfix Wo ist der Unterschied?
46. Neue Prioritäten für Bugfixes/Findings Quickwins first
47. Hard-Coded ist die neue Konfigurierbarkeit
48. Was sind die Voraussetzungen?
49. „Einfach“ beginnen Es gibt kein „Fertig“
50. „Seniore“ Teammitglieder
51. Ohne Disziplin geht es nicht
52. Nein sagen! Der Sog zum klassischen Vorgehen wird stark sein
53. Eigenverantwortung muss gewollt und möglich sein
54. Haben sich die Erwartungen erfüllt?
55. JA!
56. Themen können technisch und fachlich fertiggestellt werden!
57. Continuous Delivery ist ein Mindshift
58. Marco Kisperth marco@kisperth.de @kisperth Jörg Müller joerg.mueller@hypoport.de @joergm blog-it.hypoport.de Vielen Dank an Verena Würfel für die Erstellung der Grafiken