Perhaps I'm old school but as best I can tell, it seems like these are terms for management types to justify making one person do multiple jobs.
DevOps is not a job, despite many companies still don't understand what this term means. And NO, DevOps does not mean "All rounded IT+Dev person". There is no one in the world who could do both of these things together. IT is too complex nowadays.
DevOps is a practice for reducing barriers between the development world and the operation world, in order to let the business get the features they need as soon as possible.
To get them you have to:
- Reduce useless bureaucracy;
- Automate code integration and UNIT testing (Continuous Integration);
- Automate application delivery in the test environments (Continuous Delivery);
- Reduce the volume of changes in order to get small yet continuous improvements;
- Reorganize the teams in order in smaller yet complete squads with all the people you need for your projects (devs, sysadmins, testers etc.)
...and so on...
As you can see no one of the above points is a job description. DevOps is a set of rules.
And YES, it can improve how fast and how better the features your business needs are delivered.
One shop I am somewhat familiar with was fond of saying they were "Agile" but they produced buggy code that I was constantly having to fix.
This is wrong at many levels.
- The are producing buggy code, so I think they are not using extensively a UNIT testing framework to find bugs BEFORE the code is going to be delivered.
- Implying that you are a sysadmin, YOU don't have to fix anything. Systems shall be automated and as immutable as possible. So if there is a bug in the application, there should be an ISSUE on the developers VCS portal, then a PR with the fix. After that, the entire automated process starts again. Fixing things by hands is a BAD practice, especially since we're moving towards containers that are considered ephemeral objects.
Am I just being a curmudgeon or is there something actually useful in all this?
Every of us who are working in the IT have to understand a simple concept: what it is really matter is the business, not the IT itself.
IT exists to allow the business to make moneys, and we were hired for that purpose.
Waterfall model and the entire ITIL concept, aka the "old school style", are the reasons of why IT sucks so bad.
By using the old-style waterfall model, you don't get less buggy code. By letting 50 people approve a change because they are "THE MANAGERS", despite they're not even able to understand such change because it is not their job or because they have other priorities in their agendas, is not going to help you to release better code.
In fact you're getting code with too much CRs and PIs (and therefore too many bugs introduced), and often with also less automation. And all of that code is delivered in huge maintenance windows called RELEASE which will be followed by war rooms.