http://www.opitz-consulting.com Wann sollte ich mich mit dem Thema Continuous Delivery (CD) beschäftigen, reicht Continuous Integration (CI) nicht aus? Und wenn ich mich auf die Reise begebe: Was gehört alles dazu? In diesem Vortrag bei der OOP 2016 in München ging unser Software Architect Michael Stähler auf die notwendigen Schritte auf dem Weg von CI nach CD ein und zeigte, was sinnvolle Zwischenschritte sind und worüber man sich Gedanken machen muss. -- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. Über unsere IT-Beratung: http://www.opitz-consulting.com Unser Leistungsangebot: http://www.opitz-consulting.com Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com

1. Menschen. Innovationen. Lösungen.
Michael Stähler
Auf dem Weg von
Continuous Integration (CI)
zu Continuous Delivery (CD)
Wie die Ideen hinter CD-Prinzipien den Weg weisen können

2. Michael Stähler
 Software Architekt, Coach, Entwickler
Fokus Themen
 Software Architektur
 Java Technologien, Java EE, Spring
 Continuous Delivery
michael.staehler@opitz-consulting.com
@fred4jupiter
https://github.com/fred4jupiter
http://de.slideshare.net/opitzconsulting

3. Mission
Wir entwickeln gemeinsam mit allen Branchen
Lösungen, die dazu führen, dass sich diese
Organisationen besser entwickeln als ihr
Wettbewerb.
Unsere Dienstleistung erfolgt partnerschaftlich
und ist auf eine langjährige Zusammenarbeit
angelegt.
Leistungsangebot
Application Lifecycle Management
IT-Beratung
Business-Lösungen
Managed Services
Training und Coaching
IT-Trends
Märkte
Branchenübergreifend
Über 600 Kunden
29%
Industrie / Versorger /
Telekommunikation
29%
Handel / Logistik /
Dienstleistungen
42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände
Eckdaten
Gründung 1990
400 Mitarbeiter
9 Standorte

4. Agenda
Abgrenzung CI von CD
CD-Prinzipien und -Praktiken
Themenschwerpunkte im CD-Umfeld
Fazit

5. ABGRENZUNG CI VON CD

6. Continuous Integration
Source Control
Build
Testing
Development
trigger on
commit
commit
TestReport

7. Continuous Integration
 schnelles Feedback auf Sourcecode-Änderungen
 Prinzip: „integrate early and often“
 (mind.) einmal am Tag einchecken
Definition of Done:
Completed in Development and Test

8. Continuous Delivery
 schnelles Feedback ob Anwendung „einsatzbereit“
für Produktion
 Deployment: finale Stage von Continuous Integration
 Software ist jederzeit in deploybarem Zustand
Definition of Done:
Completed in Development and Test
Available in Production

9. Continuous Delivery
Sammlung von Techniken,
Prozessen und Werkzeugen,
um den Prozess der
Softwareauslieferung zu verbessern

10. agiles Manifest
„Unsere höchste Priorität ist es,
den Kunden durch frühe und
kontinuierliche Auslieferung wertvoller
Software zufrieden zu stellen.“
Quelle: http://agilemanifesto.org/iso/de/principles.html
1. Agile Manifest

11. Warum CD? - Ziele
 Fortführung agiler Entwicklungspraktiken bis zur
Produktion
 kürzere Time-To-Market
o Fachbereich oder Management wollen häufiger
Produkte am Markt platzieren
 Qualität der Softwareauslieferung verbessern

12. Warum CD?
“How long does it take to deploy one line of
code to production?” Mary und Tom Poppendieck, 2006

13. Metriken: Lead Time vs. Cycle Time
Zeit
Online
Lead Time (Sicht des „Kunden“; SLA)
Cycle Time
Ticket created Begin of work going online

14. Warum CD? - häufige Probleme
 Lead Time bzw. Cycle Time dauert zu lange
o Continuous Delivery fokussiert auf Cycle Time
 „Letzte Meile“ ist besonders „schmerzhaft“
 schlechte Zusammenarbeit zwischen den
Abteilungen

15. CD-PRINZIPIEN UND -PRAKTIKEN

16. CD-Prinzipien
Erstmals im Buch
„Continous Delivery“ von
Jez Humble und David Farley
definiert.
Addison-Wesley, 2010

17. Von CD-Prinzipien leiten lassen…
Prinzipien Praktiken
Topics
(Themenschwerpunkte)
Umsetzung, Tools

18. CD-Prinzipien
Repeatable, reliable Release-
/ Deploy-Process
Automate everything!
If somethings painful, do it
more often
Keep everything in
source control
Done means “released”
Build quality in!
Everybody has responsible for
the release process.
Improve continuously
CD-Praktiken
Build binaries only once
Same mechanism to deploy to
every environment
Smoke test your deployment
If anything fails, stop the line!
Topics
Cloud, Virtualisierung
Log-Management /
Monitoring
Automatisierung
Konfigurationsmanagement
Self-Service-Operations
James Betteley, 8 Principles of Continuous Delivery: https://dzone.com/articles/8-principles-continuous, 2011
CD-Pipeline
DevOps

