Frequent Releases Reduce Risk
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Frequent Releases Reduce Risk

on

  • 5,282 views

 

Statistics

Views

Total Views
5,282
Views on SlideShare
4,346
Embed Views
936

Actions

Likes
5
Downloads
28
Comments
0

3 Embeds 936

http://exortech.com 931
http://theoldreader.com 3
http://www.slideshare.net 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Frequent Releases Reduce Risk Presentation Transcript

  • 1. Releasing Frequently Reduces Risk Owen Rogers Twitter: @exortech http://exortech.com/blog
  • 2. 1 year
  • 3. 48 releases
  • 4. ~ 1 release / week
  • 5. 10+/day
  • 6. 50+/day
  • 7. continuous deployment
  • 8. crazy
  • 9. sea change
  • 10. competitive advantage
  • 11. evolve software
  • 12. resolve problems
  • 13. faster than the competition
  • 14. capability
  • 15. respond to change
  • 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. proposition
  • 18. frequent releases increase risk
  • 19. frequent releases increase risk reduce
  • 20. 1) expose
  • 21. 2) mitigate
  • 22. ?
  • 23. can you deploy daily?
  • 24. “we can’t do that...” (3 minutes, 3 reasons)
  • 25. 3 common excuses
  • 26. 1. not enough time to test
  • 27. 1. not enough time to test 2. disruptive to users
  • 28. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 29. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 30. 1. not enough time to test
  • 31. 1. not enough time to test Risk: cost of bugs getting into production
  • 32. 1. not enough time to test Risk: cost of bugs getting into production Assumptions:
  • 33. 1. not enough time to test Risk: cost of bugs getting into production Assumptions: • we know what our customers want
  • 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. 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. 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. 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. 1. not enough time to test Assume: we know what our customers want testing: did we build it right?
  • 39. 1. not enough time to test Assume: we know what our customers want risk: did we build the right thing?
  • 40. 1. not enough time to test Assume: we know what our customers want $O
  • 41. 1. not enough time to test Assume: we know what our customers want $O (well, negative $ actually)
  • 42. 1. not enough time to test Assume: we know what our customers want
  • 43. 1. not enough time to test Assume: we know what our customers want • we understand our customer’s needs
  • 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. 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. 1. not enough time to test Assume: we know what our customers want validated learning about customers
  • 47. 1. not enough time to test Assume: we know what our customers want simplest solution to validate hypothesis
  • 48. 1. not enough time to test Assume: we know what our customers want split test
  • 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. 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. 1. not enough time to test Assumption: bugs are expensive $ million bug
  • 52. 1. not enough time to test Assumption: bugs are expensive = $10 billion
  • 53. 1. not enough time to test Assumption: bugs are expensive = 120M users/day
  • 54. 1. not enough time to test Assumption: bugs are expensive bugs are inevitable
  • 55. 1. not enough time to test Assumption: bugs are expensive speed of response
  • 56. 1. not enough time to test Assumption: bugs are expensive continuous monitoring
  • 57. 1. not enough time to test Assumption: bugs are expensive
  • 58. 1. not enough time to test Assumption: bugs are expensive
  • 59. 1. not enough time to test Assumption: bugs are expensive
  • 60. 1. not enough time to test Assumption: bugs are expensive
  • 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. 1. not enough time to test Assumption: testing takes a long time small changes
  • 63. 1. not enough time to test Assumption: testing takes a long time continuous integration
  • 64. 1. not enough time to test Assumption: testing takes a long time continuous testing
  • 65. 1. not enough time to test Assumption: testing takes a long time test automation
  • 66. 1. not enough time to test Assumption: testing takes a long time always releaseable
  • 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. 1. not enough time to test Assumption: all bugs can be found in test = 40,000 photos/sec
  • 69. 1. not enough time to test Assumption: all bugs can be found in test = 6 Pb of storage
  • 70. 1. not enough time to test Assumption: all bugs can be found in test
  • 71. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 72. 2. disruptive to users
  • 73. 2. disruptive to users Risk: new releases will annoy users
  • 74. 2. disruptive to users Risk: new releases will annoy users Assumptions:
  • 75. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime
  • 76. 2. disruptive to users Risk: new releases will annoy users Assumptions: • releases incur downtime • users will notice changes
  • 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. 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. 2. disruptive to users Assumption: releases incur downtime patch releases?
  • 80. 2. disruptive to users Assumption: releases incur downtime good will
  • 81. 2. disruptive to users Assumption: releases incur downtime zero-downtime deployment
  • 82. 2. disruptive to users Assumption: releases incur downtime redundancy
  • 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. 2. disruptive to users Assumption: users will notice changes
  • 85. 2. disruptive to users Assumption: users will notice changes
  • 86. 2. disruptive to users Assumption: users will notice changes version?
  • 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. 2. disruptive to users Assumption: changes are visible to all users big-bang release
  • 89. 2. disruptive to users Assumption: changes are visible to all users options
  • 90. 2. disruptive to users Assumption: changes are visible to all users
  • 91. 2. disruptive to users Assumption: changes are visible to all users Options:
  • 92. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta)
  • 93. 2. disruptive to users Assumption: changes are visible to all users Options: • release to user subset (private beta) • rollout to some servers
  • 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. 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. 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. 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. 2. disruptive to users Assumption: changes are visible to all users options = $$$
  • 99. 2. disruptive to users Assumption: changes are visible to all users “release is a marketing decision”
  • 100. 2. disruptive to users Assumption: changes are visible to all users bonus:
  • 101. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 102. 3. too much overhead
  • 103. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes
  • 104. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions:
  • 105. 3. too much overhead Risk: cost of a release is greater than the benefit of its changes Assumptions: • high coordination overhead
  • 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. 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. 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. 3. too much overhead Assumption: high coordination overhead functional silos
  • 110. 3. too much overhead Assumption: high coordination overhead dev vs. ops
  • 111. 3. too much overhead Assumption: high coordination overhead devs don’t know prod
  • 112. 3. too much overhead Assumption: high coordination overhead ops don’t know code
  • 113. 3. too much overhead Assumption: high coordination overhead shared accountability
  • 114. 3. too much overhead Assumption: high coordination overhead
  • 115. 3. too much overhead Assumption: high coordination overhead shared accountability
  • 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. 3. too much overhead Assumption: releases are risky “if it hurts, do it more often”
  • 118. 3. too much overhead Assumption: releases are risky incremental change
  • 119. 3. too much overhead Assumption: releases are risky more or less same system
  • 120. 3. too much overhead Assumption: releases are risky practice makes perfect
  • 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. 3. too much overhead Assumption: deployment takes a long time risk: manual steps
  • 123. 3. too much overhead Assumption: deployment takes a long time automated deployment
  • 124. 3. too much overhead Assumption: deployment takes a long time one-step process
  • 125. Summary
  • 126. Frequent Releases? ?
  • 127. concerns
  • 128. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 129. risks
  • 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. localized risk
  • 132. 1) expose
  • 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. 2) mitigate
  • 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. Thank You!
  • 137. Shameless Plug
  • 138. Nov 2 - 5 • Eric Evans • Michael Feathers • Martin Fowler • Jeff Patton • Mary Poppendieck • Michael Nygard • Linda Rising • Johanna Rothmann
  • 139. Releasing Frequently Reduces Risk Owen Rogers Twitter: @exortech http://exortech.com/blog
  • 140. 1. not enough time to test 2. disruptive to users 3. too much overhead
  • 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