Misunderstanding DevOps… again

A few days ago I read on LinkedIn a comment from a guy who said that DevOps being about principles, team building and good practices was almost bullshit, because in the end you needed tools like Docker or Kubernetes.

If you follow me you’ll know that I precisely wrote the opposite in this post, and when I read this guy’s hateful words I got pretty mad.

In my company we’re currently working with a well known paid CRM platform so no “standard” tools or out of the box solutions can be used. That means no Maven, no Gradle, no SonarQube, no Docker, no Kubernetes. But yes, we are achieving a DevOps approach and I’m telling you why.


I think the key to DevOps is understanding the daily problems that colleagues face doing their daily work.

One of the many things we did when we started was to have some sessions with main developers to get to know their problems and share their experiences when doing manual steps on a daily basis.

We needed many more sessions with them but in the end we understood every aspect of their common processes, so then we could think about a solution.

Simply you cannot provide tools to solve a problem you don’t know anything about.


You can design the ultimate machine to automatically peel bananas and give it to a monkey. Yes, it can be the perfect machine but if you don’t tell the monkey why and how it should use that machine, it’ll keep doing things as always.

People can get confused when they get out from comfort zone, so our developers did. We had to migrate from Subversion to Git so we had to have a lot of workshops with them to let they understand why we were introducing all of these changes, not only to their repository engine but also in their workflows. Their procedures were really wrong, and we tried to teach them how to do things right.

So you can’t simply give a fully automated pipeline and just wait to everyone to adapt to it, because this will make people mad and asking who the hell are you.

Teaching and sharing knowledge is essential in DevOps.


Not having the popular tools doesn’t mean you cannot go fully DevOps, it only does things more interesting! :)

Instead of SonarQube we used the not so well known PMD code analysis tool. It was fun to learn new technologies and get some new experiences and challenges.

Instead of Docker we had to create some scripts to automatize their deployment process in the CRM platform, hosted in the cloud.

So yeah, using buzzwords and state of the art tools is always cool, but there’s nothing that a shell script can’t do. ;)


I’ll keep getting mad when people say DevOps is about tools and automation, simply because it’s not true and generates confusion.

DevOps is about empathizing with people to solve their daily suffering, no matter if you use some trendy tools to achieve it or not. It’s about telling people about good practices and provide them a good work environment. It’s about researching how to improve day by day.

So, again, please don’t misunderstand DevOps! ;)

PD: I wanted to dedicate this post to my colleagues from work, for their daily effort to move the project forward. :)

Like what you read? Give Adam Barreiro a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.