In a recent talk at PuppetConf 2013, co-author of Continuous Delivery and DevOps champion Jez Humble advocated passionately for not hiring in DevOps ‘experts’ but for cultivating a culture of collaboration and learning (slides 5-7)
This approach of nurturing a DevOps culture within your own organisation is what you will take from attending one of the Experience DevOps workshops; see http://experiencedevops.org/ for forthcoming workshop dates and locations.
I attended a workshop at DevWeek 2012 led by Neal Ford (@neal4d) on Continuous Delivery (CD). The day was excellent – Neal is a really engaging presenter – and I took copious notes, even though I’d already read most of the CD book. Fifteen months later, I thought it would be interesting to see how my notes from Neal’s workshop compared with my experience of Continuous Delivery, both within my job at thetrainline.com, and also in conversations with other people, particularly the good folks in the London Continuous Delivery meetup group.
The tl;dr version: go attend one of Neal’s excellent CD workshops, but be prepared for the challenges with Continuous Delivery to be much more social/organisational than technical.
Continue reading Continuous Delivery Workshop with Neal Ford (@neal4d) – a Retrospective
This post covers some issues we had recently with chef-client on Windows due to missing WMI classes, and how we diagnosed, fixed, and mitigated the problem.
At thetrainline.com we use Opscode Chef for managing our build infrastructure. Like many other tools running on Windows, the chef-clientohai framework relies on WMI for extracting information about the server machine on which scripts are being run. We found that Windows WMI repository corruption can cause chef-client runs to fail due to missing WMI classes, which causes the node to remain out of policy. The WMI repo can be repaired using winmgmt /salvagerepository, and the WMI errors can be monitored using the WMIDiag script to alert on WMI repository corruption before future chef-client runs. This post details how we detected and fixed the problem, and how to monitor for WMI repository corruption.
View original post 1,131 more words
Here is a video interview I gave summarizing some of the main themes and discussions which came out of the DevOps Summit on May 23rd in London: a shared goal for development and operations; anti-fragility as a way for DevOps and ITIL to complement each other; surface the quality of the software for all to see; tools can produce a step change in behavior for the better; and use the theory of constraints to focus improvements.
[At the Unicom DevOps Summit on 23rd May 2013 in London I gave a talk on The Business Case for DevOps; here is a summary of the talk, along with the slides. Update: now with video too.]
With an increasing number of organisations turning to DevOps to try to improve their software systems, it is becoming necessary to provide the business case for introducing DevOps, especially in organisations which perceive their main focus to be something other than software systems.
For me, building the business case for DevOps has three strands:
Matthew Skelton 