0
Releasing Frequently
    Reduces Risk
         Owen Rogers
      Twitter: @exortech
   http://exortech.com/blog
1 year
48 releases
~ 1 release / week
10+/day
50+/day
continuous
deployment
crazy
sea change
competitive advantage
evolve software
resolve problems
faster than the
 competition
capability
respond to change
Agile Manifesto

▪
Individuals and interactions over processes and tools



▪
Working software over comprehensive document...
proposition
frequent releases
   increase risk
frequent releases
   increase risk
    reduce
1) expose
2) mitigate
?
can you deploy
    daily?
“we can’t do that...”

 (3 minutes, 3 reasons)
3 common excuses
1. not enough time to test
1. not enough time to test
2. disruptive to users
1. not enough time to test
2. disruptive to users
3. too much overhead
1. not enough time to test
2. disruptive to users
3. too much overhead
1. not enough time to test
1. not enough time to test
Risk: cost of bugs getting into production
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Assume: we know what our customers want


      testing: did we
       build it right?
1. not enough time to test
Assume: we know what our customers want


    risk: did we build
     the right thing?
1. not enough time to test
Assume: we know what our customers want


                 $O
1. not enough time to test
Assume: we know what our customers want


                 $O
     (well, negative $ actually)
1. not enough time to test
Assume: we know what our customers want
1. not enough time to test
Assume: we know what our customers want

  • we understand our customer’s needs
1. not enough time to test
Assume: we know what our customers want

  • we understand our customer’s needs
  • our custome...
1. not enough time to test
Assume: we know what our customers want

  • we understand our customer’s needs
  • our custome...
1. not enough time to test
Assume: we know what our customers want


   validated learning
    about customers
1. not enough time to test
Assume: we know what our customers want


    simplest solution
       to validate
       hypot...
1. not enough time to test
Assume: we know what our customers want



            split test
1. not enough time to test
Assume: we know what our customers want

   “deliver fast enough that the
   customer doesn’t h...
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Assumption: bugs are expensive



      $ million bug
1. not enough time to test
Assumption: bugs are expensive


          = $10 billion
1. not enough time to test
Assumption: bugs are expensive


          = 120M users/day
1. not enough time to test
Assumption: bugs are expensive



 bugs are inevitable
1. not enough time to test
Assumption: bugs are expensive



  speed of response
1. not enough time to test
Assumption: bugs are expensive



        continuous
        monitoring
1. not enough time to test
Assumption: bugs are expensive
1. not enough time to test
Assumption: bugs are expensive
1. not enough time to test
Assumption: bugs are expensive
1. not enough time to test
Assumption: bugs are expensive
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Assumption: testing takes a long time



      small changes
1. not enough time to test
Assumption: testing takes a long time



        continuous
        integration
1. not enough time to test
Assumption: testing takes a long time



        continuous
          testing
1. not enough time to test
Assumption: testing takes a long time




    test automation
1. not enough time to test
Assumption: testing takes a long time




 always releaseable
1. not enough time to test
Risk: cost of bugs getting into production

Assumptions:
 • we know what our customers want
 • ...
1. not enough time to test
Assumption: all bugs can be found in test



         = 40,000 photos/sec
1. not enough time to test
Assumption: all bugs can be found in test



          = 6 Pb of storage
1. not enough time to test
Assumption: all bugs can be found in test
1. not enough time to test
2. disruptive to users
3. too much overhead
2. disruptive to users
2. disruptive to users
Risk: new releases will annoy users
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
 • users will notice c...
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
 • users will notice c...
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
 • users will notice c...
2. disruptive to users
Assumption: releases incur downtime



    patch releases?
2. disruptive to users
Assumption: releases incur downtime




             good will
2. disruptive to users
Assumption: releases incur downtime



    zero-downtime
      deployment
2. disruptive to users
Assumption: releases incur downtime



       redundancy
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
 • users will notice c...
2. disruptive to users
Assumption: users will notice changes
2. disruptive to users
Assumption: users will notice changes
2. disruptive to users
Assumption: users will notice changes



           version?
2. disruptive to users
Risk: new releases will annoy users

Assumptions:
 • releases incur downtime
 • users will notice c...
2. disruptive to users
Assumption: changes are visible to all
users


   big-bang release
