on continuous delivery
December 2, 2010
Posted by on
This comes very familiar to me. Some extra comments:
- Releasing frequently, well frequently is very relative. Releases should consist of small change set in order to keep the impact of the changes “predictable”. A way of achieving this is using agile methods like scrum.
- Everyone can self-service deployment is a tricky thing. You can do this if you architecture is not too complex, so that everyone understands what happens during a/any deployment. If the architecture is complex, then people will be only deploying their application. This requires a very good communication culture and channels. You may say …”no no, all you need is to automate”, if you are so far, please let me know.
- Puppet, well that is just a tool. The point is to automate your deployment process to the max. Infrastructure as code will be the answer.
- Metrics is a very important point. Without them you a driving blind and no automation will be possible.
- I love the “How log will it take your organization to deploy a change the involves just one line of code?“. … how agile are you?
- “If it hurst, do it more often …” kind of masochistic but very effective.
- “make your build self-healing” … I wonder what that will look like.
I got the mindmap from http://code-dojo.blogspot.com/2010/11/mind-map-continuous-delivery-notes.html