View
453
Download
4
Category
Preview:
DESCRIPTION
Bei der Auftaktveranstaltung zu den axxessio "Technologie Trends" am 19.03.2014, präsentierte Oliver Wronka, Principal Architect/ Project Manager, die diversen Facetten des Continuous Delivery.
Citation preview
Einführung von CD in Demand Supply IT Organisationen
OLIVER WRONKA
19. MÄRZ 2014
Continuous Delivery
2
Demand / Supply Split
Insbesondere in Konzernen wird die IT in zwei Rollen gesplittet – Demand (Was wollen wir) und Supply (Wie machen wir es)
Fachseite
Demand-IT
Supply-IT(Entwicklung / Betrieb)
3
Wasserfall
In Demand / Supply IT Organisationen wird nach wie vor auf das Wasserfallmodell gesetzt.
» Insbesondere in großen IT Organisationen kommt vorwiegend das V-Modell zum Einsatz.
» Große Releases» Software wird erst
mit GO Live nutzbar.» Anforderungs-
änderungen nur mittels CR-Verfahren
4
Agiles Vorgehen (hier Scrum)
Dem gegenüber stehen agile Vorgehensmodelle wie z. B. Scrum.
Alternative zu V-Modell Häufige Lieferung durch
iterative Entwicklung Reduzierung von
Komplexizitätsrisiken durch inkrementelle Entwicklung
Starke, direkte Beteiligung des Fachbereichs
Pragmatische Priorisierung
Selbstorganisation der Teams
5
Deployment Pipeline
Häufige Bereitstellung der Anwendung führt automatisch zum Aufbau einer Deploymentpipeline.
» Skripte und Werkzeuge der Lieferautomatisierung werden als Deployment Pipeline bezeichnet.
Compile Unit-Tests Package
Metriken Dokumentation
Deployment auf Testumgebung
Fach- und Regressionstests
Performancetests
Deployment auf Integrations-umgebung
Exloratives Testen
Deployment auf Produktions-umgebung
Build Quality Test Stage Production
6
Deployment Pipeline
Mittels Deploymentpipeline wird das Aufsetzen (Pull statt Push) von Umgebungen automatisiert.
» Übernimmt die automatisierte Lieferung der Software.» Stellt darüber hinaus auch die Betriebsumgebung und
deren Konfiguration bereit.» Vorbereitung und Durchführung von Tests.» Beinhaltet auch Konfiguration von
Infrastrukturkomponenten wie z. B. Loadbalancer.» Trade Off: Hoher Initialaufwand, wird jedoch mit
zunehmenden Releases gegenüber manuellem Rollout aufgewogen.
Continious Delivery
Agiles Vorgehen + Deployment Pipeline = CD
» Die Deployment Pipeline ist auch im Wasserfallmodell einsetzbar.
» Erst die Kombination aus Deployment Pipeline und agiler Methode ergibt Continious Delivery.
» Kleine Releases (nur ein oder zwei Features).» Schnelles Ausrollen (kleines Feature in 48h).
8
Disziplinen für CD
CD umfasst viele Disziplinen, die im Wasserfall eher unbekannt sind.
Handwerkszeug Automatisierung
Anaylse Architektur Code Build Test Deploy
User Stories
Personas
Story Mapping
Mockups
Evolution-äre
Architetkur
Aus-reichende
Dokument-ation
Test Driven Develop-
ment
Mocks + Stubs
Design
Refactoring
ContiniousIntegration
Distributed Version Ctrl
DependencyMgmnt
Feature Branches
ContiniousTesting
Acceptance Test Driven
Developmnt
Code Analyse
NFA Testing
Continious Deployment
Delivery Pipeline
Release Process
(Version,Notes
Migration)
Quelle: Continuous Delivery – Ein Überblick (dpunkt.verlag)
9
Phasen und deren Verantwortung
Die einzelnen Phasen des Gesamtprozesses werden durch unterschiedliche Organisationen verantwortet.
Init Analyse Design Code Test Fachl.Abn.
Betr.Abn. Rollout
Demand DemandSupply
(Entwicklungsdienstleister)Supply
(Betriebsdienstl.)
Beteiligte Rollen - Wasserfallprozess
10
Die strikte Trennung hat automatisch eine hohe Anzahl von unterschiedlichen Rollen zur Folge.
Init Analyse Design Code Test Fachl.Abn.
Betr.Abn. Rollout
Demand DemandSupply
(Entwicklungsdienstleister)Supply
(Betriebsdienstl.)
Architekt
PL
Fachseite
Analyst PL Designer Entwickler
TesterT-ArchitektB-Architekt
Tester AdminPL
DEM (DEV, TST) Admin DEM (REF, PRD)
Beteiligte Rollen – Agiler Prozess
Bei einem agilen Vorgehen tritt die auftraggebende Seite nur noch zu Beginn und Abnahme eines Zyklus in Aktion.
Backlog Code Test Fachl.Abn. Rollout Betrieb
Continuous Delivery
Dev Ops
Fachseite
(B-/T-) Architekt
Dev Team Fachseite Dev Team Admin/Entwickler
Scrum Master
Continuous Integration
Randbedingungen
Nicht jedes Projekt ist geeignet. Daher sollten bestimmte Randbedingungen gegeben sein.
» Der Benutzer bestimmt den Scope der Anwendung, daher sollte es sich um eine GUI Anwendung handeln.
» Die Anwendung selbst sollte nur im geringen Umfang mit weiteren Umsystemen interagieren.
» Außerdem sollten die Schnittstellen zu den Umsystemen stabil sein.
» Selbst angebotene Schnittstellen müssen versioniert werden.
Praktische Umsetzung - I
Die praktische Umsetzung erfolgt unter Berücksichtigung der gegebenen Organisationen.
» Das Projekt wird als DevOps Projekt aufgesetzt.» Ein Mitarbeiter des Betriebsdienstleister wird dem
DevOps Team fest zugewiesen» Die Umgebungen werden als reine Hardware inkl.
Betriebssystem zur Verfügung gestellt.» Shared Components wie Loadbalancer müssen
weiterhin klassisch konfiguriert werden.» Fachseite, business als auch technischer Architekt
treten als Produktowner auf.
Praktische Umsetzung - II
Die praktische Umsetzung erfolgt unter Berücksichtigungen der gegebenen Organisationen.
» Die Fachseite nimmt weiterhin die Anwendung ab, kann dies aber an ein demandseitiges Testteam delegieren.
» Die Anwendung wird durch DevOps für ein Jahr betrieben.
» In dieser Zeit werden die notwendigen Unterlagen für den späteren Betrieb durch den Betriebsdienstleister erstellt.
Unsere Standorte
Niederlassung Köln
Wilhelmstraße 351143 KölnTel +49 22 03 – 91 22 0Fax +49 22 03 – 91 22 23
Niederlassung Darmstadt
Kasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0
Hauptsitz Bonn
Kurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3
Niederlassung Bern
Frohbergweg 73012 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78
Consider IT done!
Recommended