Continuous Delivery Workshop

Transcript

1. Continuous Delivery Workshop_ Alexander Müller codecentric AG
2. Continuous Delivery 2
3. Agile Software Factory More than just an agile process 3 Scrum Kanban Meetings Work Breakdown Progress Control Team Efficiency Trans- parency Artifacts Development Process Evolutionary Architecture Configuration Management Version Control Pull Requests Tagging Team Branches Feature Branches Clean Code SRP OCP LSP ISP DIP DRY KISS TDA S L I D O Continuous Integration Build automation Cont. Deploy- ment Test- automation Cont. Delivery Agile Testing TDD ATDD Acceptance Criteria Test Concept Test Automation Quality Assurance Refactoring Handling Defects Documen- tation Technical Debts Pair Program- ming Metrics Code Reviews
4. Continuous...? 4 Continuous Integration Continuous Delivery Continuous Deployment Knopfdruck nicht mehr notwendig Release auf Knopfdruck jederzeit möglich automatische Builds und Tests
5. Continuous...? 5 Continuous Integration Continuous Delivery Continuous Deployment Knopfdruck nicht mehr notwendig Release auf Knopfdruck jederzeit möglich automatische Builds und Tests
6. Continuous...? 6 Continuous Integration Continuous Delivery Continuous Deployment Knopfdruck nicht mehr notwendig Release auf Knopfdruck jederzeit möglich automatische Builds und Tests
7. Die traditionalle IT-Organisation 7 Requirements -Analyse High-Level Design Detailliertes Design Implementierung Unit Testing Integration Testing Systemtest
8. Continuous Integration / Continuous Feedback 8
9. Warum Continuous Delivery? Beschleunigter und automatisierter Prozess: §  Höhere Wertschöpfung §  Bessere Release-Qualität §  Reduzierte Entwicklungskosten §  Produktive Kollaboration §  Erhöhte Kundenzufriedenheit 9
10. Implement Continuous Delivery: Prozess und Werkzeuge Entwicklung Code & Test Business Ideen / Anfiorderungen 10
11. Change Time # Deployments / T # Bugs Cost # Deployments Time Profit Invesm. Puppet Git, Jenkins, Bamboo, Nexus, Maven JUnit, Fitnesse, JBehave, Robot, Selenium T P A O FULLY AUTOMATED SOFTWARE DELIVERY and RELEASE MANAGEMENT PROCESS CONTINUOUS INTEGRATION AUTOMATED TEST AUTOMATED PROVISIONING •  Improve quality •  Increase predictability XLDeploy AUTOMATED DEPLOYMENT •  Release insight •  Reduce release time •  Reduce errors •  Less downtime •  Cost reduction •  Improve reliability •  Repeatable •  Reduce Cost •  Increase speed •  Reduce costs •  Increase speed •  Reduce risk •  Reduce Cost ARCHITECTURE AGILE PROCESS •  Deliver fast •  Deliver often •  Do the right things CONTINUOUS DELIVERY: “REMOVE WASTE FROM YOUR SOFTWARE DELIVERY PROCESS" Docker, Ansible, Puppet, Chef Bestandteile einer CD-Pipeline JIRA, Confluence 11
12. Commit Build Unit Test SonarQube Code Review Nexus Deployment: Integration Test System Genehmigung durch technischen Betrieb Deployment: Production System Continuous Delivery Pipeline (Beispiel) 12
13. Voraussetzungen für Continuous Delivery 13
14. Was ist das Ziel? 14 Das Feature soll zum Kunden intern: zum Benutzer © pixabay.com, Creative Commons CC0 knowyourmeme.com
15. Was ist das Ziel? 15 Das Feature soll zum Kunden intern: zum Benutzer © pixabay.com, Creative Commons CC0 knowyourmeme.com Feedback
16. Schritt 1: Rückverfolgbarkeit 16 Anforderungsdokumente Lastenheft Pflichtenheft Use Cases User Stories Customer Journeys Story Maps Spezifikationen © pixabay.com, Creative Commons CC0 #3 #14 #159 #26 #5 #358 #97 eindeutige Identifikatoren
17. 17 Baue eine Festung für master master 1.1 1.2 The Castle of Belogradchik, © Klearchos Kapoutsis 2009, CC-BY-2.0 Schritt 2: Branching
18. Schritt 2: Branching 18 develop master 1.1 1.2
19. Schritt 2: Branching 19 develop feature/RD-20 master 1.1 1.2
20. Exkurs: Git vs. Subversion 20
21. Unterschiede zu SVN (1) SVN Repository Working Copy Working Copy Working Copy Git Repository Git Repository Git Repository Git Repository Git Repository zentrale Versionskontrolle vs. dezentrale Versionskontrolle 21
22. Unterschiede zu SVN (2) SVN •  “When in doubt, do like CVS” •  Branches und Tags sind Verzeichnisse •  Merges sind umständlich •  Commit IDs sind fortlaufende Zahlen Git •  “When in doubt, do exactly the opposite of CVS” •  Branches und Tags sind Labels für Commits •  automatische Merge-Strategien sind integriert •  Commit IDs sind SHA-1 Hashes 22
23. Unterschiede zu SVN (3) Terminologie SVN Git Commit (remote) Commit (local) + Push Update Pull Checkout Clone - Fetch Branch Local Branch / Remote Branch - Index / Staging Area / Cache trunk master 23
24. Unterschiede zu SVN (4) Commit & Push SVN Repository Working Copy SVN Git Commit (remote) Git Repository Git Repository Push Commit (local) 24
25. Staging Area History Staging Area Working Directory git checkout git commit git add git reset 25
26. Feature Branches (1) ohne Branches mit Branches 26
27. Feature Branches (2) ohne Branches mit Branches nicht auslieferungsfähig immer auslieferungsfähig 27
28. Feature Branches (3) Verzeichnisstruktur SVN Git /module1 /trunk /src/main/java/Application.java /branches /feature1 /src/main/java/Application.java /feature2 /src/main/java/Application.java /tags /version1 /src/main/java/Application.java /module2 /trunk /branches /tags ... /module1/src/main/java/Application.java /module2 ... 28
29. Merging (1) SVN Application.java v1 SuperApplication.java v1 Application.java v1 Application.java v2 Application.java v3 Umbenennung Code-Änderung Code-Änderung 29
30. Merging (2) Git Application.java v1 SuperApplication.java v2 Application.java v1 Application.java v2 Application.java v3 Umbenennung Code-Änderung Code-Änderung Vorläufer Vorläufer Vorläufer 30
31. Exkurs-Exkurs: Git Workflow-Strategien 31
32. Pull Requests (1) 3 2 Pull •  = Fetch + Merge •  Aktuellen Stand des Branches von einem anderen Repository übertragen •  Übertragenen Branch in einen anderen Branch überführen Pull Request •  “Bitte integriere meinen Branch in deinen!”
33. Pull Requests (2) 3 3 Bitte integriere meinen Branch! Lass mich noch kurz in den Code schauen… Branch erstellt Arbeit auf dem Branch Merge des Branches
34. Continuous Integration (1) 3 4 Branch per Feature + CI •  Kritiker: “Das ist kein reines CI!” •  Antwort: “Eben.” •  Feature Branches sind kurzlebig •  Feature Branches sind isoliert •  Gleichzeitiges Arbeiten an Dateien sorgt für Instabilität •  Feature Branches können in dedizierten Integration-Branches zusammengeführt werden
35. Continuous Integration (2) 3 5 INTEGRATE AND TEST ALL THE THINGS
36. Git Flow (1) 3 6 •  Striktes Branching-Modell •  Zwei Branches statt nur master: •  master: Release History •  develop: Integration-Branch v1.0 v2.0 v3.0 master develop
37. Git Flow (2) 3 7 •  Feature Branches werden von develop abgezweigt v1.0 v2.0 v3.0 master develop feature/ticket-1
38. Git Flow (3) 3 8 •  Release Branches werden von develop abgezweigt •  Auf Release Branches findet keine Feature- Entwicklung statt v1.0 v2.0 master develop release/v3
39. Git Flow (4) 3 9 •  Hotfix-Branches werden von master abgezweigt v1.0 v1.1 master develop hotfix/broken-feature
40. Git Flow (5) 4 0 Quelle: Vincent Driessen http://nvie.com/posts/a-successful-git-branching-model/
41. Voraussetzungen für Continuous Delivery (contd.) 41
42. Schritt 3: Automatische Tests 42 feature/RD-20 Test-Driven Development?
43. Schritt 3: Automatische Tests 43 Test Concept Unit Tests -  Schnell -  Stabil -  Refaktorierung ist einfach -  Vorbedingung für Refaktorierung Service Tests -  Schnell -  Stubs/Mocks werden benötigt UI Tests -  Langsam -  Nicht stabil -  Hoher Wartungsaufwand
44. Schritt 3: Automatische Tests 44 develop feature/RD-20 master feature/RD-2 1.1 1.2 Tests sind erfolgreich Tests schlagen fehl
45. Schritt 3: Automatische Tests UI-Tests: Specification By Example (JBehave) 45 Narrative:   In  order  to  keep  a  clean  database  of  books   As  a  librarian   I  want  to  have  my  entries  validated     Scenario:   Given  an  empty  library     When  the  librarian  tries  to  add  a  book  with  an  <attribute>  of  <value>     Then  the  library  contains  a  no  book  with  an  <attribute>  of  <value>   And  the  page  contains  error  message  <message>     Examples:       |  attribute  |  value            |  message                              |   |  ISBN            |  5234567969  |  ISBN  is  not  valid          |   |  Edition      |  2.  Edition  |  Edition  is  not  valid    |    
46. Schritt 4: Code Reviews 46 © Focus Shift/OSNews/Thom Holwerda 2008
47. Exkurs: Technische Schulden 47
48. Technische Schulden und Produktivität Entwicklung neuer Features Technische Schulden abbauen!
49. Technische Schulden in 3 Schritten bekämpfen 1.  Vermeide neue technische Schulden 2.  Reduziere technische Schulden in jeder Iteration 3.  GOTO 1
50. Technische Schulden (Code Smells): Beispiele Duplicate code identical or very similar code exists in more than one location Large method a method, function, or procedure that has grown too large Large class a class that has grown too large. See God object. Feature envy a class that uses methods of another class excessively Inappropriate intimacy a class that has dependencies on implementation details of another class Refused bequest a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See “L” in SOLID (Liskov substitution principle) Lazy class a class that does too little Contrived complexity forced usage of overly complicated design patterns where simpler design would suffice Excessively long identifiers in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture 50
51. Technische Schulden mit SonarQube aufdecken Plattform zur Visualisierung von Code Qualität: §  Architektur & Design §  Kommentare §  Coding Rules §  Potentielle Bugs §  Komplexität §  Duplikation von Unit Tests Integriert §  Checkstyle prüft Coding Standards §  Findbugs analysiert Java-Klassen, um Bugs zu finden §  PMD sucht im Source Code nach potentiellen Problemen 51
52. Technische Schulden vermeiden: Test-Driven Development TDD Zyklus: §  Code wird test first geschrieben §  Der Test führt das Design des Codes und validiert gleichzeitig die Implementierung §  Continuous Refactoring führt zu Clean Code 52
53. Voraussetzungen für Continuous Delivery (contd.) 53
54. Schritt 5: Merging & Release 54 © pixabay.com 2012, Creative Commons CC0
55. Schritt 6: Automatisches Deployment 55 Why I’ll Never be an Adult, © Hyperbole and a Half 2010
56. Configuration Management 56
57. Stages 57 Test Staging Production Datenbank: test.example.com Cluster: keins Load Balancer: keiner Datenbank: staging.example.com
 Cluster: 1 Node Load Balancer: keiner Datenbank: production.example.com Cluster: 30 Nodes Load Balancer: aktiv
