I recently came across an article in InfoWorld where Adam Bertram takes a look at some of the most common misconceptions and flawed implementations of DevOps. The read proved not only interesting but instructive.
So with that in mind, I’ve decided to share my own distilled version of Adam’s thoughts with you. Take heed, because chances are your company embodies at least a couple of these warning signs. Mishandling DevOps can be a nail in your coffin. Knowing that you’re mishandling DevOps and exactly how can be the opportunity you’ve been waiting for.
DevOps cannot be achieved overnight or acquired with a check and a little training. It’s a transformational approach to core processes, and it takes time, dedication, and a team eager to change and grow.
These qualities are as uncommon as they are valuable and as such making the shift can ruffle some feathers. Not infrequently DevOps methods fly in the face of entrenched practices and long-running modi operandi.
To successfully “go DevOps” takes hard work, resolve, and trust in the process. It can’t be rushed and it can’t be bought.
TLDR: If your company has a “DevOps budget”, you’re doing devops wrong.
True DevOps contains many facets and goes well beyond configuration management. Accordingly, you would be doing yourself a disservice if you took a single-minded approach to DevOps. There’s no one solution, tool, or technique that will cement your DevOps bonefides.
In my experience, I’ve found that more often than not, if you’re preoccupied looking something tangible to tether you in your pursuit of DevOps, you’re probably missing the point. It really is a process and there are no shortcuts.
TLDR: If your company bought Chef or Puppet as a cure-all for its devops needs, you’re doing devops wrong.
DevOps-heavy cultures realize that even though it may take more time to introduce automation up front it will pay off through more reliable and faster code deployments in the future.
Part of DevOps is freeing yourself and your organization from legacy procedures and rigid processes. To this point, smart automation is beyond recommended. It should become your bread and butter.
Your company must understand that when it comes to automation, everything is on the table. This means deployments, testing, code check-in policies, server builds – everything.
TLDR: If your company spends hours poring over checklists to ensure code is ready to be deployed, you’re doing DevOps wrong.
DevOps is synonymous with concepts like continuous integration and continuous deployment. Notice the key word in both terms: continuous. DevOps is about having developers check-in code as often as possible, triggering a battery of ongoing and automated tests.
For the true DevOps rockstars, it’s about sending code to production as often as possible through continuous deployment.
If your company allows developers to check-in code that goes through automated pre-check-in tests before being passed to another round of tests to ensure that the code is ready for production, you’re on the right track. If that code automatically goes live on your production servers when fully test approved, then you’re on the cusp of DevOps greatness.
TLDR: If your company releases code changes less frequently than the harvest moon, you’re doing devops wrong – no matter how small the changes or how quickly you make them.
When the code you committed goes on to blow up a production database, what happens to you? Does your boss publicly scold you? Do you get immediately called into a manager’s office for a “closed door” meeting? Is losing your job or your ability to deploy code to production ever again a possible outcome of committing code? If so, then you’re not actualizing the lipservice you pay to DevOps.
DevOps is about empowering your talent to take stock and ownership of their software ecosystem and push for their own success. That means they can’t be afraid of trying things and taking calculated risks.
TLDR: If you are no longer trusted with commit rights to production because you have made or might make a mistake, you’re doing devops wrong.
Continuing with the theme of sign #5, true DevOps practitioners believe that when something goes wrong the fault doesn’t lie with the individual using the system but the system itself. For developers and systems ops to get along, a blameless culture must be supported.
Suppose a developer creates an application, tests the application on his or her computer, and hands the code over to operations. If a problem occurs when ops puts the code into production, ops can’t blame the developer for writing shoddy code. Nor can the developer blame operations for not managing servers correctly.
TLDR: If your company is firing staff simply for slower production, you’re doing DevOps wrong – regardless of any presumed roles or responsibilities you attribute to those involved.
DevOps combines the words “development” and “operations.” If your development and operations teams still aren’t on speaking terms, your prospects for successful DevOps are precarious, to say the least.
DevOps is all about collaboration. It’s about coming together as a team to help the company, as a whole, achieve its goal. If your operations people refuse to communicate with developers beyond throwing work over the proverbial wall, your mishandling DevOps.
TLDR: If your company has developers on one floor and operations on another, with code commit messages as the only means of communication, you’re doing devops wrong.
DevOps is not for every company. There are situations that warrant a more meticulous approach to code management. However, even if your company isn’t fully committed to building a DevOps culture, there are many facets to DevOps that can still be applied to your practices successfully.
Above all, DevOps is a cultural philosophy. It takes patience, lots of hard work, an understanding of people, and a business that will support it to truly thrive.