I recently presented a webinar on What Does DevOps Culture Feel Like? in which I attempted to characterise what it feels like to work within a DevOps culture (part of the Experience DevOps workshop series).
Operability can Improve if Developers Write a Draft Run Book
The run book (or system operation manual) is traditionally written by the IT operations (Ops) team after software development is considered complete. However, this typically leads to operability problems being discovered with the software, operational concerns having been ignored, forgotten, or not fully addressed by the development (Dev) team. If the software development team writes a draft run book or draft operation manual, many of the operational problems typically found during pre-live system readiness testing can be caught and corrected much earlier. Because the development team needs to collaborate with the operations team in order to define and complete the various draft run book details, the operations team also gains early insight into the new software. Channels of communication, trust, and collaboration are established between the traditionally siloed Dev and Ops teams, which can help to establish and strengthen a DevOps approach to building and running software systems.
I…
View original post 1,295 more words
Leaving the Platform – Branching and Releasing for Independent Subsystems
For several years, much of the code for the systems at thetrainline.com has been versioned and deployed together as a single ‘platform’. Recently, we have begun to divide up the platform into smaller chunks, to enable us to deliver some parts more frequently and rapidly, leaving other parts to evolve more slowly (as needed). Moving from a single version number for all subsystems to multiple version numbers for independent subsystems has implications for how code is built and released; this blog post outlines some of the work we have done so far in this area.
My colleague Owain Perry and I recently presented on this topic at the London Continuous Delivery meetup group (http://londoncd.org.uk/) and the slides we showed relate to the details in this post:
View original post 1,214 more words
Chef on Windows – detecting and fixing WMI problems which prevent chef-client runs
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
The Business Case for DevOps – DevOps Summit May 2013, London
I chaired the May 2013 DevOps Summit in London, whose theme was Enabling DevOps. I gave a talk on The Business Case for DevOps (blog post), and the slides are on SlideShare:
(Thanks to all those credited on the final slide, and to Unicom for organising the event)
Matthew Skelton 