2. disruptive to users
Assumption: changes are visible to all
users


             options
2. disruptive to users
Assumption: changes are visible to all
users
2. disruptive to users
Assumption: changes are visible to all
users
Options:
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
  •...
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
  •...
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
  •...
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
  •...
2. disruptive to users
Assumption: changes are visible to all
users
Options:
  • release to user subset (private beta)
  •...
2. disruptive to users
Assumption: changes are visible to all
users


      options = $$$
2. disruptive to users
Assumption: changes are visible to all
users


   “release is a
marketing decision”
2. disruptive to users
Assumption: changes are visible to all
users

             bonus:
1. not enough time to test
2. disruptive to users
3. too much overhead
3. too much overhead
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Assumption: high coordination overhead



    functional silos
3. too much overhead
Assumption: high coordination overhead



        dev vs. ops
3. too much overhead
Assumption: high coordination overhead



   devs don’t know
         prod
3. too much overhead
Assumption: high coordination overhead



    ops don’t know
         code
3. too much overhead
Assumption: high coordination overhead



        shared
     accountability
3. too much overhead
Assumption: high coordination overhead
3. too much overhead
Assumption: high coordination overhead



        shared
     accountability
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Assumption: releases are risky



    “if it hurts, do it
       more often”
3. too much overhead
Assumption: releases are risky



        incremental
          change
3. too much overhead
Assumption: releases are risky



  more or less same
      system
3. too much overhead
Assumption: releases are risky



     practice makes
         perfect
3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes

Assumptions:
 • high coordination...
3. too much overhead
Assumption: deployment takes a long
time



 risk: manual steps
3. too much overhead
Assumption: deployment takes a long
time


       automated
       deployment
3. too much overhead
Assumption: deployment takes a long
time



   one-step process
Summary
Frequent Releases?



?
concerns
1. not enough time to test
2. disruptive to users
3. too much overhead
risks
1. bugs getting into production
2. new releases will annoy users
3. cost of a release is greater
than the benefit of its c...
localized risk
1) expose
underlying risks
Risks:
 • do we know what customers want?
 • can we respond fast enough to
  problems?
 • can we detect p...
2) mitigate
mitigation strategies
Strategies:
  • validated learning about customers
  • split testing
  • continuous monitoring
  • c...
Thank You!
Shameless Plug
Nov 2 - 5
•   Eric Evans

•   Michael Feathers

•   Martin Fowler

•   Jeff Patton

•   Mary Poppendieck

•   Michael Nyga...
Releasing Frequently
    Reduces Risk
         Owen Rogers
      Twitter: @exortech
   http://exortech.com/blog
1. not enough time to test
2. disruptive to users
3. too much overhead
1. bugs getting into production
2. new releases will annoy users
3. cost of a release is greater
than the benefit of its c...
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Frequent Releases Reduce Risk
Upcoming SlideShare
Loading in...5
×

Frequent Releases Reduce Risk

