Frequent Releases Reduce Risk

3,927 views
3,876 views

Published on

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

No Downloads
Views
Total views
3,927
On SlideShare
0
From Embeds
0
Number of Embeds
990
Actions
Shares
0
Downloads
31
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

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

×