Auf dem Weg von Continuous Integration zu Continuous Delivery

909 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
909
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
116
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Auf dem Weg von Continuous Integration zu Continuous Delivery

  1. 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. 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. 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. 4. Agenda Abgrenzung CI von CD CD-Prinzipien und -Praktiken Themenschwerpunkte im CD-Umfeld Fazit
  5. 5. ABGRENZUNG CI VON CD
  6. 6. Continuous Integration Source Control Build Testing Development trigger on commit commit TestReport
  7. 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. 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. 9. Continuous Delivery Sammlung von Techniken, Prozessen und Werkzeugen, um den Prozess der Softwareauslieferung zu verbessern
  10. 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. 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. 12. Warum CD? “How long does it take to deploy one line of code to production?” Mary und Tom Poppendieck, 2006
  13. 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. 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. 15. CD-PRINZIPIEN UND -PRAKTIKEN
  16. 16. CD-Prinzipien Erstmals im Buch „Continous Delivery“ von Jez Humble und David Farley definiert. Addison-Wesley, 2010
  17. 17. Von CD-Prinzipien leiten lassen… Prinzipien Praktiken Topics (Themenschwerpunkte) Umsetzung, Tools
  18. 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. 19. THEMENSCHWERPUNKTE CD
  20. 20. Automatisierung Quelle: https://en.fotolia.com/id/70489116
  21. 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. 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. 23. CD-Pipeline Quelle: https://www.flickr.com/photos/31237410@N00/283508072/sizes/l/
  24. 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. 25. Zeit Klassische Releases Continuous Delivery “If something is painful, do it more often!“
  26. 26. CD-Pipeline Beispiel: Jenkins • build-pipeline-plugin • delivery-pipeline-plugin Plugins:
  27. 27. CD-Pipeline Beispiel: Thoughtworks GO
  28. 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. 29. Konfigurationsmanagement Quelle: https://farm3.staticflickr.com/2487/4178277860_3bcc6e9715_b_d.jpg
  30. 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. 31. Self-Service-Operations Quelle: https://farm3.staticflickr.com/2823/12183409234_59e797bfc2_o_d.jpg
  32. 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. 33. Self-Service-Operations Quelle: http://rundeck.org/images/Rundeck-JobExecution.png
  34. 34. Quelle: https://en.fotolia.com/id/92642700 DevOps
  35. 35. DevOps WallofConfusion Entwicklung Betrieb Wir müssen neue Anforderungen umsetzen! Wir müssen Stabilität gewährleisten!
  36. 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. 37. Log-Management /Monitoring Quelle: https://farm7.staticflickr.com/6238/6266640101_ddc8fc52d9_b_d.jpg
  38. 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. 39. Cloud, Virtualisierung Quelle: https://farm6.staticflickr.com/5303/5781222217_490879de04_b_d.jpg
  40. 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. 41. FAZIT
  42. 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. 43. Bildquelle / URL Fragen? Herzlichen Dank für Ihre Aufmerksamkeit!

×