The Human Side of DevOps
The Human Side of DevOps
If you make it all about automation and forget the people, it will never be true DevOps. Only true collaboration of the Devs and the Ops can lead to optimal results.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
I recently read a post titled What Is DevOps? The post made it to the DZone's front page and got a decent bunch of likes and positive comments, but to me, it missed a very important part of the DevOps culture: The human side.
Automation, Automation, Automation
Right after a brief introduction, the author of the text posted an image depicting "the collaboration between development, QA, and operations teams:"
Not so long after that, the author posts a quote:
"DevOps is the offspring of Agile software development." — Dennis Ehle
Despite this early Agile inclination, the text then goes full nerdy and reduces the topic to automation. You have to automate everything! Automate your planning! Automate your delivery! Automate your testing! Automate yourself! The author goes as far as saying this:
"A DevOps engineer helps all of these stakeholders adopt Agile gracefully. They automate everything right from the planning phase to the release phase."
The Human Side
Although I truly believe that automation is great and we should automate as much as possible, I would not consider it the one most important part of neither Agile nor DevOps. What I'd go for instead is the old and so often ignored part of Agile Manifesto:
Individuals and interactions over processes and tools.
That's right: Individuals and interactions! People working together! People collaborating, like in the collaboration diagram above!
Collaboration Is Necessary
Look: It would be really nice to have all of the repetitive processes automated and developers that know how to make the best out of the tools — but this is the end of the road. In the middle of this road, you will have a lack of automation, developers who don't know how to use the full potential of available tools, infrastructure problems, legal issues, and much more. At the beginning of the road, you might have nothing, actually; maybe a virtual machine with a Tomcat server and a bunch of WARs that someone puts there by hand. What then?
You might say that you simply push for more automation, but resources are always limited and we often want to get things done "now." The world won't wait until your infrastructure is ready. This is the point when the "collaboration" word shines out. You can either join your forces, solve the problems together, and find out the best solutions for all sides, or you can stay in the "us and them" mentality, throw things over the wall, and blame the other side.
My experience with DevOps so far matches this picture. Zooplus seems to be some kind of middle ground between being fully automation-oriented and being collaborative. Some problems are resolved together; some are resolved separately. Some things are communicated well; some surprise us long after things are out and running. As you'd expect, the results are somewhere in the middle, too. We make stuff work and we talk with the Ops, but I feel like we're more aligning to each other than working together.
In my humble opinion, if you make it all about automation and forget the people, it will never be true DevOps. It will always be the Dev and the Ops separately. Only the true collaboration of both sides can lead to optimal results, especially when we're at the beginning of the DevOps road.
Opinions expressed by DZone contributors are their own.