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
Handlungsoptionen bei der Modernisierung von Legacy-Systemen
Auf dem Weg von Continuous Integration zu Continuous Delivery
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
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
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
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
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
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
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
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.
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?
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
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)
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
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