Seit der Jahrtausendwende ist in der Softwareentwicklung einiges in Bewegung geraten. Es dürfte heute kaum ein Unternehmen geben, das nicht mindestens agile Elemente in seinen Entwicklungsprozess integriert hat. Meist mit dem Ziel, das Risiko zu minimieren Software an den Anforderungen vorbei zu entwickeln und schlussendlich Kosten bei der Entwicklung zu sparen. Aber wie lässt sich agile Softwareentwicklung in den Betrieb integrieren? Wie läuft das bisher?
Welche Probleme gibt es dabei und wie kann man diese lösen?
Im Vortrag wird anhand praktischer Erfahrung darauf eingegangen, wie agile Softwareentwicklung durch Continuous Deployment und Continuous Delivery das Betriebsumfeld innovieren kann.
5. IT Welt
• Softwareentwicklung & Systembetrieb
organisatorisch klar getrennt
• Auslagerung von Organisationseinheiten in
andere Unternehmen
FOO Inc.
... Finanzen Personal Software Betrieb Verkauf ...
BAR Corp. Outsourcing
Betrieb
14.03.12
6. Gründe
• Skaleneffekt beim Konsolidieren des
Systembetriebs nutzen
• Personalbedarf im Betrieb steigt nicht zwangsläufig
proportional zur Anzahl der zu betreuenden Systeme
Betrieb mehrerer Systeme bündeln und an
ausgewiesene Organisationseinheiten übergeben ist
wirtschaftlich vorteilhaft
• Betriebs- und Administrationsaufgaben erfordern
anderes Mitarbeiterprofil
14.03.12
7. Ergebnis
• Etablierte „Schnittstelledefinition“ zwischen
beiden Welten – Wall of Confusion
• Wie überführt man Software in den Betrieb?
• Wie kann man sicherstellen, dass der Betreib
den Anforderungen der Stakeholder gerecht
wird?
• ...
• Prozesse, Metriken, SLA‘s, Regelungen, ...
Die IT Infrastructure Library (ITIL) ist eine Sammlung von Best Practices bzw. Good Practices in einer Reihe von Publikationen, die eine
mögliche Umsetzung eines IT-Service-Managements (ITSM) beschreiben und inzwischen international als De-facto-Standard hierfür
gelten.
Quelle: http://de.wikipedia.org/wiki/IT_Infrastructure_Library
14.03.12
8. Ergebnis (2)
I want I want
change! stability!
Dev Ops
• automatisiert • formal
Allenfalls eine funktionale Zusammenarbeit, aber wenig effizient
bzw. effektiv.
14.03.12
10. Warum?
Bis zur Jahrtausendwende - klassische Software
Entwicklungsmethoden etabliert
Nachteilig:
• Plangetrieben
• Vollständige Erfassung aller Anforderungen nur
mit immensem Aufwand möglich
• „Keine“ Flexibilität bei geschäftlicher,
gesetzlicher oder technischer Veränderung
• ...
11. Klassisch
Releasezyklus
Releasezyklus
zentrale
QA
zentrale
QA
Initialisierung zentrale
QA
Analyse
zentrale
QA
Entwurf
zentrale
QA
Realisierung
Einführung
Nutzung
Zeit
... Dev Ops Ops
+ Anwender
Time to Release
14.03.12
12. Agile, Agile, Agile
Seit ca. 2003 Kanban & Scrum im Aufwand
Ziele:
• Risiko minimieren, an Anforderungen vorbei zu
entwickeln
• Entwicklungskosten einsparen, Time-To-Market
Voraussetzungen:
• Besseres Zusammenspiel zwischen Entwicklern
und Nutzern, Anwender einbinden
• Kürzere Entwicklungszyklen
14.03.12
13. Agile/Iterativ
„Agilisierter Wasserfall“
Releasezyklus
Releasezyklus
zentrale
QA
zentrale
QA
Sprint 1 2 3 4 ... n
Analyse & Analyse & Design
Analyse & Analyse & Design
Design
Design Analyse & Design Einführung
Implementierung
Implementierung
Implementierung
Implementierung Implementierung Nutzung
Test & Demo & Demo
Test & Demo & Demo
Test Test Test & Demo
Zeit
Scrum Team (Dev) Ops Ops
+ Anwender
Time to Release + (Proxy-) Anwender
14.03.12
15. DevOps
Auch: Continuous Delivery, Continuous Deployment
Releasezyklus
Releasezyklus
Releasezyklus
Releasezyklus
Releasezyklus
Sprint 1 2 3 4 ... n
Analyse & Design Design Design Design
Analyse &
Analyse &
Analyse & Analyse & Design
Implementierung
Implementierung
Implementierung
Implementierung Implementierung
Test & Demo Demo Demo Demo
Test & Test & Test & Test & Demo
Einführung
Einführung
Einführung
Einführung Einführung
Nutzung
Nutzung
Nutzung
Nutzung Nutzung
Delivery Team Zeit
+ (Proxy-) Anwender
Time to Release
14.03.12
16. DevOps steht für ...
• Engere Verbindung von Entwicklungsabteilung
und Systembetrieb unter Zuhilfenahme agiler
Praktiken
• Entsprechende Kultur im Umgang miteinander
• Werkzeuge, mit denen sich Betriebsaufgaben
automatisieren lassen
• Zunahme der Häufigkeit von Änderungen bei
gleichzeitiger Risikominimierung
14.03.12
17. DevOps
... is emerging set of
principles, methods
and practices for
communication, DevOps
collaboration and
integration between Technology
Operations
...
[wikipedia]
Patrick Debois prägte den Begriff 2009 erstmalig auf der
devopsdays.org Konferenz
14.03.12
18. Funktionierts?
• Google (2010): > 20‘000 Experimente führten
zu mehr als 500 Updates verschiedener
Algorithmen – fast 2 mal täglich
• Wordpress (2005-2010):
> 25‘000 Releases – ca. 16 pro Tag
• Etsy, (2010): > 25 Releases/Tag
14.03.12
22. Tools (1)
„Infrastructure as Code“
Betriebshandbuch
Dev Ops
• „nicht“ versiert in Shell Programmierung • „keine“ tiefen Kenntnisse über das
• „keine“ fundierte Kenntnisse im Umgang Verhalten von Anwendungen auf dem
mit Unix-Systemen Zielsystem
• „wenig“ Informationen über die Funktionen
einer Anwendungen
• „wenig“ Informationen zur Konfiguration
1. Gemeinsames Vokabular (DSL) definieren
2. Gemeinsames Beschreiben aller notwendigen Schritte
3. Direkte Überführung in ein ausführbares Programm
4. Versionierung des Programms zusammen mit der Software
• Sehr schnelle betriebsfertige Einrichtung mehrerer Systeme aus einer einheitlichen Quelle
14.03.12
23. Tools (2)
Deployment von Anwendung
Betriebshandbuch
Dev Ops
• „keine“ Informationen zu •„wenig“ Informationen zur Installation einer
Installationspfaden und Environment Anwendung auf dem Zielsystem
Variablen
1. Gemeinsames Vokabular (DSL) definieren capistrano
2. Gemeinsames Beschreiben aller notwendigen Schritte Fabric
3. Direkte Überführung in ein ausführbares Programm
4. Versionierung des Programms zusammen mit der Software
• Sehr schnelles Deployment einer lauffähigen Anwendung pro Umgebung
14.03.12