Continuous Delivery Workshop (english)

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 automatic builds and tests
5. Continuous...? 5 Continuous Integration Continuous Delivery Continuous Deployment Knopfdruck nicht mehr notwendig release at the push of a button possible at any time automatic builds and tests
6. Continuous...? 6 Continuous Integration Continuous Delivery Continuous Deployment push of a button no longer necessary release at the push of a button possible at any time automatic builds and tests
7. The Traditional IT Organization 7 Requirements -Analysis High-Level Design Detailled Design Implementation Unit Testing Integration Testing System Testing
8. Continuous Integration / Continuous Feedback 8
9. Why Continuous Delivery? Accelerated and automated process: §  Higher value creation §  Better release quality §  Reduced development costs §  Productive collaboration §  Increased customer satisfaction 9
10. Implement Continuous Delivery: Process und Tools Dev Code & Test Business Ideas / Requirements 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 Parts of a CD Pipeline JIRA, Confluence 11
12. Commit Build Unit Test SonarQube Code Review Nexus Deployment: Staging System Deployment: Production System Continuous Delivery Pipeline (Example) 12
13. Requirements for Continuous Delivery 13
14. What is the Goal? 14 The feature should be delivered to the customer internally: to the user © pixabay.com, Creative Commons CC0 knowyourmeme.com
15. What is the Goal? 15 © pixabay.com, Creative Commons CC0 knowyourmeme.com Feedback The feature should be delivered to the customer internally: to the user
16. Step 1: Traceability 16 Requirements Documentation Specification Sheet Use Cases User Stories Customer Journeys Story Maps © pixabay.com, Creative Commons CC0 #3 #14 #159 #26 #5 #358 #97 Unique Identifiers
17. 17 Build a Fortress for master master 1.1 1.2 The Castle of Belogradchik, © Klearchos Kapoutsis 2009, CC-BY-2.0 Step 2: Branching
18. Step 2: Branching 18 develop master 1.1 1.2
19. Step 2: Branching 19 develop feature/RD-20 master 1.1 1.2
20. Side Note: Git vs. Subversion 20
21. Differences (1) SVN Repository Working Copy Working Copy Working Copy Git Repository Git Repository Git Repository Git Repository Git Repository Centralized Version Control vs. Distributed Version Control 21
22. Differences (2) SVN •  “When in doubt, do like CVS” •  Branches and tags are directories •  Merges are hard •  Commit IDs are sequential numbers Git •  “When in doubt, do exactly the opposite of CVS” •  Branches and tags are labels for commits •  Built-in automatic merge strategies •  Commit IDs are SHA-1 hashes 22
23. Differences (3) Terminology 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. Differences (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) without branches with branches 26
27. Feature Branches (2) not deliverable always deliverable 27 without branches with branches
28. Feature Branches (3) Directory Structure 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. Side Note of Side Note: Git Workflow Strategies 31
32. Pull Requests (1) 3 2 Pull •  = Fetch + Merge •  Fetch the current state of the branch from another repository •  Merge the fetched branch into another branch Pull Request •  “Please merge my branch into yours!”
33. Pull Requests (2) 3 3 Please merge my branch! Let me take a look on your code first... Branch created Work on branch Merge of the branch
34. Continuous Integration (1) 3 4 Branch per Feature + CI •  Critics: “That isn’t pure CI!” •  Answer: “That’s the point.” •  Feature branches are short-lived •  Feature branches are isolated •  Simultaneous working on files causes instability •  Feature branches can be merged into integration branches
35. Continuous Integration (2) 3 5 INTEGRATE AND TEST ALL THE THINGS
36. Git Flow (1) 3 6 •  Strict branching model •  Two branches instead of a single master branch: •  master: Release History •  develop: Integration Branch v1.0 v2.0 v3.0 master develop
37. Git Flow (2) 3 7 •  Feature branches are created from develop v1.0 v2.0 v3.0 master develop feature/ticket-1
38. Git Flow (3) 3 8 •  Release branches are created from develop •  No feature development on release branches v1.0 v2.0 master develop release/v3
39. Git Flow (4) 3 9 •  Hotfix branches are created from master 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. Requirements for Continuous Delivery (contd.) 41
42. Step 3: Test Automation 42 feature/RD-20 Test-Driven Development?
43. Step 3: Test Automation 43 Test Concept Unit Tests -  Fast -  Stable -  Easy to refactor -  Precondition for code refactoring Service Tests -  Fast -  Stubs/mocks required UI Tests -  Slow -  Unstable -  High maintenance effort
44. Step 3: Test Automation 44 develop feature/RD-20 master feature/RD-2 1.1 1.2 tests successful tests fail
45. Step 3: Test Automation 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. Step 4: Code Reviews 46 © Focus Shift/OSNews/Thom Holwerda 2008
47. Side Note: Technical Debt 47
48. Technical Debt and Productivity Development of new Featues Deal with Technical Debt
49. Fight Technical Debt in 3 Steps 1.  Avoid to take on new Technical Debt 2.  Liquidate Debt in every iteration 3.  Start with 1
50. Technical Debt (Code Smells): Examples 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. Locate Technical Debts with SONAR Platform for managing code quality: §  Architecture & design §  Comments §  Coding Rules §  Potential bugs §  Complexity §  Unit tests duplications Integrates §  Checkstyle checks coding standards §  Findbugs analyzes Java classes to find bugs §  PMD scans Java source code and looks for potential problems 51
52. Avoid Technical Debts in Advance: Test Driven Development TDD Cycle: §  Code is developed “test first” §  The test first drives code design, then also validates it‘s implementation §  Continuous Refactoring to achieve “clean code” 52
53. Requirements for Continuous Delivery (contd.) 53
54. Step 5: Merging & Release 54 © pixabay.com 2012, Creative Commons CC0
55. Step 6: Automated Deployment 55 Why I’ll Never be an Adult, © Hyperbole and a Half 2010
56. 56 Feedback
57. Case Study: Continuous Delivery with the Atlassian Tool Suite 57
58. In a Nutshell 58 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 Formerly known as:
59. JIRA Software (formerly JIRA Agile): Sprint Backlog & Product Backlog 59
60. JIRA Software: Task Board 60
61. JIRA Software: Sprint Burndown Diagram 61
62. JIRA Software: Task Board (contd.) 62
63. JIRA Software: Task Board (contd.) 63
64. JIRA Software: Task Board (contd.) 64
65. JIRA Software: Feature Branches 65
66. Bitbucket Server (formerly Stash): Feature Branches 66
67. Bitbucket Server: Feature Branches (contd.) 67
68. Bitbucket Server: Feature Branches (contd.) 68
69. Bitbucket Server: Feature Branches (contd.) 69
70. Bitbucket Server: Feature Branches (contd.) 70
71. Bitbucket Server: Pull Requests 71
72. Bitbucket Server: Pull Requests (contd.) 72
73. Bitbucket Server: Pull Requests (contd.) 73
74. Bitbucket Server: Code Review 74
75. Bitbucket Server: Code Review (contd.) 75
76. Bitbucket Server: Merge Restrictions 76
77. Bitbucket Server: Merging 77
78. Bitbucket Server: Merging (contd.) 78
79. Bamboo: Deployment 79
80. Bamboo: Continuous Delivery & Deployment 80
81. Bamboo: Continuous Delivery 81
82. Bamboo: Continuous Deployment (contd.) 82
83. JIRA Software: Overview 83
84. JIRA Software: Overview (contd.) 84
85. What was Step 1? 85 Formerly known as:
86. CloudBees Jenkins vs. Atlassian Bamboo 86
87. Kosten 87 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
88. GUI CloudBees Jenkins < Atlassian Bamboo 88
89. Plugins CloudBees Jenkins •  1000+ Plugins verfügbar •  hauptsächlich kostenlos Atlassian Bamboo •  150+ Plugins verfügbar •  hauptsächlich kostenpflichtig •  Plugins werden durch Atlassian verifiziert 89
90. 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 90
91. 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 91
92. 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 92
93. Verteilte Builds CloudBees Jenkins •  Out-of-the-box •  „Remote Node“ Atlassian Bamboo •  Out-of-the-box •  „Remote Agent“ 93
94. Feedback 94
95. Agility 95
96. Implementing Innovation 96
97. Agile? Agile is not a Process it Defines a Culture 97
98. Manifesto for Agile Software Development 98
99. Agile Mindset Humans are intrinsically motivated – work is fun Mistakes are an opportunity to learn Different views in an agile team lead to better results Transparency serves as a key to continuous improvement Employees are not just resources Customer value is the only valid metric for progress control Decision making is done by the whole team not individuals 99
100. Schneider Culture Model 100
101. Schneider Culture Model (contd.) 101
102. Transition 102 „culture eats strategy for breakfast“ (Peter Drucker)
103. Further Information 103 http://www.methodsandtools.com/archive/agileculture.php
104. Styles of Agile Software Development 104 Iterative Based on time-boxed iterations of fixed duration e.g. Scrum Continuous Flow Based on principles derived from Lean Manufacturing e.g. Kanban
105. Scrum 105 Core Practices & Characteristics: §  Deliver a continuous stream of value §  Iterative & Incremental §  Empirical Approach §  Transparency §  Inspect & Adapt §  Self organized, interdisciplinary Teams
106. Scrum Core Principles 106 Short Iterations Agree to Change Collaboration Reflect Responsibility and Trust Communication Running Software Definition of Done Simple Solution Automate (Test, Build, Release)
107. Kanban 107 Core Practices & Characteristics: §  Visualize the workflow §  Limit Work in Progress (WIP) §  Measure and Manage Flow §  Make Process Policies explicit §  Implement Feedback Loops §  Improve Collaboratively Evolve Experimentally
108. Agile Culture 108
109. Lean/Kanban Culture 109
110. Questions? 110 Alexander Müller, Senior IT Consultant codecentric AG Merscheider Straße 1 42699 Solingen, Deutschland e-mail: alexander.mueller@codecentric.de mobil: +49 (0) 172. 5252240 www.codecentric.de blog.codecentric.de speakerdeck.com/alexandermueller visusnet