The Firefox DevOps problem

Enterprise IT departments which have adopted the Firefox browser are up in arms over the new, rapidly iterative release schedule for the product, saying that it doesn't allow them sufficient time to test and adjust before deployments between releases. It strikes me that this is representative of the classic problem DevOps has set out to resolve, and an excellent example of why the DevOps paradigm is not more generally useful.

If you're not already familiar with the kerfuffle, you can get a summary over at GeekWire.

DevOps promises to address the problem of this disconnect between developers and operations teams, and it is being used successfully in many internal scenarios to do just that. That success has obscured the fact that those scenarios are mostly edge cases in the wider world of IT operations. Software deployment and subsequent operations are exclusively consumption-oriented in most cases: IT departments get software from commercial vendors, released on an independent schedule without special regard for the interests of any particular organization. Following DevOps tenets is simply out of the question; even if developers, working for their own company with its own goals, were willing, the install base for a product like Firefox is so vast that there's no way they could proceed on that basis with all the various operations teams responsible for deploying it. There may be feedback mechanisms, but nothing on the scale that DevOps envisions or requires.

This does not get IT operations teams off the hook with respect to being more agile. The point is that it really is something that needs to be done quite apart from the narrow lanes represented by DevOps. Even in organizations with significant internal development, most software is probably still coming from outside the company. The need to put processes in place to deal with the increasing numbers of these products being released in more rapid iterations is crucial; but the luxury of coordinating closely with the developers should not be among the base assumptions underlying these processes.