The DevOps movement has produced many benefits in a short time: shorter lead times, greater intra-organisational communication, smaller feedback loops and more productive teams. It has also produced many myths and misconceptions. Here’s a few that I’ve encountered recently.
Of the organisations [1] I’ve worked with that use the DevOps label, the one that works closest to the original definitions (such as this one by Patrick Debois) is foiled by being separated from all things post-staging because their production operations are outsourced. There is good communication in this organisation; all the -ilities (scalability, stability, security, performa.. uh. bility?., etc.) have requirements and are measured against those requirements; feedback from operations is quickly acted on by product development and leadership teams; and all the deployment and monitoring tools in use in production are also in use in staging environments. This organisation is very mature in DevOps terms (they’ve got the culture), though they’re not all the way there yet.
The DevOps team (or in small organisations, the DevOps person) is probably the most common mis-implementation of DevOps. A core value of DevOps is to employ the entire organisation to conceive, design, develop, release and maintain valuable software. If only one team or person is doing that, then the rest of the organisation must be redundant. And more likely, if the DevOps team or person is doing only a part of that (typically, release engineering), then they are, by definition, not DevOps. No matter how well they do those DevOps-y things.
Two organisations I’ve worked with lately have used DevOps to describe the internal support role: the IT guy who provides assistance to the dev team. That’s just a misunderstanding of the term: they’re not doing anything new or trying to be DevOps, it’s just an error in labelling. In both these cases, because there was just the one person packaging releases and deploying to test and pre-production environments, there was no oversight and no drive to automation. Both organisations are ideally placed to start on the path to DevOps, yet they use the term to describe what they already have. In other organisations I have worked with (which thankfully have not yet chosen to use the term DevOps) there are entire teams of post-development internal support engineers. These organisations face a bigger challenge should they choose to work towards DevOps, since they have institutionalized the separation between software creation and software support.
In the worst case of mislabeling that I’ve heard of, the so-called “DevOps team” was formed by collocating the developers and the testers. The organisation did not change its thinking, no practices were changed, no roles were merged, the path to production was not improved, and responsibility for in-production software remained with the (outsourced!) post-release support team. I suspect that a hands-off executive mandated DevOps and an expenditure-averse manager came up with this solution.
In addition to these cases that I’ve personally encountered, there are plenty of other stories of misadventures in DevOps. There are lots of examples of organisations that separate DevOps from Ops/Support (effectively renaming “Dev” to “DevOps” without changing anything substantive). Less commonly encountered these days are the organizations that allow ad hoc hot fixes direct to production (a fast road to failure!).
The many misunderstandings about what DevOps means are completely understandable since it’s such a new term to most people. These few examples of what not to do are hopefully giving you a few ideas about what you should do. I’ll go into just a little more depth on some of the key terms associated with DevOps.
1: I’m using organisation to refer to the IT and product delivery facets of a company or enterprise. This includes company leadership, marketing, finance and other facets that overlap product delivery, even if they are mostly employed in other areas of the greater enterprise.
Related courses
Related services
Guest Post by Paul Hicks, IntergrationQA
Your details have been submitted and we will be in touch.