3 ways to kill DevOps secretly
Are you the one who designed and implemented the DevOps for your team? Or you are the one who is looking to learn DevOps and want to see what all technologies you need to learn? No matter who you are, as far as you have implemented or planning to implement DevOps, this blog will give you the cheat sheet for killing the soul of DevOps.
These killing techniques are so subtle that no one will even notice that they are living with a dead DevOps system. If you are witnessing or part of such a DevOps implementation, do let us know in the comments. Without anymore chit-chat, let's jump into the matter.
1. Your Dev/QA/Perf (etc.) teams depends on you for build and deployment in non-prod environment.
This is the best one and I didn't keep it for last. If to deploy in QA environment or to propagate in UAT environment, the teams needs you, you have killed the DevOps. Hold on, it can be even more brutal killing of DevOps if there is ticket based system in place i.e. team needs to raise a service ticket to let you know that there is an action needed. If you have the ticket based DevOps in place, congrats, you are at pro level.
Where did you stab?
DevOps is about increasing the speed, without compromising the security. If there is a dependency, then certainly its hampering the speed. If there is a ticket to build and deploy, more time is going to be wasted. If you think giving control to the team can be risky, reduce the risk by giving the control to limited set of people.
2. Your DevOps responsibilities ended after creating CI/CD pipelines.
This the most subtle one. No one will ever doubt that you killed the DevOps. Rather they might thank you for your work. I am excluding the tasks which are about the environment issues like firewall issues, server unavailability, etc. I am sure you are taking care of them, if they fall in your scope. Yet, if you never had a conversation with your Dev/QA/Perf/Data/Managers teams to know how you can make their life easier from the perspective of application delivery, then certainly you killed the DevOps in a very subtle way.
Where did you push?
DevOps is about moving the application to production with higher speed, higher quality and with lower overheads. CI/CD pipelines certainly play the major role but that's not all. You can help various teams but suggesting more efficient ways or by providing them required automation to do their work faster with fewer errors and hence saving a lot of time. Examples? How is the DB DDLs/DMLs are moving? How is the data load happening? How do you enable the DB team to ensure that Dev (or other) team is connecting to right schema? How can you make the code promotion more effective and faster?
3. It's only you (or your team), who knows it all and rest of the team depends on you for information.
Keep all the information with you and be the critical part of the system - is one way to kill the DevOps. If your manager, if, needs to know which version of the application is deployed in which environment and s/he needs to email/call/ping you to get this information, or if the application tech lead needs you to tell him who did the last deployment in a given environment or if someone needs you to tell that the version deployed in x environment is coming from which commit id in Git, then you have silently choked the DevOps to death and no one heard anything and mostly, they would never know.
How did you choke?
One important aspect of DevOps is breaking the silos. Breaking the silos does not only mean that developer can do the operations work. It's also about having the knowledge accessible to all. No one need to be expert to know the simple things of their need. A simple dashboard can give them the information they are looking for. You kept everything hidden, and they must come to you. You maintained the silos perfectly and hence you killed the DevOps.
These are very common symptoms of DevOps implementation. This is only because of the way we perceive the whole concept of DevOps. We are too much tool and process oriented that we forget the most humane reason for doing the DevOps. We need to change our outlook towards DevOps. If time permits, have look at the benefits of using DFD approach for implementing DevOps.
Let's do more meaningful DevOps and make it's purpose be fulfilled.
Join us on LinkedIn