when relevant content is
added and updated.
More than once recently, I have both seen and had discussions about DevOps. Usually it begins with someone making the claim that the rising popularity of the term is silly. There are a few different ways to think about DevOps. Something along the lines of — a set of methods and tools that help developers get code into an environment faster — is good enough for me. Practically, DevOps has people writing test automation to reduce testing cycles, using tooling to get builds faster, and building tools to get a product delivered sooner. I like to think the word as an abstraction, like the word agile (or Agile if you must). It covers a vague group of things that you may, or may not do.
The debates I see are usually claims that DevOps is NOT new, ops and development have been working together to release software since the beginning of time. I think they are right to some degree, but I also think it’s worth digging in to.
Early on in software, maybe in the mid to late 90s (and maybe still for some companies) operations amounted to creating new builds, sticking it on a disk in the form of an installer, and shipping that out to customers. There was always some need for developers to get into the mix to help with the build, or creating the installer, or as an information source. That scenario didn’t happen very often though, maybe once a quarter or every six months.
What we are now calling DevOps was part of the role of a technologist, but not very often and it just didn’t take up that much time. The timelines are much faster now.
Most software companies are shooting to release software every two weeks now. Some are doing it every day. So, instead of releases being almost an afterthought, where we have to refer to a wiki to remember what tools and commands are needed to put things back together, we have 31 flavors of automation that require people do deal with the tools and processes all the time. There are tests (or rather, checks), builds, continuous integration, and continuous delivery. An entire set of tools has come to exist over time to facilitate getting product to people faster and instead of using them 2 or 3 times a year, we use and think about them daily. Build Manager used to be a person that ran around spinning up builds, nor DevOps is part of the role of several different teams.
Why Do We Care
Yes, we could simplify and say that this is nothing new, people have worked together for ever to make builds, and what we have now is just iteration on an old idea. There is nothing new under the sun, right.
Debates like this are pretty common when a a field is inching forward or developing some how. Whether or not DevOps has been around for a long time, or the recent popularity of the term, isn’t really the interesting part. We should take the upswing in popularity as a sign that some people were self-aware enough to notice the work they were doing, and to name it. And more importantly, study the work and figure out how to do it better.
For me, the right reaction to hearing a term that at first listen doesn’t seem to add much to what we do, is to investigate. Rather than express outrage about something having been around for ages before it got a cute marketing name and a few books, I scratch my head and say “huh?”.
Confusion is a great tool, it shows that I can point myself in that direction and learn something new. Maybe the confusion is stemming from imprecise language, like using the word DevOps to describe part of the developer role instead of the specific practices that are wrapped up in there. Having that conversation is worth the time. If I’m lucky, it will turn into something valuable.