"Continuous Delivery - Nett oder nötig?" Der Erfahrungsbericht der FriendScout24 ist ein Update des aktuellen Standes im Umgang mit Continuous Delivery. Der Vortrag beleuchtet Business Reasoning, Vorgehen, Probleme und Herausforderungen und den Umgang mit unterschiedlichen Stacks.

1. www.friendscout24.de
Continuous Delivery
Nett oder nötig?
Michael Maretzke

2. Michael Maretzke
FriendScout24
Vice President Technology
michael.maretzke@friendscout24.de
twitter: @mmaretzke

4. „Full-Service“ für alle ernsthaften Beziehungen
FriendScout24 - für die Suche nach
dem richtigen Partner
Flirten
-
Aktive Suche
Dateroulette
Lebenspartner
- Wissenschaftlicher
Test mit Matching
Abenteuer
Das erste PremiumCasual-Dating Portal
speziell für die Frau
-
Auch verfügbar
- iOS-/Android-App
- Facebook-App
-
Diskretion durch
Maskentool
Sicherheit mit
Jugendschutzpixel
Seriös

9. Product
Manager
Product
Owner
UX Designer
Lead
Engineer
Scrum
Master
SW Engineer SW Engineer
SW Engineer SW Engineer
QA Manager
KANBAN
SCRUM
AGILE

10. Kerngeschäft
Wachstumsfelder
Bewährtes
Businessmodell
Neue
Businessmodelle
8 Jahre erprobte
Architektur
Leading EdgeTechnolgies

11. How do we
increase
the odds of
our success?

12. Warum
Continuous
Delivery?

13. AUTOMATION.
Jez Humble, David Farley: „Continuous Delivery“, Addison-Wesley, ISBN 9780321601919, Seite 17

14. LEAN Product Development
Entrepreneurs are Everywhere
Entrepreneurship is Management
Validated Learning
Innovation Accounting
Build-Measure-Learn

15. Warum LEAN Product
Development?
Build
Learn
Measure

16. Fail early, learn fast.

17. Continuous Delivery
@ FriendScout24
Continuous
Live
Deployment

18. Online Dating Plattform „FriendScout24“
●
●
●
●
●
●
Architektur? Gewachsen.
Release? Restart.
Backend und Frontend? Abhängigkeiten.
Redundanz? Nicht alle relevanten Elemente.
Aufwand? Sehr groß.
Automatisierung? Schon davon gehört.

19. Casual Dating Plattform „Secret“
●
●
●
●
●
●
Architektur? Neu.
Release? Painless.
Backend und Frontend? Geregelt.
Redundanz? Yes.
Aufwand? Adäquat.
Automatisierung? Yes.

20. 2013
2012
2011
Continuous Live Deployment
Past | Present | Future
…

21. 2011-2012
low hanging fruits

22. Continuous Live Deployment @ FRS24
2011
●
●
●
●
Agile Methode? SCRUM.
Release Cycle? 3 Wochen.
QA-Zeit? 2 Tage.
Unit-Tests? Wenige.
Oktober 2011
Assessment
@FRS24
Brain Storming
1)
2)
3)
4)
5)
6)
7)
8)
9)
…
…
…
…
…
…
…
…
…
TODO-Liste
@FRS24
Setup CLD
Team

23. Continuous Live Deployment @ FRS24
2012
●
●
●
●
Agile Methode? Kanban.
Release Cycle? Jeden 2. Tag.
QA-Zeit? 5 Stunden.
Unit-Tests? Mehr – aber immer noch wenig.
@FRS24
CLD-Team
1)
2)
3)
4)
5)
6)
7)
8)
9)
…
…
…
…
…
…
…
…
…
TODO-Liste

24. Continuous Live Deployment @ FRS24
2012
●
●
●
●
Agile Methode? Kanban.
Release Cycle? Jeden Tag.
QA-Zeit? 3 Stunden.
Unit-Tests? Noch mehr – aber immer noch wenig.
Seite 24
Titel der Präsentation | Autor der Präsentation

25. Release Delivery Time
2012

26. Zeitdauer UAT-Läufe
2012

27. Unit Test Coverage
2012

28. Build-Pipeline
2012

29. Wie?
●
●
●
●
●
Build-Pipeline? Komplett erneuert.
CI-Umgebung? Komplett erneuert (Jenkins).
UAT-Läufe? Optimiert (Selenium parallelisiert).
Code? Aufgeräumt.
Architektur? Wenig Änderung.
März 2012

30. 2012 - 2013
BIG BLOCKS
BIG BLOCKS

31. BIG BLOCKS
4 Dimensionen zum Erfolg
Organisation
System
Architecture
Software
Architecture
Menschen

32. 4 Dimensionen zu Continuous Live Delivery
FriendScout24
Menschen
Organisation
Software
Architecture
System
Architecture
• Verständnis
• Zusammenarbeit
• Renovierung
• Virtualisierung
• Kommunikation
• Spannungsfeld
SW Developer
IT Operations
DevOps
• Backend 1st
• Network
Architecture
• Transparenz
• Ownership
Builds brechen
• Definition of Done
• Frontend 2nd
• Stand Alone Tests
• Hardware
Architecture
Single Boxes 
Blades
Alte Storages 
Neue Storages
• Automation
• Automation
• Config
Management
• Config
Management
• Monolith 
Autonome
Applikationen
• Blueprints

33. Tools?
●
●
●
●
●
●
●
CI? Jenkins.
Build-Pipeline? Jenkins, Nexus.
Repository? git.
Build-Tools? Gradle, maven, rake, scripts.
Agile Tool? JIRA, Greenhopper.
Monitoring? Nagios, Gomez, New Relic.
Code Wach? Sonar.

34. Lessons? Learned!
● Continuous Delivery? Nett und NÖTIG.
● CD ein Selbstzweck? Nein. Teil eines größeren Ganzen.
● Ältere Technologie? Herausforderung, aber machbar.
● Tools? Start mit OpenSource, dann Enterprise Software.
● CD als USP? Nein, CD wird Commodity.
● USP? Product Development Practice & Company Culture
• How do we do
this?
Never fear the change.

35. 2014++
●
●
●
●
Releases? Daily und Zero Downtime.
Virtualisierung? Elastic Computing.
Configuration Management? Infrastructure as Code.
Deployment Management? Enterprise grade.
Seite 35
Titel der Präsentation | Autor der Präsentation

36. Q&A
•
•
•
•
•
•
•
•
•
•
•
•
•
•
http://www.flickr.com/photos/27698646@N04/3747987087
http://www.flickr.com/photos/cdeimages/3569891026/
http://www.flickr.com/photos/28803638@N00/1536804850/
http://www.flickr.com/photos/mckaysavage/8115049949
http://www.flickr.com/photos/83876152@N00/4006567910
http://www.flickr.com/photos/8515164@N08/5699142183
http://www.flickr.com/photos/mssarakelly/10797744144/
http://www.flickr.com/photos/18091975@N00/3654141771
http://www.flickr.com/photos/23797059@N02/3716705025
http://www.flickr.com/photos/bakokojp/8369049055
http://www.flickr.com/photos/befuddledsenses/7265071672
http://www.flickr.com/photos/katerha/5746905652
Selbst 
http://www.flickr.com/photos/hamillianactor/362021036