7 Signs You're Doing DevOps Wrong
Software, tools, slow deployment times, and inability to accept failure do not pave the way for DevOps.
Join the DZone community and get the full member experience.
Join For Free
in an article in infoworld, adam bertram takes a look at some of the most common misconceptions and flawed implementations of devops. chances are, your company has fallen prey to at least one of them so read on.
sign no. 1: you need to buy “the devops”
“devops” cannot be obtained overnight with a simple check and a little training. it is a transformational approach to core processes, and it takes time, dedication, and especially a team that can implement devops practices, many of which will fly against your company’s previous modes of operation.
if your company has a devops budget, you’re doing devops wrong.
sign no. 2: you equate software and tools to devops
devops consists of a number of facets that go beyond configuration management; don’t focus in on only one simply because a solution exists and it’s tangible. if you look for something tangible to latch onto in your journey to be a devops ninja, you will fail.
if your company bought chef or puppet as a cure-all for its devops needs, you’re doing devops wrong.
sign no. 3: you use checklists or runbooks to manage code deployments
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. your company must understand that everything is on the table for automation. this means deployments, testing, code check-in policies, servers builds — everything.
if your company spends hours poring over checklists to ensure code is ready to be deployed, you’re doing devops wrong.
sign no. 4: you release code to production every few months (or years)
devops is synonymous with concepts like continuous integration and continuous deployment. notice the key word in both terms: continuous. devops is about consistently having developers check code in as often as possible, which kicks off automated tests.
for the true devops rock stars, it’s also about taking that code and sending it directly to production through continuous deployment. if your company allows developers to check in code that goes through automated pre-check-in tests, gets handed over to another set of tests to ensure that the code is ready for production, then goes live on your production servers if deemed ready automatically, then you know you’ve achieved devops greatness.
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.
sign no. 5: you consider failure unacceptable
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 your company is not practicing devops.
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.
sign no. 6: you blame others for system problems
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 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.
if your company is firing staff simply for bringing down production, you’re doing devops wrong — regardless of any presumed role or responsibilities you attribute to those involved.
sign no. 7: the developers and operations groups look like two grain silos
devops weds the word “developer” to the word “operations.” if your developers and operations people still aren’t on speaking terms, you don’t have a chance at doing devops right. 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 to developers other than throwing work over the proverbial wall, your devops dreams are toast.
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.
it’s all about the culture
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 of the devops philosophy that can be applied to your practices successfully.
for more devops misconceptions and best practices, download this whitepaper now!
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.
Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments