If it hurts do it more often
Introducing Continuous Delivery

pingworks – Alexander Birk, Christoph Lukas
SEITENBAU – Christian Faigle


Agile Breakfast 27.6.2012




                                              pingworks
Case Study – Continuous Delivery

   Konkretes Projekt: online Präsentationstool
    ala slideshare.net
   Ordner, Tags, Berechtigungen
   ca. 40 Entwickler
   3 Standorte




                                              pingworks
Technischer Rahmen

   3 Schichten Architektur
   Datenschicht, Businesslogik, RIA
   Inhomogene Technologien: Java, PHP, JS
   ~ 35 SVN Module
   ~ 40 Konfigurationsdateien, > 5000 Zeilen
   13 Maschinen in produktionsnaher Umgebung
   Unit-, Integrations- und Systemtests


                                                pingworks
Komponenten




              pingworks
Entwicklung mit SCRUM

   zweiwöchige Sprints
   Lieferung alle zwei Wochen
   Jede Lieferung bedeutet:
       Erstellung von RPMs
       Deployment auf Testumgebung
       Durchführung von Tests
       Erstellung von Testprotokollen



                                         pingworks
Lieferung ohne Continuous Delivery

   Tagging, RPM Build, Deployment: ~ 1 PT
   Lieferung: ~ 2 PT
   Spezialwissen nötig
   Wehe, die Spezialisten haben Urlaub!!
   Integration selten, mini BigBang




                                             pingworks
Continuous Delivery




                      pingworks
Continuous Delivery




                      pingworks
Voraussetzungen


                  Continuous Delivery


      Continuous Integration   Configuration Management




       Automated Testing           DevOps Thinking




                                                          pingworks
Implementierung

   Standardisierung der Testumgebung
   Standardisierung des Deployments
   Standardisierung der Konfiguration
   Aufbau der Build-Pipeline im Jenkins




                                           pingworks
Testumgebungen

   Virtualisierte Testumgebungen
   Einheitliches Hostnamen Schema
   Gescriptetes Cloning und Konfiguration
   „Wegwerf-Mentalität“
   Erstellung in < 15 min.




                                             pingworks
Deployment

   Installer im Bundle
   Kann Anwendung auf allen Umgebungen
    installieren
   Konfiguriert die Anwendung
   „One Click Deployment“ in < 3 min.




                                          pingworks
Continuous Delivery in Zahlen

   2500 Unittests
   1500 Integrationstests
   200 Systemtests
   Bis zu 100 Commits / Bundles pro Tag
   Bis zu 1000 Deployments pro Tag
   30 Testumgebungen
   100 VMs, 2 ESX-Server


                                           pingworks
Schwierigkeiten

   Graben zwischen Dev und Ops zuschütten
   DevOps Thinking etablieren:
    „jeder ist verantwortlich für die Delivery“
   Vermeintliche Kosten
   Letzte Meile beim Kunden




                                                  pingworks
Gewinn

   Deployment wird mit getestet
   Konfiguration unter Kontrolle
   Deutlich weniger Fehler
   Mehr Zeit für Features
   Weniger Zeit für stupides Deployment /
    Konfiguration




                                             pingworks
Live Demo

   Erzeugung einer Testumgebung
   Build-Pipeline im Jenkins
   Bundle-Repository
   Dashboard
   Deployment auf neue Testumgebung




                                       pingworks

Agile Breakfast - If it hurts do it more often

  • 1.
    If it hurtsdo it more often Introducing Continuous Delivery pingworks – Alexander Birk, Christoph Lukas SEITENBAU – Christian Faigle Agile Breakfast 27.6.2012 pingworks
  • 2.
    Case Study –Continuous Delivery  Konkretes Projekt: online Präsentationstool ala slideshare.net  Ordner, Tags, Berechtigungen  ca. 40 Entwickler  3 Standorte pingworks
  • 3.
    Technischer Rahmen  3 Schichten Architektur  Datenschicht, Businesslogik, RIA  Inhomogene Technologien: Java, PHP, JS  ~ 35 SVN Module  ~ 40 Konfigurationsdateien, > 5000 Zeilen  13 Maschinen in produktionsnaher Umgebung  Unit-, Integrations- und Systemtests pingworks
  • 4.
    Komponenten pingworks
  • 5.
    Entwicklung mit SCRUM  zweiwöchige Sprints  Lieferung alle zwei Wochen  Jede Lieferung bedeutet:  Erstellung von RPMs  Deployment auf Testumgebung  Durchführung von Tests  Erstellung von Testprotokollen pingworks
  • 6.
    Lieferung ohne ContinuousDelivery  Tagging, RPM Build, Deployment: ~ 1 PT  Lieferung: ~ 2 PT  Spezialwissen nötig  Wehe, die Spezialisten haben Urlaub!!  Integration selten, mini BigBang pingworks
  • 7.
  • 8.
  • 9.
    Voraussetzungen Continuous Delivery Continuous Integration Configuration Management Automated Testing DevOps Thinking pingworks
  • 10.
    Implementierung  Standardisierung der Testumgebung  Standardisierung des Deployments  Standardisierung der Konfiguration  Aufbau der Build-Pipeline im Jenkins pingworks
  • 11.
    Testumgebungen  Virtualisierte Testumgebungen  Einheitliches Hostnamen Schema  Gescriptetes Cloning und Konfiguration  „Wegwerf-Mentalität“  Erstellung in < 15 min. pingworks
  • 12.
    Deployment  Installer im Bundle  Kann Anwendung auf allen Umgebungen installieren  Konfiguriert die Anwendung  „One Click Deployment“ in < 3 min. pingworks
  • 13.
    Continuous Delivery inZahlen  2500 Unittests  1500 Integrationstests  200 Systemtests  Bis zu 100 Commits / Bundles pro Tag  Bis zu 1000 Deployments pro Tag  30 Testumgebungen  100 VMs, 2 ESX-Server pingworks
  • 14.
    Schwierigkeiten  Graben zwischen Dev und Ops zuschütten  DevOps Thinking etablieren: „jeder ist verantwortlich für die Delivery“  Vermeintliche Kosten  Letzte Meile beim Kunden pingworks
  • 15.
    Gewinn  Deployment wird mit getestet  Konfiguration unter Kontrolle  Deutlich weniger Fehler  Mehr Zeit für Features  Weniger Zeit für stupides Deployment / Konfiguration pingworks
  • 16.
    Live Demo  Erzeugung einer Testumgebung  Build-Pipeline im Jenkins  Bundle-Repository  Dashboard  Deployment auf neue Testumgebung pingworks