58. Beispiel: Datenbank 58 key value ldap.host ldap.example.com ldap.admin.username admin ldap.admin.password c0d3c3ntr1c$ru73z! (fast) zentrale Konfiguration (weitere Konfiguration für DB-Verbindung notwendig)
59. Beispiel: Properties-Datei 59 db.host=localhost db.admin.username=admin db.admin.password=c0d3c3ntr1c$ru73z! ldap.host=ldap.example.com ldap.admin.username=admin ldap.admin.password=c0d3c3ntr1c$ru73z!
60. Beispiel: Environment Detection 60 IP Adresse? Test Konfiguration Staging Konfiguration Production Konfiguration 192.168.0.11 52.17.31.109 52.18.27.55
61. Anti-Pattern: Abhängigkeit zum Container 61 Keine Abhängigkeit zum Container erzeugen, denn...
62. Deployment vs. Provisionierung 62
63. Deployment 63 Deployment erfolgt für: •  Anwendung •  Scripts für Migrationen
64. Provisionierung 64 Provisionierung erfolgt für: •  Betriebssystem •  Netzwerk •  Datenbankserver •  Container / Application Server
65. Provisionierungsmethoden 65 •  Vorlagen für virtuelle Maschinen klonen •  automatisierte Provisionierung from scratch •  Ansible •  Chef •  Puppet
66. Best Practice: Infrastructure as Code 66 •  Versionierung der Infrastruktur •  Infrastruktur passt zur Anwendung •  Code Reviews!
67. Best Practice: Docker - Single Responsibility Principle 67 Leichtgewichtige Container, die einem Zweck dienen Einmalige Provisionierung + Image Repositories zur Wiederverwendung
68. 68 Feedback
69. Fallbeispiel: Continuous Delivery mit der Atlassian Tool Suite 69
70. In a Nutshell 70 Prioritize Stories Select Stories for Sprint Write Stories Refine Stories for Work Create Feature Branch Compare Branches and Commits Create Pull Requests Review Code Update Task Progress View Corresponding Tickets Require Minimum Review Approvals Require Successful Build See Pull Requests & Commits w/ Failing Builds Detect Failing Builds Analyze Build Logs View Corresponding Tickets Deploy to Multiple Heterogeneous Target Systems View Corresponding Builds View Corresponding Commits View Corresponding Pull Requests View Corresponding Deployments Create Releases Merge Branches Deploy Continuously Track Progress of Implementation
71. JIRA Agile: Sprint Backlog & Product Backlog 71
72. JIRA Agile: Task Board 72
73. JIRA Agile: Sprint Burndown Diagram 73
74. JIRA Agile: Task Board (contd.) 74
75. JIRA Agile: Task Board (contd.) 75
76. JIRA Agile: Task Board (contd.) 76
77. JIRA Agile: Feature Branches 77
78. Stash: Feature Branches 78
79. Stash: Feature Branches (contd.) 79
80. Stash: Feature Branches (contd.) 80
81. Stash: Feature Branches (contd.) 81
82. Stash: Feature Branches (contd.) 82
83. Stash: Pull Requests 83
84. Stash: Pull Requests (contd.) 84
85. Stash: Pull Requests (contd.) 85
86. Stash: Code Review 86
87. Stash: Code Review (contd.) 87
88. Stash: Merge-Bedingungen 88
89. Stash: Merging 89
90. Stash: Merging (contd.) 90
91. Bamboo: Deployment 91
92. Bamboo: Continuous Delivery & Deployment 92
93. Bamboo: Continuous Delivery 93
94. Bamboo: Continuous Deployment (contd.) 94
95. JIRA: Überblick 95
96. JIRA: Überblick (contd.) 96
97. Was war noch gleich Schritt 1? 97
98. CloudBees Jenkins vs. Atlassian Bamboo 98
99. Kosten 99 CloudBees Jenkins •  Kostenlos in der Basisausführung •  CloudBees Jenkins Team Edition, Enterprise und Operations Center sind kostenpflichtig •  Preise hängen von der Konfiguration ab und müssen angefragt werden Atlassian Bamboo •  Kostenpflichtig •  Preise hängen von der Anzahl der Remote Agents ab
100. GUI CloudBees Jenkins < Atlassian Bamboo 100
101. Plugins CloudBees Jenkins •  1000+ Plugins verfügbar •  hauptsächlich kostenlos Atlassian Bamboo •  150+ Plugins verfügbar •  hauptsächlich kostenpflichtig •  Plugins werden durch Atlassian verifiziert 101
102. Integration CloudBees Jenkins •  Verlinkung von JIRA-Tickets via Plugin Atlassian Bamboo •  Out-of-the-box mit JIRA und Stash •  Bidirektionale Integration •  JIRA Tickets verweisen auf Builds •  Builds verweisen auf JIRA Tickets •  Branches verweisen auf Builds •  Builds verweisen auf Branches •  Release Management mit JIRA 102
103. Branch Management CloudBees Jenkins •  nur über Plugins mit limitierten Funktionen Atlassian Bamboo •  Automatische Branch-Erkennung •  Plan Branches •  pro VCS Branch kann ein Branch vom Plan erzeugt werden - automatisch 103
104. Pipelines CloudBees Jenkins •  nur über Plugins mit limitierten Funktionen Atlassian Bamboo •  Out-of-the-box •  Pläne können andere Pläne auslösen •  Ausführung von Plänen können an Bedingungen geknüpft werden Beispiel: Pläne A und B müssen erfolgreich durchgelaufen sein, damit Plan C ausgelöst wird 104
105. Verteilte Builds CloudBees Jenkins •  Out-of-the-box •  „Remote Node“ Atlassian Bamboo •  Out-of-the-box •  „Remote Agent“ 105
106. Feedback 106
107. Agility 107
108. Implementing Innovation 108
109. Agile? Agile is not a Process it Defines a Culture 109
110. Das Agile Manifest 110
111. Agile Mindset Menschen sind intrinsisch motiviert – Arbeit macht Spaß Fehler sind eine Gelegenheit um zu lernen Verschiedene Ansichten führen in agilen Teams zu besseren Ergebnissen Transparenz ist der Schlüssel zur kontinuierlichen Verbesserung Mitarbeiter sind nicht nur Ressourcen Kundenwert ist die einzige valide Metrik zur Fortschrittskontrolle Entscheidungen werden vom gesamten Team getroffen und nicht von einzelnen Personen 111
112. Schneider Culture Model 112
113. Schneider Culture Model (contd.) 113
114. Transition 114 „culture eats strategy for breakfast“ (Peter Drucker)
115. Literatur 115 http://www.methodsandtools.com/archive/agileculture.php
116. Varianten der agilen Softwareentwicklung 116 Iterativ Basiert auf Iterationen mit fester Timebox e.g. Scrum Kontinuierlicher Fluss Basiert auf den Prinzipien aus dem Lean Manufacturing e.g. Kanban
117. Scrum 117 Kern-Praktiken & Characteristiken: §  Liefere einen kontinuierlichen Wertstrom §  Iterativ & inkrementell §  Empirischer Ansatz §  Transparenz §  Inspect & Adapt §  Selbstorganisierte, interdisziplinäre Teams
118. Scrum Core Principles 118 Short Iterations Agree to Change Collaboration Reflect Responsibility and Trust Communication Running Software Definition of Done Simple Solution Automate (Test, Build, Release)
119. Kanban 119 Kern-Praktiken & Characteristiken: §  Visualisiere den Workflow §  Limitiere Work in Progress (WIP) §  Messe und verwalte den Fluss §  Mache Prozessregeln explizit §  Implementiere Feedback-Schleifen §  Verbessere kollaborativ Entwickle experimentell
120. Agile Culture 120
121. Lean/Kanban Culture 121
122. Fragen? 122 Alexander Müller, Senior IT Consultant codecentric AG Merscheider Straße 1 42699 Solingen, Deutschland mobil: +49 (0) 172. 5252240 www.codecentric.de blog.codecentric.de speakerdeck.com/alexandermueller visusnet