To everyone with DevOps in their job title (a quick LinkedIn search turned up 432,081 DevOps traits ) folks, we are doing it wrong.
To every employer looking to fill positions like "DevOps engineer" you, too, are miserably misguided.
As it turns out, DevOps isn't "a job title, a software tool, a team name, or magic enterprise fairy dust", as Brian Guthrie mentions, but rather "a set of practices that encourage continuous integration into production".
We know this, right? And yet those job titles, that tooling... we can't seem to get away from them. Vendors complicate this problem, but given that DevOps is really about culture change, the primary person to blame in all this mess, is us. We are also the people who can fix it.
...Once the path is set right
It's not crucial that the process is fantastic to start. The point is that it's something the various team members agree upon and are empowered to tweak/improve as they go. It's also important to visualize this process, so that everyone clearly understands the workflow and can point to where issues bottleneck it. Just don't expect employees to change simply because you crowned them the DevOps team/person
What it means by "becoming DevOps"
According to Guthrie: "If you think DevOps is a toolkit and not a practice you're missing the point. If you think it's a role and not collaboration between roles you're missing the point. If you think it's a team and not an organisational feedback loop you're missing the point. The goal of that journey is the acknowledgement and recognition that software is safer when people with complementary skillsets in technical operations and software development work together, not apart."
Again, it can't be stressed enough that DevOps is not a skillset and it's not a toolset: it's a mindset. That mindset involves a collaborative approach, whereby operations folks trust product developers to deploy code, and product developers neither understand nor trust the way operations needs code deployed. One way to think about it is that developers need to think about the stability of the product as just as important as the features; that is, that "the product" is the complete experience with the product, and not merely a long list of features.
But let's be honest, we are not there yet.
OK, now what?
For one, says Guthrie, we can focus on "incremental change, tight feedback loops, shared knowledge, and mutual respect". If you're a developer releasing large change sets, you're part of the problem. Work on incremental change with an eye towards performance and stability. In other words, start to change culture by virtue of how we change the way we develop software.
For operations folk, it's time to start measuring everything, perhaps starting with time to market and cycle time, as Magnus Hedemark has suggested. The first measures the time it takes to go from conception of a feature to the point that a customer can actually consume it, and the latter measures how long it takes to go from an engineering team working on a project to the customer being able to access it. Both help to fine-tune the overall effort necessary to delivering software.
Another important step, as Hedemark points out, is to kickstart a process.
Hedemark says: "DevOps success requires an organisation to put a regular (and hopefully effective) process in place and relentlessly improve upon it. It doesn't have to start out being effective, but it must be a regular process. Usually that it's some flavour of agile methodology like Scrum or Scrumban; sometimes it's a Lean derivative. Whichever way you go, pick a formal process, start using it, and get the basics right."
Once the basics are set, let's dive in to the DevOps Tools!
Inspired from: https://www.theregister.co.uk/2017/12/08/devops_real_talk/