The Rationale For Continuous Delivery Or What Does Good Look Like? - - PowerPoint PPT Presentation

the rationale for continuous delivery
SMART_READER_LITE
LIVE PREVIEW

The Rationale For Continuous Delivery Or What Does Good Look Like? - - PowerPoint PPT Presentation

The Rationale For Continuous Delivery Or What Does Good Look Like? Dave Farley http://www.davefarley.net @davefarley77 http://www.continuous-delivery.co.uk The State of Software Development The State of Software Development Source:


slide-1
SLIDE 1

Dave Farley

http://www.davefarley.net @davefarley77

http://www.continuous-delivery.co.uk

The Rationale For Continuous Delivery

Or What Does ‘Good’ Look Like?

slide-2
SLIDE 2

The State of Software Development

slide-3
SLIDE 3

The State of Software Development

Source: KPMG (New Zealand) Date: 2010 In a study of project management practices: 1) 70% of organizations have suffered at least one project failure in the last 12 months 2) 50% of respondents indicated that their projects consistently failed to achieve what they set out to achieve.
slide-4
SLIDE 4

The State of Software Development

Source: KPMG (New Zealand) Date: 2010 In a study of project management practices: 1) 70% of organizations have suffered at least one project failure in the last 12 months 2) 50% of respondents indicated that their projects consistently failed to achieve what they set out to achieve. Source: KPMG – Global IT Management Survey Date: 2005 In a survey of 600 projects worldwide: 1) 49% of organisations had suffered a project failure in the past 12 months 2) 2% of organisations reported that all of their projects achieved their desired benefits.
slide-5
SLIDE 5

The State of Software Development

Source: KPMG (New Zealand) Date: 2010 In a study of project management practices: 1) 70% of organizations have suffered at least one project failure in the last 12 months 2) 50% of respondents indicated that their projects consistently failed to achieve what they set out to achieve. Source: KPMG – Global IT Management Survey Date: 2005 In a survey of 600 projects worldwide: 1) 49% of organisations had suffered a project failure in the past 12 months 2) 2% of organisations reported that all of their projects achieved their desired benefits. Source: Logica Management Consulting Date: 2008 In a survey of 380 senior execs in Western Europe: 1) 35% of organisations abandoned a major project in the last 3years 2) 37% of business change programmes fail to deliver benefits.
slide-6
SLIDE 6

The State of Software Development

Source: KPMG (New Zealand) Date: 2010 In a study of project management practices: 1) 70% of organizations have suffered at least one project failure in the last 12 months 2) 50% of respondents indicated that their projects consistently failed to achieve what they set out to achieve. Source: KPMG – Global IT Management Survey Date: 2005 In a survey of 600 projects worldwide: 1) 49% of organisations had suffered a project failure in the past 12 months 2) 2% of organisations reported that all of their projects achieved their desired benefits. Source: Logica Management Consulting Date: 2008 In a survey of 380 senior execs in Western Europe: 1) 35% of organisations abandoned a major project in the last 3years 2) 37% of business change programmes fail to deliver benefits. Source: The McKinsey Group with Oxford University Date: 2012 In a study of 5,400 large scale projects (> $15m): 1) 17% of projects go so badly that they threaten the existence of the company performing them. 2) On average large projects run 45% over budget and 7% over time while delivering 56% less value than predicted.
slide-7
SLIDE 7

The State of Software Development Has Been Err…. Sub-Optimal

slide-8
SLIDE 8

The State of Software Development Has Been Err…. Sub-Optimal

slide-9
SLIDE 9

The State of Software Development Has Been Err…. Sub-Optimal

But there are signs of change…

slide-10
SLIDE 10

What Have We Tried?

slide-11
SLIDE 11

What Have We Tried?

slide-12
SLIDE 12

What Have We Tried?

slide-13
SLIDE 13

What Have We Tried?

slide-14
SLIDE 14

What Have We Tried?

slide-15
SLIDE 15

What Have We Tried?

slide-16
SLIDE 16

What Have We Tried?

slide-17
SLIDE 17

What Have We Tried?

slide-18
SLIDE 18

What Have We Tried?

slide-19
SLIDE 19

What Have We Tried?

slide-20
SLIDE 20

What Have We Tried?

slide-21
SLIDE 21

Learning From Our Mistakes

slide-22
SLIDE 22

Learning From Our Mistakes

“Insanity is doing the same thing over and

  • ver again and

expecting different results.”

Albert Einstein

slide-23
SLIDE 23

What Do We Really Want?

Customer Feedback Business Idea

slide-24
SLIDE 24

What Do We Really Want?

Customer Feedback Business Idea

Quickly Cheaply Reliably

slide-25
SLIDE 25

A Question….

slide-26
SLIDE 26

A Question….

What is the most successful invention in human history?

slide-27
SLIDE 27

A Question….

SCIENCE

slide-28
SLIDE 28

The Scientific Method

