A lot has been said and written in these last 3 years in an attempt to define what DevOps really stands for. One thing most of us agree upon is that DevOps is not a job definition – it’s a culture, a mindset, a software manufacturing practice which is focused on breaking the walls between the developers and the operations. And it is a very cool and hip practice, one that everybody likes and everybody wants a piece of.
So job postings for “DevOps engineers” pop up each day like mushrooms after a summer rain.
And we adapt ourselves to the new realities and start calling ourselves DevOps engineers, even though half a year ago we were called CM, or integrators, or system engineers, or whatever.
I myself just signed a new contract for “DevOps” role. And yes – I’m going to do DevOps. But I know that if we want DevOps – everybody in the company has to do DevOps. So my natural goal is that every engineer in the company becomes a DevOps engineer. And that got me thinking – if everyone is a DevOps engineer – how will my role be different from all the rest?
I think I have found the right term:
I’ve always liked thinking of what we’re doing at work (you know, providing process automation, building CD pipelines, etc) as ‘enablement’ – as this enables all the other players of software development life cycle to do their work with more quality, efficiency, visibility and ease.
And that’s exactly what DevOps is for.
So if everybody wants DevOps, we’re going to enable the DevOps.
We’ll be the DevOps Enablers!
Originally posted at http://otomato.wordpress.com