ATBru 2015 - Facts and Fallacies of Continuous Delivery

This is my presentation about Continuous Delivery at Agile Tour Brussels 2015.

Continuous Delivery brings a lot of value to your organisation. It will allow you to reduce your time to market for new features and bug fixes. It is a significant predictor of company performance.

Continuous Delivery is more than just tooling. It is also a mindset.

During this session we will not talk about how to implement Continuous Delivery. Although you will get a short introduction to it. The session will be more about the mindset you need to have in order to successfully implement Continuous Delivery. And it'll highlight some facts … And a fallacy (or two) that exist in the minds of decision makers preventing them to take the leap forward.

Transcript

1. Facts and Fallacies of Continuous Delivery Agile Tour Brussels 2015 Thierry de Pauw, @tdpauw
2. What is Continuous Delivery
3. "How long would it take your organisation to deploy a change that involves just one single line of code ? Do you do this on a repeatable, reliable basis ?" Mary and Tom Poppendieck, Implementing Lean Software Development
4. Satisfy your customer through early and continuous delivery of valuable software
5. A Deployment Pipeline is the automated implementation of your process of getting software from version control into the hands of your users.
6. It is a logical extension of Continuous Integration Every commit creates a potential release candidate
7. One of its key objectives is to optimise for human resource usage
8. The deployment pipeline has 3 purposes: •every part of the process is visible •it improves feedback •it empowers teams
9. The deployment pipeline is part of your value stream, the process of getting a feature from the mind of your customers into their hands
10. The entire process, from concept to cash, can be modelled as a value stream map
11. Fact 1 More than just Tooling
12. Continuous Delivery is a mindset
13. It is about the DevOps Culture and Lean Software Development
14. The DevOps Culture : The Three Ways
15. The First Way: from Left to Right Maximise the flow from Development to Operations to Customers
16. Definition of Done is not when Development is done coding
17. The aim is single piece flow
18. The Second Way: from Right to Left Constant flow of fast feedback at all stages of the value stream
19. To get early feedback, you can't have 1 year releases
20. The Third Way: a Culture of Improvement A culture that fosters continual experimentation, learning from failures and understanding that repetition and practice leads to mastery.
21. "If a system is not improving, the result is not steady state. Instead, because of entropy, organisational performance declines" Mike Rother, Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
22. The Three Ways are essential to successfully apply Continuous Delivery
23. Fact 2 Build your binaries once and only once
24. 1. Keep the deployment pipeline efficient
25. 2. Always build upon foundations known to be right
26. It must be possible to deploy the binaries to every environment
27. Fact 3 Keep everything under Version Control
28. A new team member must be able to checkout the project from version control, and run a single command to build and deploy the application on the local workstation
29. Fact 4 When continuously integrating, integrate also your internal dependencies
30. Always use the latest stable version of your internal dependencies.
31. Fact 5 Feature branches are evil
32. They introduce risk
33. They are time consuming
34. Refactoring becomes difficult
35. They increase the complexity of the internal dependency management
36. Break down your stories into smaller chunks of work
37. Implement the user-facing bits last
38. Use Branch by Abstraction
39. Use Feature Toggles
40. Fact 6 Automate the hell out of it
41. "If the build, deploy, test, and release process is not automated, it is not repeatable" Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
42. Some things are impossible to automate
43. But the list of things that cannot be automated is much smaller than many people think
44. Test Automation
45. Human beings are simply bad at repetitive, complex tasks that manual regression testing requires
46. Database creation, database schema upgrades (or downgrades) Network and firewall configuration
47. Application Automation
48. Fact 7 It doesn't come over one night
49. To identify your bottleneck You need to model your value stream using a value stream map
50. Any improvements made anywhere besides the bottleneck are an illusion
51. Fact 8 Build Quality In !
52. "Your goal is to build quality into the code from the start, not test it in later" Mary and Tom Poppendieck, Implementing Lean Software Development
53. When a defect is found, stop the line
54. "Defect tracking systems are queues of partially done work" Mary and Tom Poppendieck, Implementing Lean Software Development
55. "(Technical Debt) comes from taking shortcuts, which may make sense in the short-term. But like financial debt, the compounding interest costs grow over time. If an organisation doesn't pay down its technical debt, every calorie in the organisation can be spent just paying interest, in the form of unplanned work." The Phoenix Project
56. "Delaying testing until after the development process is a sure-fire way to decrease the quality of your application." Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
57. Test automation makes the quality of your application significantly higher, so manual testing is then only an affirmation of the functional completeness
58. Fact 9 Deployments become Boring
59. Anti-pattern: Big feature releases as answer for failing deployments
60. "If it hurts, do it more often !"
61. Deploy the same way to each environment
62. You have to have a Copy of Production
63. First Fallacy Deployments cost too much
64. The indirect cost of the downtime during releases
65. Systems that only operate during "business hours" are rare
66. SLA 99,5% availability means less than 216 minutes of unplanned downtime per month
67. 216 min/month vs 5 hours of planned downtime
68. Users do not care if the downtime was planned or unplanned
69. Blue Green Deployments
70. Zero-Down Time Deployments •Expansion (days before) : add stuff •Roll out •Clean up (days after) : remove stuff
71. Fact 10 Rollbacks become obsolete
72. Fix Forward
73. Fact 11 You will not risk customers for an arbitrary release date
74. For product vendors release dates matter For the other 99,9%: nobody cares
75. Customers care that the system is available and works without too many bugs
76. Do not try to rush releases into production before being ready
77. Fact 12 You build it you run it
78. Everybody in your team (by extension your organisation) is responsible for the release process
79. "An organisation that respects software developers as professionals will expect them to design their own jobs [...]. It will expect them to improve continually the way they do their work as part of a learning process. Finally, it will give them the time and equipment necessary to do their jobs well. [...] Frontline workers have process design authority and decision-making responsibility." Mary and Tom Poppendieck, Lean Software Development
80. Second Fallacy That does not work here syndrome
81. Continuous Delivery is all about managing risk
82. The system prevents you to deploy a build into production that is not thoroughly tested and found to be fit
83. Heavy change management processes bring nothing to the stability of systems
84. Everything that improves throughput improves stability Everything that improves innovation also improves stability
85. Third Fallacy But we are not Unicorns !
86. "Of the Fortune 500 companies in 1955, 87% are gone. In 1958, the Fortune 500 tenure was 61 years; now it's only 18 years" Richard Foster, Creative Destruction: Why Companies that are built to Last underperform the Market - and how to Successfully transform Them, 2001
87. One of the primary objections from horses is that all unicorns were born that way
88. All unicorns were once horses
89. LinkedIn 2011: 2 months feature freeze
90. Etsy 2009: "had to come to grips that they were living in a sea of their own engineering filth"
91. Facebook 2009: barely able to keep up with user growth, code deployments were becoming increasingly dangerous
92. •BNY Mellon, Bank of America, ING Netherlands •Target •UK.gov
93. Resources
94. Hello, I am Thierry de Pauw Software Engineer, Jack of All Trades Agile Technical Coach http://thinkinglabs.io @tdpauw