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!