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
November 18, 2010
Posted by on
This is some amazing video about a good manageable application and the operations team around it. This what devops are up to. Only when software engineering and operations work together you get this brilliant. Great job!
Open Mic 2: Continuous Deployment and Operations Dashboards at kaChing from dev2ops.org on Vimeo.