19. THEMENSCHWERPUNKTE CD

20. Automatisierung
Quelle: https://en.fotolia.com/id/70489116

21. Automatisierung
Deployment Checklist:
Unit Tests starten
Build taggen
Dateien kopieren
Package, Release
FTP Transfer auf Server
Jobs, Server restarten
Deployment Jobs:
Test Deploy
Stage Deploy
Prod Deploy

22. Automatisierung
 ermöglicht zuverlässiges, wiederholbares Release-
und Deployment-Management
 Umgebungen gleich halten (reproduzierbar)
 „Infrastructure as Code“
 mittlerweile viele (gute) Tools verfügbar

23. CD-Pipeline
Quelle: https://www.flickr.com/photos/31237410@N00/283508072/sizes/l/

24. CD-Pipeline
Manueller Start
Commit Stage
Automated
Acceptance Test
Stage
Manual QA
Testing
UAT
Capacity & Load
Testing
Production
Quality
Gate
Value Stream
Quality
Gate
Quality
Gate
Quality
Gate

25. Zeit
Klassische Releases
Continuous Delivery
“If something is painful, do it more often!“

26. CD-Pipeline
Beispiel: Jenkins
• build-pipeline-plugin
• delivery-pipeline-plugin
Plugins:

27. CD-Pipeline
Beispiel: Thoughtworks GO

28. CD-Pipeline
 schafft Transparenz im Release- und Deployprozess
 Qualitätssicherung durch Quality-Gates
 Feedback-Zyklus mit jeder Stage
 Test von Funktionalitäts-, Sicherheits- und
Performance-Aspekten

29. Konfigurationsmanagement
Quelle: https://farm3.staticflickr.com/2487/4178277860_3bcc6e9715_b_d.jpg

30. Konfigurationsmanagement
 ein Binär-Artefakt für alle Umgebungen
o dynamische Konfiguration zur Laufzeit
 Applikation mit Laufzeitumgebung „bündeln“
o z.B. Spring Boot, Payara Micro, RPM, Docker-Container …
 eine Versionsnummer pro Pipeline-Build
 Datenbankschemamigration
 Feature Toggles / Feature Flags
o z.B.

31. Self-Service-Operations
Quelle: https://farm3.staticflickr.com/2823/12183409234_59e797bfc2_o_d.jpg

32. Self-Service-Operations
 Deployment, Releasemanagement per „Button-Click“
o Deploye in alle Umgebungen auf die gleiche Weise
 Features: Dashboard, Job Scheduling, Remote Execution
 Smoke-Test nach Deployment
 Rechtemanagement
 Auditing: Historie mittels Activity-Log
o Wer hat wann welche Version deployt?

33. Self-Service-Operations
Quelle: http://rundeck.org/images/Rundeck-JobExecution.png

34. Quelle: https://en.fotolia.com/id/92642700
DevOps

35. DevOps
WallofConfusion
Entwicklung Betrieb
Wir müssen neue
Anforderungen
umsetzen!
Wir müssen Stabilität
gewährleisten!

36. DevOps
 Fokus auf das gesamte System definiert die Ziele
o jeder ist verantwortlich für den Auslieferungsprozess
(DEV, QA, OPS…)
o MicroServices: Querschnitts-Teams, „You build it, you run it“
 Entwicklerteam mit Ops-Beteiligung
o oder Ops-Team mit Entwicklerbeteiligung
 Betrieb frühzeitig in Entwicklung einbeziehen
o Wartungskosten: ca. 2- bis 4-fache der Entwicklungskosten *
* http://archiv.iwi.uni-hannover.de/cms/images/stories/upload/lv/wisem0809/SQM/WRT.pdf

37. Log-Management /Monitoring
Quelle: https://farm7.staticflickr.com/6238/6266640101_ddc8fc52d9_b_d.jpg

38. Log-Management/Monitoring
 viele Anwendungen, viele Logs, viele Server
o zentraler Zugang hilfreich (z.B. über Dashboard)
 Prod-Logs überwachen, korrelieren, durchsuchen
 Feedback aus Produktion bereits in Entwicklung
 einheitliches Format (z.B. GELF)

39. Cloud, Virtualisierung
Quelle: https://farm6.staticflickr.com/5303/5781222217_490879de04_b_d.jpg

40. Cloud (PaaS), Virtualisierung
 ermöglicht schnelle Bereitstellung von Test-/Prod-Umgebungen
(on-demand)
 einfache, dynamische Skalierung
 Software muss nicht an Umgebung angepasst werden
o Umgebung wird an Software angepasst bzw. dafür erstellt
 Containerization
o angepasste Umgebung für die Anwendung
o ideal für MicroService-Architekturen
 Build-Agents in Docker-Umgebung

41. FAZIT

42. Fazit
Continuous Delivery ist Fortführung von CI
Automatisierung ist Enabler für CD
CD für jedes Unternehmen wichtig
Es gibt nicht das eine CD-Tool

43. Bildquelle / URL
Fragen?
Herzlichen Dank für
Ihre Aufmerksamkeit!