9 Antipatterns to save your DevOps from becoming DevOops
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” ― Rick Cook, The Wizardry Compiled
Being one of those software engineers on the losing side, I know of one more race that is against the contemporaries to deliver better applications and services in minimum time. And races like these bred cultural transformations in development practices. One such cultural shift is DevOps. In simple words, it is all about streamlining the software delivery process and making it more fast and efficient with the ultimate aim to achieve organizational success. It is with this goal in mind that cross-functional teams consisting of software developers, ops experts, product owners, Quality Assurance (QA) professionals, etc. came into existence. A significant number of businesses are resorting to DevOps in recent time and this number is growing rapidly.
But setting on a course to stranger tides could be a dangerous business. You might end up losing yourself and the ones on the vessel with you too. DevOps is one such journey. In July 2019, I shared a blog about Microservices Antipatterns. This blog is about DevOops, the “DON’Ts” of DevOps or you can say “DevOps antipatterns”. In other words, it is about avoiding common mistakes that most of us could commit in the DevOps voyage. If you are a member of one of the cross-functional teams mentioned above or someone planning to adopt and nurture DevOps best practices, then this blog is for you. So, what are the most common don’ts that I am talking about?
1. Implementing DevOps in the Dev only
To implement DevOps successfully, you must minimize the rift between product owners, Dev, Test, and Ops teams. Unfortunately, some of us give more importance to the development in the process of instilling DevOps. It is of utmost importance to understand that you won’t be able to reap the benefits of DevOps unless all these individual contributors and teams collaborate at all levels.
2. Implementing DevOps in the Ops only
Yes, this is equally true for organizations that believe in their operations teams more because they get production to drive the revenue. Again, these organizations need to understand that DevOps is all about collaborative efforts. None of the Dev, Test, or Ops teams can do it all by themselves.
3. Simply starting somewhere
Well, that’s not how it works. Change is the essence of life but it is important to know where to apply these changes. Adopting DevOps for greenfield projects will always be easier as compared to brownfield projects. You can start with fresh codebases and processes of your choice. Plus, the teams would be more open to new practices than the already set up practices. With greenfield projects, you are always at the risk of …read more
