Your SlideShare is downloading. ×
  • Like
Continuous Delivery
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Continuous Delivery

  • 955 views
Published

from JavaDays Riga '12

from JavaDays Riga '12

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
955
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
13
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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