Someone sent me a message the other day asking for some help. They'd recently joined a new company that was thinking of setting up a "DevOps Department".
My immediate thought:
🚨🚨🚨 That's a recipe for failure before they've even begun. 🚨🚨🚨
K but why tho?
Usually when I see a "DevOps Department" or a "DevOps Team" or similar, it's implemented as a silo in the organisation. That silo holds all the knowledge regarding how to deploy and manage applications, and they're the only ones who can create new pipelines.
When that happens, development and operations don't work together any more than they did, they just have another group of people with their own priorities to contend with.
A new silo between Dev and Ops (or sometimes just replacing Ops) is completely against the point of DevOps.
Can it ever work?
Yes. I think so.
But only if that "department" is considered a knowledge center, and concentrates on the services and tools the developers and operations teams need to do things properly.
Tools like VSTS and Application Insights.
Or maybe GitHub, Team City, Octopus Deploy, and Raygun.
There are a ton of tools out there. The important thing is that the DevOps department not be the sole operators of those tools. They can guide, train, maintain, and manage those tools, but the developers and operations folks should be using them day to day. Not just clicking the buttons, but configuring builds, defining releases, pushing code that defines the infrastructure, watching production metrics, etc.
Cue happy teamwork shot:
The organisers of the Global DevOps Bootcamp put it well. The DevOps tooling should be self-service - it should be easy to configure a new pipeline, manage work, define new infrastructure, and monitor production.
✨ Easy does not mean raising a ticket with the DevOps department. ✨
Ok, so is my DevOps department destined to fail?
Is DevOps only practiced within that department?
There's your probable answer.