Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous deployment

414 views

Published on

When you do Continuous Deployment you can deploy whenever you want: you made it as easy as possible and you have become very good at it. Every engineer knows how to deploy the application to any environment. The Product Department can always see the latest bells and whistles as they are built because you have Stable servers running the latest versions of the application. You implement big changes gradually and show them to Product while keeping the customer's experience stable. When you decide to release, you have made sure all things will work and you know how to react if nevertheless they break, without fires or panic.

Continuous Deployment also forces you to do many right things: repeatable builds; the exact same deployment process in all environments, including the developer's machines and a development environment that is as close to Live as possible; backwards-compatible database changes; easy rollbacks; code that is split into components; good tests...

In this talk I give an introduction to Continuous Deployment: why you should care, what it means and I propose a few first steps towards introducing this methodology.

I presented this talk at DjangoCon EU 2013.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Continuous deployment

  1. 1. Continuous Deployment Òscar Vilaplana @grimborg dev@oscarvilaplana.cat DjangoCon EU 2013
  2. 2. """We're hiring!""" from paylogic import (code, highavailability, challenge) from netherlands import (fun, nature, bikes, beer) def hire(you): email('oscar.vilaplana@paylogic.eu', you.cv) return challenge.accept()
  3. 3. """We're hiring!""" from paylogic import (code, highavailability, challenge) from netherlands import (fun, nature, bikes, beer) def hire(you): email('oscar.vilaplana@paylogic.eu', you.cv) return challenge.accept()
  4. 4. intro
  5. 5. deploy
  6. 6. easy
  7. 7. good at it
  8. 8. everyone
  9. 9. Product Owner
  10. 10. Stable
  11. 11. latest versions
  12. 12. big changes
  13. 13. gradually
  14. 14. acceptance
  15. 15. stable
  16. 16. works
  17. 17. Done
  18. 18. breaks
  19. 19. don't panic
  20. 20. forces
  21. 21. Right Things
  22. 22. repeatable
  23. 23. identical
  24. 24. deployment
  25. 25. environments
  26. 26. backwards compatible
  27. 27. rollback
  28. 28. components
  29. 29. tests
  30. 30. yes it does!
  31. 31. start working
  32. 32. energy
  33. 33. download
  34. 34. setup.py
  35. 35. broken
  36. 36. dependency
  37. 37. pip install
  38. 38. setup.py
  39. 39. nope
  40. 40. docs & hack
  41. 41. for(;;)
  42. 42. pip uninstall giveafuck
  43. 43. Life life = new Life()
  44. 44. taming a lion 1800s
  45. 45. beat into submission fear guns & whips confusion
  46. 46. taming a lion present
  47. 47. understand conditioning behaviour → signal reward trust
  48. 48. taming a lion 1800s
  49. 49. beat into submission fear guns & whips confusion
  50. 50. deploy by hand, hack fear guns & whips confusion
  51. 51. deploy by hand, hack but it works! guns & whips confusion
  52. 52. deploy by hand, hack but it works! hack till it works confusion
  53. 53. deploy by hand, hack but it works! hack till it works special decisions
  54. 54. taming a lion present
  55. 55. understand conditioning behaviour → signal reward trust
  56. 56. deploy: hard conditioning behaviour → signal reward trust
  57. 57. deploy: hard CI behaviour → signal reward trust
  58. 58. deploy: hard CI push → test → green reward trust
  59. 59. deploy: hard CI push → test → green happy trust
  60. 60. deploy: hard CI push → test → green happy it works in Live
  61. 61. what you needwhat you need
  62. 62. team
  63. 63. working software
  64. 64. repeatable build
  65. 65. deployment
  66. 66. rollback
  67. 67. release
  68. 68. team
  69. 69. committed to quality
  70. 70. process can't compensate
  71. 71. pip install giveafuck
  72. 72. everyone deploys
  73. 73. identical environment
  74. 74. everyone is responsible
  75. 75. learn
  76. 76. working software
  77. 77. tests
  78. 78. unit tests functional tests acceptance tests
  79. 79. acceptance: user's viewpoint
  80. 80. continuous integration
  81. 81. quick reliable
  82. 82. slow test: fail
  83. 83. no pylint: fail
  84. 84. keep it green
  85. 85. check in often always ready to rollback
  86. 86. responsible: dev + qa
  87. 87. quality
  88. 88. broken: triage
  89. 89. right now vs asap
  90. 90. repeatable build
  91. 91. automated
  92. 92. used by everyone everywhere
  93. 93. no manual changes
  94. 94. deployment script
  95. 95. used by everyone everywhere
  96. 96. deploy.sh <environment> <version>
  97. 97. not just code configuration infrastructure
  98. 98. always follow pipeline
  99. 99. even on emergencies
  100. 100. buggy changes unknown state irreproducible what went wrong?
  101. 101. what went wrong?
  102. 102. rollback
  103. 103. blue-green green is live release to blue test, accept blue is new green
  104. 104. canary show new version to a few
  105. 105. database: keep backwards- compatible
  106. 106. release
  107. 107. last step automatic
  108. 108. small changes frequent experience less risk
  109. 109. maybe not for you
  110. 110. tips
  111. 111. split in components
  112. 112. rehearse releases get very good at them!
  113. 113. infrastructure manage and test
  114. 114. all environments equal use vagrant
  115. 115. automate everything (not possible? document)
  116. 116. Questions? Answers? @grimborg dev@oscarvilaplana.cat Thank you!

×