Continuous Delivery

1,606 views

Published on

from JavaDays Riga '12

Published in: Technology
  • Be the first to comment

Continuous Delivery

  1. 1. Andrzej Grzesik
  2. 2. CONTINOUS DELIVERY Andrzej Grzesik
  3. 3. @ags313andrzej@grzesik.itandrzejgrzesik.info
  4. 4. ABOUT:MEPresentPast
  5. 5. GEECON 2013 I HATE COMPUTERS disclaimer 17th-19th May, Krakow, Poland
  6. 6. I HATE COMPUTERS disclaimer
  7. 7. QUESTIONS? ask them right away!
  8. 8. GREAT BOOKS!
  9. 9. FACTS FIRST
  10. 10. is more fun than
  11. 11. Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.
  12. 12. Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.
  13. 13. DELIVERY
  14. 14. DELIVERED when?
  15. 15. DEPENDS…(ultimate answer in computers)
  16. 16. #DEFINE DONE
  17. 17. WHAT IS DONE?
  18. 18. WHAT IS DONE?
  19. 19. WHAT IS DONE?Coded
  20. 20. WHAT IS DONE?Coded Reviewed
  21. 21. WHAT IS DONE?Coded Reviewed Checked-in
  22. 22. WHAT IS DONE?Coded Reviewed Checked-in Built
  23. 23. WHAT IS DONE?Coded Reviewed Checked-in Built Tested
  24. 24. WHAT IS DONE?Coded Reviewed Checked-in Built Tested Demoed
  25. 25. NOT REALLY :-)
  26. 26. #REDEFINE DONE
  27. 27. NOT READYTILL DEPLOYED
  28. 28. DONE === RELEASED
  29. 29. ERIC RIES, THE LEAN STARTUP build&ideas& deploy&learn& measure& data&
  30. 30. If we canreduce the time between major iterations we can increase our odds of success Eric Ries, Lean Startup
  31. 31. RELEASES give us
  32. 32. FEEDBACK!
  33. 33. How long would it take your organization to deploy achange that involved just one single line of code?Do you do this on a repeatable, reliable basis? Mary and Tom Poppendieck, Implementing Lean Software Development
  34. 34. RELEASE == FEEDBACK
  35. 35. REPEATABLE FEEDBACK
  36. 36. HOW?!
  37. 37. entreth:THE DEPLOYMENT PIPELINE
  38. 38. THE DEPLOYMENT PIPELINE
  39. 39. THE DEPLOYMENT PIPELINEcompile
  40. 40. THE DEPLOYMENT PIPELINEcompileunit test
  41. 41. THE DEPLOYMENT PIPELINEcompileunit testpackage
  42. 42. THE DEPLOYMENT PIPELINEcompileunit testpackage artifact repository
  43. 43. THE DEPLOYMENT PIPELINEcompile Acceptanceunit test testingpackage artifact repository
  44. 44. THE DEPLOYMENT PIPELINEcompile Acceptance Capacityunit test testing testingpackage artifact repository
  45. 45. THE DEPLOYMENT PIPELINEcompile Acceptance Capacity Manualunit test testing testing testingpackage artifact repository
  46. 46. THE DEPLOYMENT PIPELINEcompile Acceptance Capacity Manualunit test Release testing testing testingpackage artifact repository
  47. 47. BUILD ONLY ONCE!
  48. 48. THE DEPLOYMENT PIPELINE
  49. 49. THE DEPLOYMENT PIPELINEcompile Acceptance Capacityunit test testing testingpackage artifact repository
  50. 50. THE DEPLOYMENT PIPELINEcompile Acceptance Capacity Manualunit test testing testing testingpackage artifact repository
  51. 51. THE DEPLOYMENT PIPELINEcompile Acceptance Capacity Manualunit test Release testing testing testingpackage artifact repository
  52. 52. THE DEPLOYMENT PIPELINE
  53. 53. THE DEPLOYMENT PIPELINE Acceptance Capacity testing testing
  54. 54. THE DEPLOYMENT PIPELINE Acceptance Capacity Manual testing testing testing
  55. 55. THE DEPLOYMENT PIPELINE Acceptance Capacity Manual Release testing testing testing
  56. 56. THE DEPLOYMENT PIPELINE fear!compile Acceptance Capacity Manualunit test Release testing testing testingpackage artifact repository
  57. 57. AUTOMATE EVERYTHING! (almost)
  58. 58. AUTOMATE EVERYTHING!
  59. 59. AND?
  60. 60. WELL, IT’S BIG
  61. 61. ALL CODEIS PRODUCTION READY
  62. 62. EVERY VERSION ISA RELEASE CANDIDATE
  63. 63. QUALITY GOES UP people care
  64. 64. idea from: paulklipp.com/blog
  65. 65. PRO TIP: --VERSION
  66. 66. WHY VERSIONS?
  67. 67. 185.0.1 is more friendly than0cdfc45df874354265b3be910b52c41398de79ca
  68. 68. ANTIPATTERNS
  69. 69. DEPLOYING RARELY/LATE symptomps: “alpha”, “beta”, “gold”
  70. 70. LATE FIRST CONTACT WITH REALITY
  71. 71. UNREALISTIC ASSUMPTIONS
  72. 72. WELL TESTED IN.. DEV
  73. 73. DEPLOYING MANUALLY is evil!
  74. 74. ERROR-PRONE http://www.flickr.com/photos/aaronjacobs/64368770/
  75. 75. ALWAYS DIFFERENT repeatable
  76. 76. IMPOSSIBLE TO TEST
  77. 77. VOODOOhttp://flickr.com/photos/35541100@N00/2486381001/
  78. 78. 2 AM DEPLOYShttp://www.flickr.com/photos/dhdesign/1096464615/sizes/z/in/photostream/
  79. 79. THE “DEPLOY” TEAM
  80. 80. DO YOU AVOID DEPLOYS?
  81. 81. HOW OFTEN DO YOU DEPLOY?
  82. 82. IF IT HURTSDO IT MORE OFTEN! practice, practice, practice
  83. 83. INCREMENTAL, FREQUENT RELEASES REDUCE RISK
  84. 84. PROVIDE DATA
  85. 85. GIVE ROLLBACK POINTS
  86. 86. SOME STATSFacebook - every 10 minutesEtsy - 50-60 deploys/dayGitHub - >50 deploys/dayproject X - 1374 commits, 1057 deployments, <8 months
  87. 87. ENVIRONMENTS
  88. 88. IF I ERASED ALL YOUR PRODUCTIONMACHINES, HOW LONG WOULD YOU NEED TO BE BACK UP?
  89. 89. WELL, CODE IS IN GITmercurial, subversion, ClearCase, whathaveyou
  90. 90. IMAGINE:http://www.flickr.com/photos/roadhunter/68017745/
  91. 91. INFRASTRUCTURE AND CONFIGURATION IS JUST AS IMPORTANT
  92. 92. VERSION IT! (puppet, chef, etc)
  93. 93. BEFRIEND SOME ADMINS :-)
  94. 94. AND VERSION EVERYTHING
  95. 95. MANUAL CONFIGURATION OF ENVIRONMENTS
  96. 96. PRIVILEGED DEPLOY TEAM
  97. 97. NOT REPEATABLE
  98. 98. SLIGHT DIFFRENENCES
  99. 99. DOESN’T SCALE
  100. 100. HARD TO TRACK
  101. 101. ROLLBACK, ANYONE?
  102. 102. TRUCKS
  103. 103. MEANWHILE,IN THE REAL WORLD
  104. 104. MY SYSTEM IS ***
  105. 105. WHERE TO START?
  106. 106. WITH PRODUCTION and fix things backwards
  107. 107. AUTOMATE DEVELOPMENT and bring automation forward
  108. 108. DEPLOYS how do I?
  109. 109. DEPLOYS• blue-green• canary• emergency fixes
  110. 110. BLUEGREENtr affic
  111. 111. FULL BLUEGREEN IS COSTLY but great for availability
  112. 112. CANARYold old old newold old old new
  113. 113. EMERGENCY FIXES
  114. 114. EMERGENCY FIXES go the same way
  115. 115. DON’T BREAK RULES
  116. 116. CAVEATS!
  117. 117. STATE
  118. 118. LONG RUNNING *
  119. 119. SAGAS?http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
  120. 120. DATASTORESEACH APP HAS IT’S OWN ideally
  121. 121. DATASTORES SCRIPTED must
  122. 122. DATASTORESMIGRATIONS nice
  123. 123. DATASTORES TEST all of them
  124. 124. MAYBE EVENT SOURCING?
  125. 125. VERSION YOUR ENTITIES and code accordingly
  126. 126. BRANCHING
  127. 127. FEATURE SWITCHES instead
  128. 128. if your systemlooks like that
  129. 129. CUT!
  130. 130. • have integration tests• have a “test” system
  131. 131. DESKTOPS• LOVE your autoupdate• build-in version checking and inform user
  132. 132. DESKTOPSDo or
  133. 133. LOVE YOUR AUTOUPDATE
  134. 134. PUSH USER UP
  135. 135. IN PRACTICE
  136. 136. MODULES^N
  137. 137. PRE-TESTED COMMITS rock, a bit
  138. 138. DVCSrock, a lot!
  139. 139. VMSrock a lot!
  140. 140. THERE ARE TOOLS
  141. 141. IS AWESOMEbut
  142. 142. +
  143. 143. GLUhttp://linkedin.github.com/glu
  144. 144. GO ($$$)
  145. 145. PALDIES! kthxbye!
  146. 146. @ags313andrzej@grzesik.itandrzejgrzesik.info tweet please!
  147. 147. RESOURCES• http://continuousdelivery.com• http://lmgtfy.com/?q=continuous+delivery

×