Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - Oktober 2013

Post on 15-Apr-2017

3,141 views 0 download

transcript

www.friendscout24.de www.friendscout24.de

Continuous Delivery

Nett oder nötig?

Michael Maretzke

Michael Maretzke FriendScout24

Vice President Technology

michael.maretzke@friendscout24.de

twitter: @mmaretzke

Flirten Lebenspartner Abenteuer

- Aktive Suche - Dateroulette

Auch verfügbar - iOS-/Android-App - Facebook-App

- Wissenschaftlicher Test mit Matching Das erste Premium-

Casual-Dating Portal speziell für die Frau

- Diskretion durch Maskentool

- Sicherheit mit Jugendschutzpixel

- Seriös

FriendScout24 - für die Suche nach

dem richtigen Partner

„Full-Service“ für alle ernsthaften Beziehungen

Product Manager

Lead Engineer

SW Engineer SW Engineer

SW Engineer SW Engineer

QA Manager

Scrum Master

Product Owner

UX Designer

SC

RU

M K

AN

BA

N

AGILE

Kerngeschäft

Bewährtes Businessmodell

8 Jahre erprobte Architektur

Wachstumsfelder

Neue Businessmodelle

Leading Edge-Technolgies

How do we increase

the odds of our success?

Warum Continuous

Delivery?

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

AUTOMATION.

LEAN Product Development

Validated Learning

Build-Measure-Learn

Innovation Accounting

Entrepreneurship is Management

Entrepreneurs are Everywhere

Warum LEAN Product Development?

Build

Measure Learn

Fail early, learn fast.

Continuous Delivery @ FriendScout24

Continuous Live

Deployment

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.

Casual Dating Plattform „Secret“

● Architektur? Neu.

● Release? Painless.

● Backend und Frontend? Geregelt.

● Redundanz? Yes.

● Aufwand? Adäquat.

● Automatisierung? Yes.

Continuous Live Deployment Past | Present | Future

20

11

20

12

20

13

2011-2012 low hanging fruits

Continuous Live Deployment @ FRS24 2011

● Agile Methode? SCRUM.

● Release Cycle? 3 Wochen.

● QA-Zeit? 2 Tage.

● Unit-Tests? Wenige.

@FRS24

Brain Storming

Assessment 1) …

2) … 3) … 4) …

5) … 6) …

7) … 8) …

9) …

Oktober 2011

TODO-Liste

@FRS24

Setup CLD

Team

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

Titel der Präsentation | Autor der Präsentation

Seite 24

● Agile Methode? Kanban.

● Release Cycle? Jeden Tag.

● QA-Zeit? 3 Stunden.

● Unit-Tests? Noch mehr – aber immer noch wenig.

Continuous Live Deployment @ FRS24 2012

Release Delivery Time 2012

Zeitdauer UAT-Läufe 2012

Unit Test Coverage 2012

Build-Pipeline 2012

Wie?

März 2012

● Build-Pipeline? Komplett erneuert.

● CI-Umgebung? Komplett erneuert (Jenkins).

● UAT-Läufe? Optimiert (Selenium parallelisiert).

● Code? Aufgeräumt.

● Architektur? Wenig Änderung.

BIG BLOCKS 2012 - 2013 BIG BLOCKS

BIG BLOCKS 4 Dimensionen zum Erfolg

Menschen

Organisation

Software Architecture

System Architecture

4 Dimensionen zu Continuous Live Delivery FriendScout24

Menschen

• Verständnis

• Kommunikation

• Transparenz

• Ownership Builds brechen

Organisation

• Zusammenarbeit

• Spannungsfeld SW Developer IT Operations DevOps

• Definition of Done

Software Architecture

• Renovierung

• Backend 1st

• Frontend 2nd

• Monolith Autonome Applikationen

• Blueprints

• Stand Alone Tests

• Automation

• Config Management

System Architecture

• Virtualisierung

• Network Architecture

• Hardware Architecture Single Boxes Blades Alte Storages

Neue Storages

• Automation

• Config Management

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.

• How do we do

this?

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

Never fear the change.

Titel der Präsentation | Autor der Präsentation

Seite 35

2014++

● Releases? Daily und Zero Downtime.

● Virtualisierung? Elastic Computing.

● Configuration Management? Infrastructure as Code.

● Deployment Management? Enterprise grade.

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