Why not every DevOps strategy is worthy of your attention
DevOps advice is plentiful today. Some, like Cameron McKenzie, would say it is too plentiful. Here's his advice for weeding out the unworkable from the sensible.
If the current hype cycle is any indication, the industry must be approaching peak DevOps. It simply would not be possible for the tech media, along with online seminars, social media and conference sessions, to provide any more opportunities for advocates and evangelists to offer up DevOps advice. And in light of this onslaught of opinions, we should note that some of this advice is significantly better than the rest. In fact, much of the DevOps strategy we're hearing is outright nonsense.
I'm in the process of publishing two articles with advice for both development and operations personnel about the things they can do in order to prepare themselves, and perhaps even pave the way, for DevOps adoption in their organization. All of that advice, such as learning a scripting language like Groovy, or installing a local continuous integration server, pertains directly to DevOps. A DevOps strategy that is actionable and pertinent is a great idea. Advice that isn't? Well, that isn't good advice.
Bad DevOps advice
The worst piece of DevOps advice I hear -- and I hear it over and over again -- is that the first step in doing DevOps is to get your operations and development teams communicating with each other. If you ever see a DevOps evangelist tweet that, unfollow them. If you hear that in a seminar, leave the room. If a manager says that on a conference call, quit your job. Anyone who says that doesn't know the first thing about transitioning into DevOps.
Any change that can't be measured, tested and evaluated simply isn't worth doing.
If you work at a company where the operations team and development team refuse to correspond, a DevOps strategy isn't going to solve your problems. Operations and development are two important departments that absolutely must communicate with each other, regardless of what your software development philosophy is. If people inside your company refuse to communicate, won't respond to email and expectorate on each other when they pass in the halls, then your problems are far beyond the scope of DevOps. That's a human resources issue, and if your organization can't address a basic human resource issue, then your organization has no business even talking about a DevOps strategy.
Any advice that is so general and so nebulous that it can be applied to any situation, regardless of whether an organization is doing DevOps or not, should be rebuked as soon as it's offered. Yes, teams should communicate with each other. You know what else? Employees should show up for work on time. And developers shouldn't take two-hour lunches. Is that a DevOps issue? No, it's not. And from a DevOps strategy perspective, the advice is worthless. When an advocate can't tell the difference between an HR issue and a DevOps issue, you know their advice is without merit.
Good DevOps advice
DevOps isn't about getting two teams to communicate. If anything, when DevOps is done right, there should be less communication between operations and development. I recommended teams identify any manual authorization or verification steps that occur in the deployment process. After identifying them, the next step is figuring how to automate them.
For example, if the head of operations must sign a requisition form before a weekly deployment occurs, then DevOps teams need to figure out a way to automate that process. Figure out why the manual sign-off is necessary, create a set of tests that replicate ops' thought process when the requisition is made and write a script that can be fired off by your continuous integration server that runs those tests and makes the deployment happen.
Change you can test, measure and evaluate
That's good DevOps advice. It identified a problem, namely the requirement to sign off on a requisition form. It suggests steps that can be taken to address the problem. And, finally, the solution can be tested and validated. If your DevOps team has eliminated the need for a senior manager to sign off on a requisition form, then it's flattened a speed bump in the software development process. That will cause the velocity of deployment to increase. Good advice addresses a problem, proposes solutions for fixing the problem and includes a mechanism to test whether the change has worked. Any DevOps strategy which advocates a change that can't be measured, tested and evaluated simply isn't worth doing.
The bottom line is that there are real, substantive things IT teams can be doing to make DevOps work. But there are also a lot of heretics in the industry repeating cliché phrases and meme-worthy nonsense about changing culture or communicating better. It all sounds good in a tweet, but when it comes to actually implementing DevOps and increasing the velocity of software development, IT professionals need actionable advice that pertains directly to the task at hand.
If the DevOps strategy advice you're hearing isn't actionable, and it is so hippy-dippy that it could be applied to pretty much any job in any industry, then it's not DevOps advice. More likely than not, it's just nonsense.
