$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Continuous Delivery ist keine Technologie (W-JA...
Search
Joerg Mueller
November 06, 2013
Programming
0
11
Continuous Delivery ist keine Technologie (W-JAX 2013)
Joerg Mueller
November 06, 2013
Tweet
Share
More Decks by Joerg Mueller
See All by Joerg Mueller
Struktur vor Zufall: Verlässlichere KI-Systeme bauen mit Pydantic AI
joergm
0
41
The Tech Stack Canvas (engl.)
joergm
0
100
The Tech Stack Canvas (BED-Con 2023)
joergm
0
180
Was hat der Produktlebenszyklus mit Software-Architektur zu tun? (BED-Con 2023)
joergm
0
220
Istio, Linkerd 2, or …? A comparison of Service Mesh implementations
joergm
0
40
ISTIO, LINKERD UND CO. IM VERGLEICH: WELCHES SERVICE MESH PASST ZU MIR?
joergm
0
40
Kubeless - Das Beste aus zwei Welten (Continuous Lifecycle 2018)
joergm
0
14
Microservice Architekturen praktisch - Kubernetes (Architecture Summit 2018)
joergm
0
23
Kubernetes - the abstract cloud (Microservice Summit 2018)
joergm
0
25
Other Decks in Programming
See All in Programming
20251127_ぼっちのための懇親会対策会議
kokamoto01_metaps
2
430
生成AIを利用するだけでなく、投資できる組織へ
pospome
1
310
S3 VectorsとStrands Agentsを利用したAgentic RAGシステムの構築
tosuri13
6
310
AIコーディングエージェント(Gemini)
kondai24
0
210
著者と進める!『AIと個人開発したくなったらまずCursorで要件定義だ!』
yasunacoffee
0
130
JETLS.jl ─ A New Language Server for Julia
abap34
1
370
CSC509 Lecture 14
javiergs
PRO
0
220
ローターアクトEクラブ アメリカンナイト:川端 柚菜 氏(Japan O.K. ローターアクトEクラブ 会長):2720 Japan O.K. ロータリーEクラブ2025年12月1日卓話
2720japanoke
0
730
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
7k
ハイパーメディア駆動アプリケーションとIslandアーキテクチャ: htmxによるWebアプリケーション開発と動的UIの局所的適用
nowaki28
0
420
手軽に積ん読を増やすには?/読みたい本と付き合うには?
o0h
PRO
1
170
【CA.ai #3】ワークフローから見直すAIエージェント — 必要な場面と“選ばない”判断
satoaoaka
0
240
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Git: the NoSQL Database
bkeepers
PRO
432
66k
A designer walks into a library…
pauljervisheath
210
24k
Building an army of robots
kneath
306
46k
Making the Leap to Tech Lead
cromwellryan
135
9.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Scaling GitHub
holman
464
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Transcript
Continuous Delivery ist keine Technologie Marco Kisperth, Jörg Müller
Marco Kisperth der Product Owner @kisperth Jörg Müller der Techniker
@joergm
Unser Product Owner hatte eine Vision!
Update der Anwendung mindestens einmal pro Stunde möglich
Features werden während der Umsetzung laufend ausgerollt
Ein System für Produktion, Akzeptanz, Preview und Schulung
Wir hatten erstmal gewaltige Zweifel!
„Jeder Commit automatisch auf Produktion!“
None
Wer bezahlt den Aufwand für die automatisierte Testabdeckung?
Wie soll so ein automatisches Deployment funktionieren?
Jetzt sollen If-Bedingungen für neue Features in den Code?
Warum wollte der Product Owner so etwas?
Nur ein genutztes Feature ist ein gutes Feature
Keine goldenen Wasserhähne
Features in kleinen Schritten zur Verfügung stellen
Weniger Komplexität
Mehr Zufriedenheit
Was mussten wir tun, damit es funktioniert?
Kein extra QA
Operations im Team
Support durch Business Analysten und Developer
Alle Verantwortung und Fähigkeiten mussten in ein Team
Technologisch brauchten wir eine Deployment Pipeline
Automatisierte Test-Stages aber nur ein Stage für Menschen
Der Test-Modus ersetzt das Preview- System test
Feature Switches sind nötig, aber seltener, als man denkt
Kanban statt Scrum pull
Commanders Intent Acceptance Tests Kommunikation ! keine detaillierte Spezifikation !#?
Community mit Anwendern und Entscheidern aufbauen
Anwendungs-Controlling
Die Anwendung informiert selber über Änderungen neu
Wie weit sind wir damit gekommen?
500.000 Zeilen Code (Java, Javascript, Groovy, XML, HTML)
21.000 Unit Tests & 400 Selenium Test
Fehler schnell beheben ist wichtiger als vermeiden
17 „Entwickler“, 3 BA, 1 UX, 1 PO
Klassische Rollenbilder gemischt
Was hat es in uns verändert?
„Das ist mein Produkt“
Test Driven Development
Refactoring in small steps
Agile Methoden und Continous Delivery greifen perfekt ineinander!
Keine Abstimmung zum Rollout nur Freischalten ist Entscheidung des Product
Owners
Feature oder Bugfix Wo ist der Unterschied?
Neue Prioritäten für Bugfixes/Findings Quickwins first
Hard-Coded ist die neue Konfigurierbarkeit
Was sind die Voraussetzungen?
„Einfach“ beginnen Es gibt kein „Fertig“
„Seniore“ Teammitglieder
Ohne Disziplin geht es nicht
Nein sagen! Der Sog zum klassischen Vorgehen wird stark sein
Eigenverantwortung muss gewollt und möglich sein
Haben sich die Erwartungen erfüllt?
JA!
Themen können technisch und fachlich fertiggestellt werden!
Continuous Delivery ist ein Mindshift
Marco Kisperth
[email protected]
@kisperth Jörg Müller
[email protected]
@joergm blog-it.hypoport.de Vielen
Dank an Verena Würfel für die Erstellung der Grafiken