Case Study zu Continuous Delivery Vortrag gehalten auf der Agile Bodensee in Konstanz am 28.9.2012

1. If it hurts do it more often
Introducing Continuous Delivery
pingworks – Alexander Birk, Christoph Lukas
SEITENBAU – Christian Faigle
Agile Bodensee, 28.9.2012

2. Case Study – Continuous Delivery
 Konkretes Projekt: online Präsentationstool
a la slideshare.net
 Ordner, Tags, Berechtigungen
 ca. 40 Entwickler
 3 Standorte

3. Technischer Rahmen
 3 Schichten Architektur
 Java, PHP, JS
 ~ 35 SVN Module, 5000 Konfigparameter
 Unit-, Integrations- und Systemtests

4. Komponenten

5. Entwicklung mit SCRUM
 zweiwöchige Sprints
 Lieferung alle zwei Wochen
 Jede Lieferung bedeutet:
 Erstellung von Binärpaketen
 Deployment auf Testumgebung
 Durchführung von Tests
 Erstellung von Testprotokollen

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

7. Continuous Delivery

8. Continuous Delivery

9. Aspekte von Continuous Delivery
Continuous Delivery
Convention over
Continuous Integration
Configuration
DevOps Thinking Continuous Improvement

10. Testumgebungen
 Virtualisierte Testumgebungen
 „Infrastructure as Code“
 Geskriptetes „bare Metal-Cloning“ und
Konfiguration
 „Wegwerf-Mentalität“
 Erstellung in < 15 min.

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

12. Continuous Delivery in Zahlen
 Bis zu 100 Commits / Bundles pro Tag
 Bis zu 1000 Deployments pro Tag

13. Schwierigkeiten
 Bereitschaft für Veränderung
 Graben zwischen Dev und Ops zuschütten
 DevOps Thinking etablieren:
„jeder ist verantwortlich für die Delivery und
Betrieb“
 Vermeintliche Kosten

14. Aufwand und Kosten
 Aufsetzen von Continuous Delivery
3 Entwickler Vollzeit 2 Monate => 120 PT
 Manuelles Deployment pro Sprint
1 Jahr, 25 Sprints a 3 PTs => 75 PT
1 Sprint Integration / Bugfixing => 70 PT
----------
145 PT

15. Gewinn
 Deployment wird zum Non-Event
 Kein „Configuration Nightmare“
 weniger (schwere) Fehler
 Keine Angst vor Refactorings
 Weniger Aufwand für Deployment /
Konfiguration / Testing
 Mehr Zeit für Features, mehr Motivation

16. Fazit
„Must Have“ für agile Software Entwicklung

17. Live Demo
 Erzeugung einer Testumgebung
 Dashboard
 Build-Pipeline im Jenkins
 Bundle-Repository
 Deployment auf neue Testumgebung