3,745

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,745
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
29
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Transcript of "Frequent Releases Reduce Risk"

  1. 1. Releasing Frequently Reduces Risk Owen Rogers Twitter: @exortech http://exortech.com/blog
  2. 2. 1 year
  3. 3. 48 releases
  4. 4. ~ 1 release / week
  5. 5. 10+/day
  6. 6. 50+/day
  7. 7. continuous deployment
  8. 8. crazy
  9. 9. sea change
  10. 10. competitive advantage
  11. 11. evolve software
  12. 12. resolve problems
  13. 13. faster than the competition
  14. 14. capability
  15. 15. respond to change
  16. 16. Agile Manifesto ▪ Individuals and interactions over processes and tools ▪ Working software over comprehensive documentation ▪ Customer collaboration over contract negotiation ▪ Responding to change over following a plan
  17. 17. proposition
  18. 18. frequent releases increase risk
  19. 19. frequent releases increase risk reduce
  20. 20. 1) expose
  21. 21. 2) mitigate
  22. 22. ?
  23. 23. can you deploy daily?
  24. 24. “we can’t do that...” (3 minutes, 3 reasons)
  25. 25. 3 common excuses
  26. 26. 1. not enough time to test
  27. 27. 1. not enough time to test 2. disruptive to users
  28. 28. 1. not enough time to test 2. disruptive to users 3. too much overhead
  29. 29. 1. not enough time to test 2. disruptive to users 3. too much overhead
  30. 30. 1. not enough time to test
  31. 31. 1. not enough time to test Risk: cost of bugs getting into production
  32. 32. 1. not enough time to test Risk: cost of bugs getting into production Assumptions:
  33. 33. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want
  34. 34. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive
  35. 35. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time
  36. 36. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time • all bugs can be found in test
  37. 37. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time • all bugs can be found in test
  38. 38. 1. not enough time to test Assume: we know what our customers want testing: did we build it right?
  39. 39. 1. not enough time to test Assume: we know what our customers want risk: did we build the right thing?
  40. 40. 1. not enough time to test Assume: we know what our customers want $O
  41. 41. 1. not enough time to test Assume: we know what our customers want $O (well, negative $ actually)
  42. 42. 1. not enough time to test Assume: we know what our customers want
  43. 43. 1. not enough time to test Assume: we know what our customers want • we understand our customer’s needs
  44. 44. 1. not enough time to test Assume: we know what our customers want • we understand our customer’s needs • our customers know what they want
  45. 45. 1. not enough time to test Assume: we know what our customers want • we understand our customer’s needs • our customers know what they want • our customers will still want what we have when we give to them
  46. 46. 1. not enough time to test Assume: we know what our customers want validated learning about customers
  47. 47. 1. not enough time to test Assume: we know what our customers want simplest solution to validate hypothesis
  48. 48. 1. not enough time to test Assume: we know what our customers want split test
  49. 49. 1. not enough time to test Assume: we know what our customers want “deliver fast enough that the customer doesn’t have time to change their mind”
  50. 50. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time • all bugs can be found in test
  51. 51. 1. not enough time to test Assumption: bugs are expensive $ million bug
  52. 52. 1. not enough time to test Assumption: bugs are expensive = $10 billion
  53. 53. 1. not enough time to test Assumption: bugs are expensive = 120M users/day
  54. 54. 1. not enough time to test Assumption: bugs are expensive bugs are inevitable
  55. 55. 1. not enough time to test Assumption: bugs are expensive speed of response
  56. 56. 1. not enough time to test Assumption: bugs are expensive continuous monitoring
  57. 57. 1. not enough time to test Assumption: bugs are expensive
  58. 58. 1. not enough time to test Assumption: bugs are expensive
  59. 59. 1. not enough time to test Assumption: bugs are expensive
  60. 60. 1. not enough time to test Assumption: bugs are expensive
  61. 61. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time • all bugs can be found in test
  62. 62. 1. not enough time to test Assumption: testing takes a long time small changes
  63. 63. 1. not enough time to test Assumption: testing takes a long time continuous integration
  64. 64. 1. not enough time to test Assumption: testing takes a long time continuous testing
  65. 65. 1. not enough time to test Assumption: testing takes a long time test automation
  66. 66. 1. not enough time to test Assumption: testing takes a long time always releaseable
  67. 67. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want • bugs are expensive • testing takes a long time • all bugs can be found in test
  68. 68. 1. not enough time to test Assumption: all bugs can be found in test = 40,000 photos/sec
  69. 69. 1. not enough time to test Assumption: all bugs can be found in test = 6 Pb of storage
  70. 70. 1. not enough time to test Assumption: all bugs can be found in test
  71. 71. 1. not enough time to test 2. disruptive to users 3. too much overhead
  72. 72. 2. disruptive to users
  73. 73. 2. disruptive to users Risk: new releases will annoy users
  74. 74. 2. disruptive to users Risk: new releases will annoy users Assumptions:
  75. 75. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime
  76. 76. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes
  77. 77. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes • changes are visible to all users
  78. 78. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes • changes are visible to all users
  79. 79. 2. disruptive to users Assumption: releases incur downtime patch releases?
  80. 80. 2. disruptive to users Assumption: releases incur downtime good will
  81. 81. 2. disruptive to users Assumption: releases incur downtime zero-downtime deployment
  82. 82. 2. disruptive to users Assumption: releases incur downtime redundancy
  83. 83. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes • changes are visible to all users
  84. 84. 2. disruptive to users Assumption: users will notice changes
  85. 85. 2. disruptive to users Assumption: users will notice changes
  86. 86. 2. disruptive to users Assumption: users will notice changes version?
  87. 87. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes • changes are visible to all users
  88. 88. 2. disruptive to users Assumption: changes are visible to all users big-bang release
  89. 89. 2. disruptive to users Assumption: changes are visible to all users options
  90. 90. 2. disruptive to users Assumption: changes are visible to all users
  91. 91. 2. disruptive to users Assumption: changes are visible to all users Options:
  92. 92. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta)
  93. 93. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers
  94. 94. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers • downgrade feature
  95. 95. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers • downgrade feature • disable feature (feature darkmode)
  96. 96. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers • downgrade feature • disable feature (feature darkmode) • defer commit
  97. 97. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers • downgrade feature • disable feature (feature darkmode) • defer commit • defer release
  98. 98. 2. disruptive to users Assumption: changes are visible to all users options = $$$
  99. 99. 2. disruptive to users Assumption: changes are visible to all users “release is a marketing decision”
  100. 100. 2. disruptive to users Assumption: changes are visible to all users bonus:
  101. 101. 1. not enough time to test 2. disruptive to users 3. too much overhead
  102. 102. 3. too much overhead
  103. 103. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes
  104. 104. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions:
  105. 105. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead
  106. 106. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead • releases are risky
  107. 107. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead • releases are risky • deployment takes a long time
  108. 108. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead • releases are risky • deployment takes a long time
  109. 109. 3. too much overhead Assumption: high coordination overhead functional silos
  110. 110. 3. too much overhead Assumption: high coordination overhead dev vs. ops
  111. 111. 3. too much overhead Assumption: high coordination overhead devs don’t know prod
  112. 112. 3. too much overhead Assumption: high coordination overhead ops don’t know code
  113. 113. 3. too much overhead Assumption: high coordination overhead shared accountability
  114. 114. 3. too much overhead Assumption: high coordination overhead
  115. 115. 3. too much overhead Assumption: high coordination overhead shared accountability
  116. 116. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead • releases are risky • deployment takes a long time
  117. 117. 3. too much overhead Assumption: releases are risky “if it hurts, do it more often”
  118. 118. 3. too much overhead Assumption: releases are risky incremental change
  119. 119. 3. too much overhead Assumption: releases are risky more or less same system
  120. 120. 3. too much overhead Assumption: releases are risky practice makes perfect
  121. 121. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead • releases are risky • deployment takes a long time
  122. 122. 3. too much overhead Assumption: deployment takes a long time risk: manual steps
  123. 123. 3. too much overhead Assumption: deployment takes a long time automated deployment
  124. 124. 3. too much overhead Assumption: deployment takes a long time one-step process
  125. 125. Summary
  126. 126. Frequent Releases? ?
  127. 127. concerns
  128. 128. 1. not enough time to test 2. disruptive to users 3. too much overhead
  129. 129. risks
  130. 130. 1. bugs getting into production 2. new releases will annoy users 3. cost of a release is greater than the benefit of its changes
  131. 131. localized risk
  132. 132. 1) expose
  133. 133. underlying risks Risks: • do we know what customers want? • can we respond fast enough to problems? • can we detect problems when they happen? • can we limit the impact of changes? • can we deploy without downtime? • can we build production-ready software?
  134. 134. 2) mitigate
  135. 135. mitigation strategies Strategies: • validated learning about customers • split testing • continuous monitoring • continuous integration • test automation • zero-down time deployment • deployment options • operation levers • automated deployment
  136. 136. Thank You!
  137. 137. Shameless Plug
  138. 138. Nov 2 - 5 • Eric Evans • Michael Feathers • Martin Fowler • Jeff Patton • Mary Poppendieck • Michael Nygard • Linda Rising • Johanna Rothmann
  139. 139. Releasing Frequently Reduces Risk Owen Rogers Twitter: @exortech http://exortech.com/blog
  140. 140. 1. not enough time to test 2. disruptive to users 3. too much overhead
  141. 141. 1. bugs getting into production 2. new releases will annoy users 3. cost of a release is greater than the benefit of its changes
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×