If that's the predominant definition, then pretty much everyone that coined the term, written books about it, or run devopsdays events has failed, and we might as well pack up the use of the term. Because not one of them would agree with this.
Devops is/was a professional movement to get developers and operations folks to communicate with one another, create a shared value system and culture, drive continuous learning, enhance automation, visibility/metrics, so we can all build software faster safely and sustainably.
Infrastructure as code was one small aspect of this. Continuous delivery, microservices, cloud native platforms, a sharing/collaborative culture, lean product development, modern alerting/monitoring, all were part of this.
But it seems tech pop culture cliche's win out over best intentions again and again, as they did with 'agile', 'cloud', 'structured programming', 'object oriented programming', 'reactive', and 'REST'
There are three (non exclusive) variants of this theme.
a) The term is misappropriated to refer to some something rather different from what it was originally meant to refer to. I may be guilty of doing that.
b) The concept was too fluffy to begin with and sparked a cottage industry for consultants without helping anyone else.
c) The original ideas were flawed and have so many unintended consequences in practice that people rightly start associating the term with those negative outcomes instead of the well meaning goals.
Perhaps a bit of all the above is what's causing the dissonance here.
b) Consultants (good and bad) always sprout up in any area, and have throughout history (see: Sophists vs. Charlatans).
But, what is "fluffy" (ill-defined, nebulous, uncertain, difficult) to one person is a deep area of research for another.
Put another way, people tend to dismiss what they don't understand or can't see as unimportant. This is the "looking for your lost keys under the street lamp" syndrome. Most often people can only understand the future in terms of the past, and if they don't have past exposure to a topic, they're not going to see its relevance unless they put extraordinary effort in to pay attention.
For example (not necessarily directed at you), Devops folks really put a lot of emphasis on Lean concepts that come out of the Toyota production system. But if I think "wtf do I care about making cars?", I might think ideas like "Continuous Flow" or "Cost of Delay" as being fuzzy and irrelevant to my work as a developer. But they have huge impact over how work is organized and made productive, and literally billions of dollars have been spent developing and honing these ideas in the product manufacturing industries... that just might have broader relevance to the dysfunction of how traditional enterprises run their IT shops vs. how Amazon does.
As for c), all ideas are flawed and have unintended consequences :) , focusing too deeply on the negative is a cynical reaction that often gets back to (b).
That's very much not the predominant definition, most companies that hire DevOps people just use it as a different name for a more modern infrastructure engineer. Shitty cheap companies use it to hire developers & infra in one role. My personal opinion is that a DevOps engineer is someone who probably once was a developer so he's very well versed in coding, but switched over to infrastructure.
That's not my understanding of the term DevOps. Rather, DevOps means using version-controlled artifacts for deployment rather than manual deployment or one-off scripts, and to consider those artifacts a "product" in their own right, or part of the main development artifacts. So that qualified devs could create/edit those along with other developer artifacts, though frequently these artifacts are created by admin-like persons.
And I don't see DevOps becoming obsolete at all; just the other day I spend deploying apps with an ops guy, where neither of us could do it all on his own: the ops guy lacked understanding of the code bases, the endpoints to configure, and integration test procedures, me not having permissions to redeploy and view logs.
The buzzwords are ultimately meaningless but that sounds more specific to ”infrastructure as code” than the meaning of “devops”. With iaac basically being one of the facets of devops. Does that sound right to you?
I don't know. IAAC is a much newer term than DevOps, and used primarily in combination with IAAS, so I think its meaning can't be used as an argument to give or take away meaning to the term DevOps.
It generally means "ops work that is done with the best practices of dev work".
Yes, that means infrastructure as code, including code reviews, frequent deployments, etc.
No, it doesn't require that the developers working on the devops code are the same ones who work on the app code. At a small company (e.g., three devs) they will be, but at a large company, you have a dedicated "devops team" who exclusively works on infrastructure (as code).
It’s more or less a logical following of infrastructure as code, because it’s the developers who write and push those files.