Continuous Delivery Sounds Great but it Won't Work Here
44 likes9,983 views
The document discusses the concept of continuous delivery, emphasizing its importance for efficient software deployment and how it can be hindered by organizational challenges such as regulation, legacy systems, and cultural issues. It outlines key principles from historic software development practices and provides statistics demonstrating improvements in productivity and cost from adopting agile methodologies over time. The author argues that underlying cultural changes and systematic approaches are crucial for successful implementation of continuous delivery in an organization.
![Kaizen [improvement] opportunities
are infinite. Don’t think you have made
things better than before and be at
ease… This would be like the student
who becomes proud because they
bested their master two times out of
three in fencing. Once you pick up the
sprouts of kaizen ideas, it is important
to have the attitude in our daily work
that just underneath one kaizen idea is
yet another one.
—Taiichi Ohno](https://image.slidesharecdn.com/cdsoundsgreatwontwork-161007211740/85/Continuous-Delivery-Sounds-Great-but-it-Won-t-Work-Here-28-320.jpg)
Continuous Delivery Sounds Great but it Won't Work Here
- 1. @jezhumble #lascot16 continuous delivery sounds great but it won’t work here
- 2. @jezhumble what is continuous delivery? The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way.
- 3. @jezhumble design vs delivery Product Design and Development Product Delivery (build, testing, deployment) Create new products and services that solve customer problems using hypothesis-driven delivery, modern UX, design thinking. Enable fast flow from development to production and reliable releases by standardizing work, reducing variability and batch sizes. Feature design and implementation may require work that has never been performed before. Estimates are highly uncertain. Outcomes are highly variable. Integration, test and deployment must be performed continuously as quickly as possible. Cycle times should be well-known and predictable. Outcomes should have low variability. The DevOps Handbook; also https://conflatedautomatons.wordpress.com/2013/02/02/industrializing-the-noosphere/
- 5. @jezhumble unix? 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. 3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. 4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. Doug McIlroy, E. N. Pinson, B. A. Tague (8 July 1978). "Unix Time-Sharing System Forward". The Bell System Technical Journal. Bell Laboratories. pp. 1902–1903.
- 6. @jezhumble it won’t work here because… Stated reasons • We're regulated • We’re not building websites • Too much legacy • Our people are too stupid Actual reasons • Our culture sucks • Our architecture sucks
- 7. @jezhumble part the first “we’re regulated”
- 8. Jon Jenkins, “Velocity Culture, The Unmet Challenge in Ops” | http://bit.ly/1vJo1Ya
- 9. time to restore service lead time for changes release frequency change fail rate it performance http://bit.ly/2014-devops-report
- 12. @jezhumble part the second “we’re not building websites”
- 13. hp laserjet firmware 2008 ~5% - innovation capacity 15% - manual testing 25% - product support 25% - porting code 20% - detailed planning 10% - code integration Costs Full manual regression: 6 wks Builds / day: 1-2 Commit to trunk: 1 week Cycle times
- 14. implement continuous integration reduce hardware variation create a single package create a simulator implement comprehensive test automation futuresmart rearchitecture
- 16. hp laserjet firmware ~5% - innovation 15% - manual testing 25% - current product support 25% - porting code 20% - detailed planning 10% - code integration 2008 ~40% - innovation 5% - most testing automated 10% - current product support 15% - one main branch 5% - agile planning 2% - continuous integration 2011 The remaining 23% on RHS is spent on managing automated tests.
- 17. the economics 2008 to 2011 • overall development costs reduced by ~40% • programs under development increased by ~140% • development costs per program down 78% • resources now driving innovation increased by 8X A Practical Approach to Large-Scale Agile Development (Addison-Wesley) Gruver, Young, Fulghum
- 18. @jezhumble part the third “too much legacy”
- 22. Steve Yegge’s Platform Rant | http://bit.ly/1zxknpR
- 23. @jezhumble part the fourth “our people are too stupid”
- 25. changing culture http://www.thisamericanlife.org/radio-archives/episode/403/nummi http://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/ Schein, The Corporate Culture Survival Guide
- 26. TOYODA AUTOMATIC LOOM TYPE G 26 “Since the loom stopped when a problem arose, no defective products were produced. This meant that a single operator could be put in charge of numerous looms, resulting in a tremendous improvement in productivity.” http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html
- 28. Kaizen [improvement] opportunities are infinite. Don’t think you have made things better than before and be at ease… This would be like the student who becomes proud because they bested their master two times out of three in fencing. Once you pick up the sprouts of kaizen ideas, it is important to have the attitude in our daily work that just underneath one kaizen idea is yet another one. —Taiichi Ohno
- 29. Jesse Robbins, “Master of Disaster” @ Amazon| @jesserobbins “don’t fight stupid… make more awesome”
- 30. thank you! © 2016 DevOps Research and Assessment LLC https://devops-research.com/ To receive the following: • A copy of this presentation • A 100 page excerpt from Lean Enterprise • An excerpt from the DevOps Handbook • A 20m preview of my Continuous Delivery video workshop • Discount code for CD video + interviews with Eric Ries & more Just pick up your phone and send an email To: [email protected] Subject: devops continuo