continuous delivery sounds great

Transcription

1 continuous delivery sounds dev on summit march 30, Jez Humble

2 continuous delivery sounds great but it won t work dev on summit march 30, Jez Humble

3 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

4 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. Integration, test and deployment must be performed continuously as quickly as possible. Estimates are highly uncertain. Cycle times should be well-known and predictable. Outcomes are highly variable. Outcomes should have low variability. The DevOps Handbook; also

5 direct intellectual

6 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

7 it won t work here because Stated reasons We're regulated We re not building websites Too much legacy Our people are too

8 it won t work here because Stated reasons Actual reasons We're regulated Our culture sucks We re not building websites Our architecture sucks Too much legacy Our people are too

9 part the first we re

10 Jon Jenkins, Velocity Culture, The Unmet Challenge in Ops

11 it performance lead time for changes release frequency time to restore service change fail rate

12 deployment

13

14

15 Dev Ops

16 Dev Ops PaaS IaaS

17 compliance

18 part the second we re not building

19 hp laserjet firmware

20 hp laserjet firmware 2008

21 hp laserjet firmware 2008 Costs 10% - code integration 20% - detailed planning 25% - porting code 25% - product support 15% - manual testing ~5% - innovation capacity

22 hp laserjet firmware 2008 Costs Cycle times 10% - code integration Commit to trunk: 1 week 20% - detailed planning Builds / day: % - porting code Full manual regression: 6 wks 25% - product support 15% - manual testing ~5% - innovation capacity

23 futuresmart rearchitecture

24 reduce hardware variation futuresmart rearchitecture

25 futuresmart rearchitecture reduce hardware variation create a single package

26 futuresmart rearchitecture reduce hardware variation create a single package implement continuous integration

27 futuresmart rearchitecture reduce hardware variation create a single package implement continuous integration implement comprehensive test automation

28 futuresmart rearchitecture reduce hardware variation create a single package implement continuous integration implement comprehensive test automation create a simulator

29 deployment pipeline

30 hp laserjet firmware % - code integration 2% - continuous integration 20% - detailed planning 5% - agile planning 25% - porting code 15% - one main branch 25% - current product support 10% - current product support 15% - manual testing 5% - most testing automated ~5% - innovation ~40% - innovation

31 hp laserjet firmware % - code integration 2% - continuous integration 20% - detailed planning 5% - agile planning 25% - porting code 15% - one main branch 25% - current product support 10% - current product support 15% - manual testing 5% - most testing automated ~5% - innovation ~40% - innovation The remaining 23% on RHS is spent on managing automated tests.

32 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

33 part the third too much

34

35

36

37 strangler

38 Steve Yegge s Platform Rant

39 part the fourth our people are too

40 the production line

41 changing culture Schein, The Corporate Culture Survival Guide

42 changing culture Schein, The Corporate Culture Survival Guide

43 TOYODA AUTOMATIC LOOM TYPE G 30

44 TOYODA AUTOMATIC LOOM TYPE G 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. 30

45

46 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

47 don t fight stupid make more awesome Jesse Robbins, Master of

48 thank you! 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 To: jezhumble@sendyourslides.com Subject: devops continuo 2017 Jez Humble