Post on 25-Jun-2020
1
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.deVersion:
Von Continuous Integration zu Continuous Delivery
1.2
Steffen Schluff
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
2
2
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
3
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Been there, done that (1)
4
Build-Werkzeug
CI-Server
Entwickler-team
VCS
CI-Server-Webseitemit Build-Ergebnissen
Update
Commit
Build
Build-Ergebnisse
zurückgeben
Build-Ergebnisse veröffentlichen
benachrichtigen
3
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Been there, done that (2)
• „Daily Build and Smoke Tests“ sind schon ein alter Hut– Erste Veröffentlichung von Steve McConnell im Jahre 1996– Thema war bereits davor schon bekannt
• „Continuous Integration“ Artikel von Martin Fowler im Jahre 2000– Themenbereich bekam einen klingendem Namen– Definition „Key Practices“ (Automate the build, Make it self-testing, …)– Erste Bereitstellung von „fertigen“ Tools (CruiseControl)
• „Continuous Integration“ gehört heute zum guten Ton– Wahlfreiheit zwischen diversen Servern (Jenkins, Hudson, Bamboo, …)– Definition von Best Practices, Patterns und Anti-Patterns– Probleme der zweiten Generation: Testlaufzeiten, Virtualisierung, …
5
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Entwickler Kosmos
6
Issue-TrackerAtlassian JIRA
IDEEclipse
SCMSubversion
CI-ServerJenkins
Mylyn
Subversive
SVN Plugin
View VC
SVN Plugin
JIRA Plugin
4
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Da war doch noch was? (1)
7
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
First principle behind the Agile Manifesto(http://agilemanifesto.org/principles.html)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Da war doch noch was? (2)
8
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
First principle behind the Agile Manifesto(http://agilemanifesto.org/principles.html)
5
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Ha Ha Only Serious
9
Issue-TrackerAtlassian JIRA
IDEEclipse
SCMSubversion
CI-ServerJenkins
Mylyn
Subversive
SVN Plugin
View VC
SVN Plugin
JIRA Plugin
Customer
???
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Bis hierher sollst du kommen und nicht weiter
• Continuous Integration konzentriert sich auf Entwickler
• CI Server grün, Commit erfolgreich, Entwickler glücklich
• Aber kein Bereitstellen zum Testen und keine Produktivsetzung
10
CustomerDeveloper
UAT QAOps
(http://www.public-domain-photos.com/free-cliparts)
BuildTool
CI-Server
TeamDev
Team
VCS
CI-ServerResults
6
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Denkt denn niemand an den Kunden?
• Kunde möchte Verfügbarkeit seiner Funktionalität– Kein Interesse, ob CI Server rot, grün, gelb oder blau ist
• Zwischen gutem CI Build und Kunden Verfügbarkeit liegt Release– Release Schritt oft nicht so gut beherrscht wie CI Ökosystem
• Release Modell „Big Bang“™ (alias der Klassiker)– Manuell, Zeitintensiv, Kompliziert, viele Beteiligte, Fehleranfällig
11
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Don‘t do that then!
• Seltene dafür aber große Releases als Konsequenz– Organisatorische Vermeidungsreaktion
• Zugleich hoher Stressfaktor bei ungeplanten Releases– Wenig Übung führt zu hohen Fehlerrate bei Hotfixes
• Frustrierend für den Kunden– Auch einzelne Features brauchen scheinbar sehr lange
12
7
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gut Ding will Weile haben
• Dauer einer Kunden Idee bis Produktivsetzung („Concept to Cash“)
• Visualisierung als „Value Stream Map“
13
Entwicklung und Bereitstellung
ProduktChancen
Bewertung
ProduktDefinition
ProduktPlanung
DevelopmentAbschlusstestAbschlusstest
undFreigabe
Release
3 Tage 1 Woche 10 Tage 7 Wochen 1 Woche 2 Stunden
1 Woche 10 Tage 3 Tage 5 Tage 2 Tage
(Nach „Continuous Delivery“/J. Humble, D. Farley)
Bearbeitungszeit (wertschöpfend)
Wartezeit(nicht wertschöpfend)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Stay on target
14
Time
Cha
nge
Time
Cha
nge
(http://en.wikipedia.org/wiki/Continuous_delivery)
“[…] the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and
with minimal manual overhead.”
8
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Buzzword (1)
15
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
First principle behind the Agile Manifesto(http://agilemanifesto.org/principles.html)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Buzzword (2)
16
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
First principle behind the Agile Manifesto(http://agilemanifesto.org/principles.html)
9
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
17
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery
• „Continuous Delivery is not Continuous Integration. ContinuousDelivery is being in the position to ship your product whenever youwant, day or night.” (Neal Ford)
• Frühere Begriffsverwendung und Wurzeln – „Agile Manifesto” (2001)– „Deployment Pipeline” (2004/2005)
• Gleichnamiges Buch von Jez Humble & David Farley– Eigentliche Begriffsprägung (2010)
• Schwerpunktthemen „Automation“ und „Collaboration“
18
10
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery – Kerngedanken
• “Create a Repeatable, Reliable Process for Releasing Software”– “If It Hurts, Do It More Frequently, and Bring the Pain Forward”– “Automate Almost Everything”– “Keep Everything in Version Control”
• “Everybody Is Responsible for the Delivery Process”
• “Done Means Released”
• Und wie soll das alles umgesetzt werden?
19
(Nach „Continuous Delivery“/J. Humble, D. Farley)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Pipeline – Ein erster Blick
• Zentrale Abstraktion „Deployment Pipeline“– Visualisierung aller Prozessteile für alle Beteiligten– Verbessertes Feedback während der Ausführung– Möglichkeit eines vollautomatischen Releases in alle Umgebungen
20
(Nach „Continuous Delivery“/J. Humble, D. Farley)
CommitStage
AkzeptanzTest Stage
Performance Test Stage
Nutzer-abnahme
Stage
ProduktivStage
Compilieren
Unit Testsausführen
Paketieren
Code Analyseausführen
Umgebung konfigurieren
Binariesdeployen
Smoke Testsausführen
Akzeptanz Testsausführen
Umgebung konfigurieren
Binariesdeployen
Smoke Testsausführen
PerformanceTests ausführen
Umgebung konfigurieren
Binariesdeployen
Smoke Testsausführen
Umgebung konfigurieren
Binariesdeployen
Smoke Testsausführen
11
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Pipeline – Bestandteile
• Die Deployment Pipeline– Macht Status der Produktentwicklung sichtbar– Liefert Feedback zu jeder Änderung– Technisch-konzeptuelle Basis des Release Prozesses
• Die Pipeline besteht aus einer Folge von Stages– Commit Stage als zentrales Eingangs-Gate– Typische Stages: UAT, Performance Tests, Production Deployment– Stages verbunden durch Trigger (automatisch oder manuell)
• Jobs sind die Bausteine der Stages– „Unit of Work“– Bestehen aus Tasks wie Build, Deploy, Copy, Test, …
21
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Pipeline – Sequenzdiagramm
• Jede Ressourcen Änderung startet neue Pipeline Instanz
• Erste Stage produziert alle Artefakte
• Durchlaufen aller Stages bis Fehlschlag („Stop the line“) oder …
• Pipeline Ende erreicht ist (letzte Stage führt Deployment aus)
22
(Nach „Continuous Delivery“/J. Humble, D. Farley)
AutomatisierteAutomatisierteAkzeptanz
Tests
Nutzer-abnahme
Releasein Produktion
Artefaktebauen undUnit Tests
Versions-kontrolle
DeliveryTeam
Check inTrigger
Trigger
Manualapproval
Manualapproval
Feedback
Feedback
Feedback
12
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Pipeline – Ein zweiter Blick
23
VCS
Commit StageProduktiv
Stage
Performance Test Stage
NutzerabnahmeStage
Artefakt-Repository
Qualitätssicherung:SelbstgesteuertesDeployment
Anwendungsbetrieb:Release auf Knopfdruck
automatisiert:einmaliges Erstellen der Artefakte und Freigabe in das Artefakt-Repository
Anwendungsbetrieb:Release auf Knopfdruck
Infrastruktur- und AnwendungskonfigurationQuellcode
Akzeptanz TestStage
(Nach „Continuous Delivery“/J. Humble, D. Farley)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery – Prinzipien & Methoden (1)
• Fortlaufende Optimierung– In Verantwortung aller Beteiligter (Development, Operations, …)
• Artefakte– Werden einmal gebaut und in einem Artefakt Repository verwaltet… – und allen Stages zur Verfügung gestellt– Ziel ist identisches Deployment in allen Umgebungen– Umgebungsspezifika durch eigene Konfigurationen
• Configuration-Management– Basis für einmalig erstellte Artefakte– Umfasst Software und Infrastruktur („Infrastructure as code“)– Konfigurationen werden versioniert
24
13
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery – Prinzipien & Methoden (2)
• Automatisierung– So umfangreich wie möglich– Umfasst auch alle Aspekte der Infrastruktur (inklusive OS)– Prägung durch Development und Operations
• Tests– Basis für Automatisierung und Pipeline Processing– Geben Sicherheit für erfolgreiche Änderungen– Smoke Tests speziell für Deployment
• Monitoring– Ermöglicht Feedback für Operating– Basis für fortlaufende Optimierung
25
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Alle Theorie ist grau
• Erfolgsfaktoren von Continuous Integration rückblickend waren– Eingängiger Name– Konkrete „Key Practices“– Einsetzbare Tools
• Zum Erfolg fehlt Continuous Delivery also noch ein gutes Tool– Erster Impuls oft selbstgemachte Lösungen („Home grown“), aber …– häufig schnell veraltet bei schlechtem Kosten-Nutzen Verhältnis
• Jedes Projekt hat in der Praxis seine eigenen Spezialitäten– Web App vs. Mobile vs. Rich Client, Programmiersprache, OS, usw.– Somit sind auch Continuous Delivery Umsetzungen verschieden
• Gibt es also gar kein Continuous Delivery Tool?
26
14
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
27
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery – Tooling (1)
• „The deployment pipeline has its foundation in the process of continuous integration and is in essence the principles of continuous integration taken to its logical conclusion.“ (J. Humble, D. Farley)
28
Bisheriger CI Fokus
CommitStage
AkzeptanzTest Stage
Performance Test Stage
Nutzer-abnahme
Stage
ProduktivStage
15
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Continuous Delivery – Tooling (2)
• CI Server werden bereits für alle möglichen Projekt Arten eingesetzt– Und integrieren dabei diverse Tool Arten (Build, Test, Lint, Coverage, …)
• Tools für einzelnen Continuous Delivery Konzepte sind vorhanden– Artefakt Repositories (CI-Server eigene Repos, Maven, …)– „Infrastructure as code“ (Puppet, Chef, …)
• Continuous Integration wird Continuous Delivery Server durch …– Integration der neuen CD spezifischen Tool Arten– Bereitstellung einer Deployment Pipeline (samt Stages, Jobs, Triggern)
29
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Namen sind Schall und Rauch
• Jeder gängige CI Server bietet Pipeline Bausteine an– Und ist somit ein CD Server
• Konkrete Namen können variieren – Teils historische Gründe, teils Abgrenzung zur Konkurrenz
• Exemplarische Beispiele („Your Mileage May Vary“)– Jenkins : Build Jobs, Build Steps, Post-build Actions, diverse Plugins– Go: Go Pipelines, Stages, Jobs, Tasks– Bamboo : Build Plans, Stages, Jobs, Tasks
• Erster logischer Schritt ist Visualisierung der Pipeline– Übersicht aller Pipelines eines CD Servers– Bisherige Aktivitäten einer Pipeline, i.e. vergangene Pipeline Instanzen
30
16
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Pipelines Dashboard in Go
31
(http://www.thoughtworks.com/products/docs/go/13.3/help/)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Pipeline Activity in Go
32
(http://www.thoughtworks.com/products/docs/go/13.3/help/)
17
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Build Pipeline Plugin in Jenkins
33
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
You Can Look But You Better Not Touch (1)
• Reine Visualisierung für „passive“ Pipelines ausreichend– Neue Pipeline Instanzen entstehen durch Ressourcen Änderungen
• Aber Benutzerinteraktion ist Teil der Pipeline Idee („Manual Trigger“)– „Manual Approval“ oder „Push Button Releases“ als Variationen
• Allgemeine Bedienelemente ebenfalls nötig– Pipeline Instanz ohne Ressourcen Änderung „von Hand“ erzeugen– Bestehende Pipeline pausieren
• Pipeline Visualisierung wird zur Pipeline GUI
34
18
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
You Can Look But You Better Not Touch (2)
35
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Wenn man jemandem den kleinen Finger reicht, …
• Visualisierung der Deployment Pipeline macht Lust auf mehr– und schafft dadurch neue GUI Probleme
• Die üblichen Verdächtigen sind oft gleich …
• Selektives „Überspringen“ von Stages– Deployen auf Produktion aber nicht auf Test Umgebung (z.B. bei Hotfix)
• Erneutes Ausführen einzelner Stages– Wiederholen automatisierter Tests (z.B. gleicher Code, neuer Agent)– Rollback oder Re-deploying (z.B. nach Produktions Crash)
• Zentralisierte Rechteverwaltung für manuelle Trigger– Bestimmte Gruppen verwalten bestimmte System (z.B. Prod Admins)
36
19
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
… nimmt er gleich die ganze Hand
• GUI der Pipeline Aktivität um entsprechende Buttons ergänzen– Jede Pipeline Stage (auch vergangene) wahlfrei ausführbar machen
• Aber erzeugt dies implizit dann eine neue Pipeline Instanz?– Und wie visualisiere ich das eigentlich?
37
(http://www.thoughtworks.com/products/docs/go/13.3/help/)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Go Pipelines vs Deployment Pipelines
• „A Go Pipeline does not necessarily map one-to-one with what is referred to as the automated deployment pipeline in continuous delivery literature. The automated deployment pipeline is essentially the end-to-end CD value stream. This end to end value stream is often better modeled using multiple Go Pipelines.“(http://www.thoughtworks.com/insights/blog/how-do-i-do-cd-go-part-2-pipelines-and-value-streams)
• Mehrere Go Pipelines bilden „Continuous Delivery Value Stream“– Und dieser entspricht der Deployment Pipeline– (Go) Pipelines sind plötzlich also auch Bausteine
• Go bietet „Value Stream Maps“ zur Visualisierung an– Zeigt Status einer bestimmten Go Pipeline Instanz …– sowie alle dazu beitragenden Upstream Abhängigkeiten … – und alle daraus entstandenen Downstream Abhängigkeiten
38
20
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Value Stream Maps in Go
39
(http://www.thoughtworks.com/products/docs/go/13.3/help/)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Environments in Go
• Environments zuvor nur implizit vorausgesetzt (UAT, Produktion, …)
• Go erlaubt explizites Anlegen und Verwalten von Environments
• Jede Pipeline gehört zu maximal einer Environment
• Erlaubt Darstellung in welcher Umgebung was läuft
40
21
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
WAT
• „The deployment pipeline has its foundation in the process of continuous integration and is in essence the principles of continuous integration taken to its logical conclusion.“ (J. Humble, D. Farley)
• „Continuous Integration was not designed for Continuous Delivery. Continuous Integration is designed to keep developers informed about the state of the latest code changes.“ (Atlassian Bamboo Doc) (https://confluence.atlassian.com/x/LgQrF)
• Was will uns der Autor damit sagen?
41
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
He french fried when he should have pizza'd
• Deployment meist nicht durch Development sondern Operations– Unterschiedliche Personen mit unterschiedlichen Aufgaben
• CI Server Tooling ist auf Development ausgerichtet
• „Aber wir haben doch jetzt auch Pipelines im CI Server…“– Eine nachträgliche Abstraktion perfekt passend für…– „Der letzte erfolgreiche Build wird zeitnah deployt “
42
22
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Wünsch Dir was (1)
• Ziel: Stabiler Betrieb aller Umgebungen und der deployten Software– Deployment ist nur Ops Teilaspekt, zentrale Fragen sind abstrakter
• Welche Releases existieren? Welche User Stories sind enthalten?– Welche Tests sind für das Relases gelaufen? Haben User getestet?– Bei Bedarf: Welche konkreten VCS Commits sind enthalten?
• Was sind die Unterschiede zwischen zwei bestimmten Releases?– Nein zu „grep VCS Logs“ und „Klicken in Pipeline Activity Graphiken“
• Welche Umgebungen existieren und mit welchen Rechten?– Wie kann ich diese Rechte zentral rollenbasiert verwalten?
43
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Wünsch Dir was (2)
• Welche Releases laufen in einer Umgebung?– Wie ist Historie der Releases in einer Umgebung? – Wer hat wann welches Release deployt? Wer hat es freigegeben?
• Wie führe ich ein Release Rollback in Umgebung durch?– Nein zu „Wiederhole erste Stage aus Pipeline rel2prod mit Revsion 42“
• „Give deployments the first-class treatment“– Klare Schnittstelle zwischen Dev und Ops
44
23
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Projects in Bamboo (1)
• Build Plan erzeugt und testet Build Artefakte– „Klassische“ Continuous Integration (Dev Sicht)– Kapselt Build Prozess Details, fungiert nach außen als Artefakt Quelle
• Deployment Project abstrahiert zu deployende Software (Ops Sicht)– Deployment Project ist fest mit einem Build Plan verknüpft
• Deployment Projects definieren Environments– Laufzeitumgebungen mit Berechtigungen und Artefakt Deploy Skripten
• Für Deployment von Artefakten muss Release erzeugt werden– Bündelt Artefakte eines konkreten Builds zur deploybaren Einheit– Verbindung Deployment und Build Prozess (Dev Ops Brücke)
45
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Deployment Project in Bamboo (2)
46
Artifacts
Build #15
Foo.jarBar.jar
Build #16
Foo.jarBar.jar
Build #17
Foo.jarBar.jar
Snafu.jar
Environments
Entwicklung
Produktion
Test
1.2
1.2
1.3
Releases
Release1.3
Release1.2
#15
#17
24
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Demonstration
47
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
48
25
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Die Tücke im Detail
• Continuous Delivery ist Fortsetzung von Continuous Integration– Continuous Integration Tooling ist bekannt und etabliert
• Aber: Jetzt nicht mehr nur Development beteiligt, sondern auch…– Quality Assurance in Stage „Manual Testing“– Operations in Stage „Release“
• Problem wird „verschärft“ durch „neue“ Methoden und Technologien– Agile Projekte releasen häufiger als Wasserfall Projekte– Verfügbarkeit von Server Hardware stetig wachsend (Cloud)– Bisheriger Release Stress und Sockelkosten nicht mehr tragbar
• Beteiligte Gruppen müssen stärker zusammenrücken– Betrifft vor allem Development und Operations
49
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
First things first
• Neues Buzzword notwendig: DevOps
• Portmanteau (Kofferwort) aus „Development“ und „Operations“
• Erste Verwendung „DevOpsDays 2009“ in Belgien
50
DevOps […] is a software development method that stresses communication, collaboration and integration between software
developers and information technology (IT) professionals.
(http://en.wikipedia.org/wiki/Devops)
26
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Houston, we have a problem (1)
• Zwei beteiligte Parteien mit gegenläufigen Zielen– Development will neue Features (Change)– Operations will hohe und schnelle Verfügbarkeit (Stability)– Konkurrenz, da häufig keine übergreifende Sicht in Unternehmen
• Trennung durch „Wall of Confusion“– Unterschiedliche Ziele und unterschiedliche Tools– „Wir werfen Operations dann den nächsten Release über den Zaun“
51
(Quelle: http://dev2ops.org/2010/02/what-is-devops/)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Houston, we have a problem (2)
• Nach fehlgeschlagenen Relase spielen alle „The Blame Game“– Ops: Artefakte, Skripte, Config Files, … waren fehlerhaft– Dev: Bei uns hat es funktioniert, ihr habt was falsch gemacht– Ops: Ihr müsst selber drauf schauen, was nicht stimmt– Dev: Wir kommen doch gar nicht auf die Prod Maschinen (usw.)
• In der Zwischenzeit kann niemand arbeiten– Fachabteilung ist es egal, ob Development oder Operations schuld
• Rollback eines teilweise durchgeführten Releases oft unmöglich– Releases nicht atomar, häufig im Bereich Datenbankänderungen
• Releases wird als Konsequenz „irgendwie“ lauffähig gemacht– Oft „Dirty Hacks“ ohne Lerneffekt dafür mit versteckten Fehlern
52
27
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Déjà vu
• „Wall of Confusion“ ist nicht neu
• Frühere Trennung zwischen Business und Development
• Lösung war agile Entwicklung
• DevOps soll gleiches für Development und Operations leisten
53
(Quelle: http://dev2ops.org/2010/02/what-is-devops/)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Hund, Katze, Maus, …
• Zur Zeit noch kein DevOps de facto Standard verfügbar– … auf dem Level von Fowlers CI Artikel oder dem CD Buch
• Selbst die Definition variiert noch je nach Quelle– Devlopment Method (Wikipedia), Movement (Gartner), …– „DevOps is not about a technology, it is about a business problem“
• Mögliches Standardwerk „The DevOps Cookbook“ angekündigt– Vertrauensvorschuss durch Autoren (Patrick Debois, Gene Kim, …)– Vermutlich weitreichender als nur DevOps (eher bus-qa-sec-net-ops)
• Zur Zeit hauptsächlich Online Material und Quellen für DevOps– Inhalte stark abhängig von jeweiligen Autoren– Expose prod logs, Devs wear pagers, Ops stories in project backlog, …
54
28
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Patterns again, …
• „Agile DevOps“ Reihe von Paul Duvall als exemplarisches Beispiel– Online Liste von DevOps Pattern bei IBM DeveloperWorks– Starker Fokus auf „Infrastructure as code“ Themen
• Scripted environments– Automatisierte und versionierte Bereitstellung einer Server Umgebung– Server Umgebung ist Teil des Deployments auf Produktion– Mögliche Tools: Chef oder Puppet
• Test-driven infrastructures– Wenn Infrastruktur Code ist, dann muss Infrastruktur getestet werden– Testet ob alle Bestandteile der Infrastruktur verfügbar sind– Beispiel: Test, ob Apache in richtiger Version läuft
55
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
… again …
• Chaos Monkey– „Everything fails, all the time“ (Werner Vogels)– Terminiert regelmäßig Instanzen in einer Gruppe von Systemen und …– Testet indirekt, ob das System trotzdem weiterläuft– Schlägt in kontrollierten Zeiten zu, um für den Ernstfall bereit zu sein
• Transient environments– Umgebungen sind so kurzlebig wie möglich (Stunden bis Tage)– Keine „heiligen“ Server mehr, mit nicht reproduzierbarer Konfiguration– Forciert Konzept, dass alles automatisiert sein muss
56
29
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
… and again.
• Version everything– Ziel ist Etablierung einer „single source of truth“– Maximal ein Checkout zum Loslegen für einen neuen Entwickler
• Delivery Pipeline– Vergleiche Deployment Pipeline aus Continuous Delivery
• DevOps Dashboard– Anzeige wie Änderungen das System in welcher Stage wie beeinflussen– Für alle beteiligten Gruppen zugänglich– Häufig im Continuous Integration Server verankert
57
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Frage des Standpunkts
• Continuous Delivery und DevOps sind miteinander verwandt– Ähnliche oder zumindest überlappende Prinzipien und Kernbegriffe
• Keine gegenseitige Ignoranz sondern vielmehr gleiches Ziel– Veröffentlichungen beziehen sich auf den jeweils anderen Begriff
• „Flattening“ von Release Prozessen und Organisationsstrukturen– Wunsch sind schnellere, billigere und bessere Releases
58
30
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Gliederung
• Einleitung
• Continuous Delivery
• Tool Time
• DevOps
• Zusammenfassung
59
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Zusammenfassung
• Kundenzufriedenheit erfordert Auslieferung von Software– Klassische Release Modelle sind zu unflexibel für moderne Entwicklung
• Continuous Delivery soll helfen dieses Problem zu lösen– Deployment Pipelines als Hilfsmittel in aktuellen CI Servern verfügbar
• Ende der Fahnenstange im Bereich CD Tooling noch nicht erreicht– CI Server Hersteller konkurrieren mit neuen Features und Ideen
• Auslieferung erfordert Team übergreifende Zusammenarbeit– Vor allem zwischen Development und Operations
• Zwischen Development und Operations steht „Wall of Confusion“– DevOps will diese Wand mit Methoden und Verfahren überwinden
60
31
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
If you remember one thing
61
“In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand.”
(“The Phoenix Project”)
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Links
• Schulung: Versionsverwaltung mit Git– http://www.oio.de/git-schulung-versionsverwaltung-seminar-dvcs-
training.htm
• Schulung: Versionsverwaltung mit Subversion– http://www.oio.de/subversion-svn-schulung.htm
• Schulung: Hudson Grundlagen– http://www.oio.de/schulung-hudson-seminar-continuous-integration-
training-jenkins.htm
• Schulung: JIRA – Fachliche Administration – http://www.oio.de/seminar/methodik-prozess-management-soft-
skills/seminar-training-atlassian-jira-schulung.htm
62
Mehr von OIO zum Thema…
32
Von Continuous Integration zu Continuous Delivery© 2013 Orientation in Objects GmbH
Links
• Artikel aus dem Java Spektrum: Optimiertes Testen (PDF)– http://www.oio.de/public/softwaretest/optimiertes-
testen-gateways-gatekeeper-keymaster_JS_03_11.pdf
• Beratung zu Open Source Tools:– http://www.oio.de/beratung-consulting/open-source-
software/tools/
63
Mehr von OIO zum Thema…
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.de
??
? ?
????
Fragen ?
64
33
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.de
Vielen Dank für ihre Aufmerksamkeit !