Characterisation Make a guess based on experience and observation. Hypothesis Propose an explanation. Deduction Make a prediction from the hypothesis. Experiment Test the prediction.

Repeat!

slide-29
SLIDE 29

What Works?

57% 14% 29%

Challenged Successful Failed

49% 42% 9%

Source: The CHAOS Manifesto, The Standish Group 2012

Agile Waterfall

slide-30
SLIDE 30

What Works? - More Data

30% 64% 6% 21% 72% 7% 28% 65% 7% 35% 50% 15% 32% 49% 18%

Source: Scott Ambler, Dr. Dobbs Journal, Feb 2014 (http://www.drdobbs.com/architecture-and-design/the-non-existent-software-crisis-debunki/240165910)

Agile Lean Iterative Ad-Hoc Traditional

slide-31
SLIDE 31

What Works? - More Data

30% 64% 6% 21% 72% 7% 28% 65% 7% 35% 50% 15% 32% 49% 18%

Source: Scott Ambler, Dr. Dobbs Journal, Feb 2014 (http://www.drdobbs.com/architecture-and-design/the-non-existent-software-crisis-debunki/240165910)

Agile Lean Iterative Ad-Hoc Traditional

Lean Thinking …

  • Deliver Fast
  • Build Quality In
  • Optimise the Whole
  • Eliminate Waste
  • Unnecessary Variations (Mura)
  • Overburden (Muri)
  • Wasteful activities (Muda)
  • Amplify Learning
  • Decide Late
  • Empower the Team
slide-32
SLIDE 32

Smart Automation - a repeatable, reliable process for releasing software

Unit Test Code Idea Executable spec. Build Release

What Really Works?

slide-33
SLIDE 33

Smart Automation - a repeatable, reliable process for releasing software

Unit Test Code Idea Executable spec. Build Release

What Really Works?

slide-34
SLIDE 34

Smart Automation - a repeatable, reliable process for releasing software

Unit Test Code Idea Executable spec. Build Release

“It doesn’t matter how intelligent you are, if you guess and that guess cannot be backed up by experimental evidence – then it is still a guess!”

  • Richard Feynman

What Really Works?

slide-35
SLIDE 35

Cycle-Time

103 days

Typical Traditional Cycle Time

10 days 64 days
slide-36
SLIDE 36

Cycle-Time

Commit Stage Compile Unit test Analysis Build Installers Automated acceptance testing Automated performance testing Manual testing Release 57 mins 3 mins 20 mins 20 mins 30 mins 4 mins

Typical CD Cycle Time

103 days

Typical Traditional Cycle Time

10 days 64 days
slide-37
SLIDE 37

What Is Continuous Delivery?

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The first principle of the agile manifesto. The logical extension of continuous integration. A holistic approach to development. Every commit creates a release candidate. Finished means released into production!

slide-38
SLIDE 38

The Principles of Continuous Delivery

Create a repeatable, reliable process for releasing software. Automate almost everything. Keep everything under version control. If it hurts, do it more often – bring the pain forward. Build quality in. Done means released. Everybody is responsible for the release process. Improve continuously.

slide-39
SLIDE 39

The Principles of Continuous Delivery

Create a repeatable, reliable process for releasing software. Automate almost everything. Keep everything under version control. If it hurts, do it more often – bring the pain forward. Build quality in. Done means released. Everybody is responsible for the release process. Improve continuously.

“If Agile software development was the opening act to a great performance, Continuous Delivery is the headliner.”

Forrester Research 2013

slide-40
SLIDE 40

What Does This Look Like?

slide-41
SLIDE 41

Example Continuous Delivery Process

Local Dev. Env. Source Repository
slide-42
SLIDE 42

Example Continuous Delivery Process

Local Dev. Env. Source Repository
slide-43
SLIDE 43

Example Continuous Delivery Process

Local Dev. Env. Commit Source Repository
slide-44
SLIDE 44

Example Continuous Delivery Process

Local Dev. Env. Commit Source Repository
slide-45
SLIDE 45

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Commit Source Repository
slide-46
SLIDE 46

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Commit Commit Source Repository
slide-47
SLIDE 47

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Source Repository
slide-48
SLIDE 48

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Source Repository
slide-49
SLIDE 49

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Acceptance Source Repository
slide-50
SLIDE 50

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Acceptance Source Repository Manual Test Env. Deployment App.
slide-51
SLIDE 51

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Acceptance Source Repository Manual Test Env. Deployment App.
slide-52
SLIDE 52

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Commit Acceptance Manual Source Repository Manual Test Env. Deployment App.
slide-53
SLIDE 53

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance Commit Acceptance Manual Source Repository Manual Test Env. Deployment App.
slide-54
SLIDE 54

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance Commit Acceptance Manual Source Repository Manual Test Env. Deployment App.
slide-55
SLIDE 55

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance Commit Acceptance Manual Perf1 Source Repository Manual Test Env. Deployment App.
slide-56
SLIDE 56

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Source Repository Manual Test Env. Deployment App.
slide-57
SLIDE 57

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Source Repository Manual Test Env. Deployment App.
slide-58
SLIDE 58

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Perf2 Source Repository Manual Test Env. Deployment App.
slide-59
SLIDE 59

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Perf2 Source Repository Manual Test Env. Deployment App. Data Migration
slide-60
SLIDE 60

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Perf2 Source Repository Manual Test Env. Deployment App. Data Migration
slide-61
SLIDE 61

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Commit Acceptance Manual Perf1 Perf2 Staged Source Repository Manual Test Env. Deployment App. Data Migration
slide-62
SLIDE 62

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Source Repository Manual Test Env. Deployment App. Data Migration
slide-63
SLIDE 63

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Source Repository Manual Test Env. Deployment App. Data Migration
slide-64
SLIDE 64

Example Continuous Delivery Process

Artifact Repository Local Dev. Env. Acceptance Commit Component Performance System Performance Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Production Source Repository Manual Test Env. Deployment App. Data Migration
slide-65
SLIDE 65

Example Continuous Delivery Process

Artifact Repository Local Dev. Env.

Deployment Pipeline

Acceptance Commit Component Performance System Performance Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Production Source Repository Manual Test Env. Deployment App. Data Migration
slide-66
SLIDE 66

“This may work for small projects but can’t possibly scale”

slide-67
SLIDE 67

“This may work for small projects but can’t possibly scale”

The Google Build Process

  • Single Monolithic Repository
  • Continuous Build & Test on Commit For:
  • > 60 Million builds per year and growing exponentially.
  • > 100 Million lines of code.
  • All tests are run on every commit, (>20 commits per

minute).

  • > 100 Million test cases executed per day.
slide-68
SLIDE 68

“This is too risky, releasing all the time is a recipe for disaster”

slide-69
SLIDE 69

“This is too risky, releasing all the time is a recipe for disaster”

The Amazon Build Process

  • Mean time between deployment - 11.6 seconds
  • Mean hosts simultaneously receiving a deployment - 10,000
  • 75% reduction in outages triggered by deployment between

2006 and 2011

  • 90% reduction in outage minutes triggered by deployment
  • ~0.001% of deployments cause an outage
  • Instantaneous rollback
  • Reduction in complexity
slide-70
SLIDE 70

“This may work for simple web sites but my technology is too complex”

slide-71
SLIDE 71

“This may work for simple web sites but my technology is too complex”

  • Transformation of Development Approach for all LaserJet

Firmware Products

  • Large Complex Project
  • Multiple Products
  • Four Year Timeframe
  • 10x Developer Productivity Increase

HP Laserjet Firmware Team Experience

slide-72
SLIDE 72

HP LaserJet Firmware Team

10% Code Integration 20% Detailed Planning 25% Porting Code 25% Product Support 15% Manual Testing ~5% Innovation 2% Continuous Integration 5% Agile Planning 15% Architectural Integrity 10% Unified Support 5% Automated Testing 3% Improving Tools 10% Writing Tests ~40% Innovation

2008 2011

slide-73
SLIDE 73

The Results

A Practical Approach to Large scale Agile Development (Gruver, Young and Fulgrhum)
  • Overall development costs reduced by ~40%
  • Programs under development increased by ~140%
  • Development cost per program down by 70%
  • Resources now driving innovation increased by 5x
slide-74
SLIDE 74

The Effect on Business - Part 1

  • Continuous Delivery changes the economics of software delivery.
  • 87% of companies who’s development & operations functions

were rated as “excellent” saw revenue growth > 10% in 20131

  • In contrast, 13% of companies who’s development & operations

functions were rated “average” or worse saw similar growth.

  • 8x more frequent production deployments
  • 8000x faster deployment lead times (i.e., time required from

“code committed” to “successfully running in production”)

  • 50% lower change failure rates
Source: 1"DevOps and Continuous Delivery: Ten Factors Shaping the Future of Application Delivery.”, Enterprise Management Associates’ Report (2014)
slide-75
SLIDE 75

The Effect on Business - Part 2

  • Higher throughput2
  • Higher reliability2
  • 12x faster service restoration times when something went

wrong (i.e., MTTR)

  • “Organizational culture is one of the strongest predictors of

both IT performance and overall performance of the

  • rganization”2
  • “We can now assert with confidence that high IT

performance correlates with strong business performance, helping to boost productivity, profitability and market share.”2

Source: 2“2014 State of DevOps report”, Jez Humble, Gene Kim, Nicole Forsgren Velasquez, Puppet Labs (2014)
slide-76
SLIDE 76

Who Practices CD?

slide-77
SLIDE 77

Who Practices CD?

slide-78
SLIDE 78

Q&A

http://www.continuous-delivery.co.uk

Dave Farley http://www.davefarley.net @davefarley77