I was in the first week of a new job and the assignment was to install a company software on the local machine. In the beginning, I found that there are some documents on the internal website which I could follow to install. This was a very optimistic expectation of course. As soon as I started reading and doing the steps, I realized that there are many things that are not mentioned in the document and I began to ask a lot of questions that I do not have any answers to. I had to ask the current DevOps engineers for each unclear part. Later, I found that every day I am on a call for hours with these engineers and we achieve bit by bit of this installation together. I would say 20% of the operations were documented and automated, but the rest of the things should be done manually. Finally, I managed to install the software in a week but still, there were many things I did not know how I had done, and forgot many other details that were not in the document.
It turns out every time we have a new hire, this situation happens again and again and there has been no update neither on the document nor in the software installation process. What amazed me was that the DevOps engineers were proud of what they have already created after years but they did not realize that no one can install that software without them. This situation created a huge amount of complexity around the software deployment and takes hours for employees to figure out things again and again. So, no matter how nice all those scripts were, it created a high overhead for the company which was quite hidden for the managers for years.
When it comes to DevOps, usually the first thing you can think of is automation which is true. In fact, by following DevOps practices, you’re going to automate as much as you can, and that’s out of the question, but sometimes people miss out on why DevOps offers to automate and what you will achieve through automation. Additionally, before you automate, you really need to understand the high-level picture of your software architecture and all required operations in detail. So, it is crucial to know your software and the value of automation. Then you might be able to start automating and create a smooth deployment process for your software.
Back to our story, the engineers had the technical knowledge to write and maintain complicated scripts. However, this is not enough to apply DevOps practices. DevOps helps the team create a smooth pipeline in which every team member can work and bring value as fast as possible. What we saw in this story is that there were only a few people within the company who knew how to install the software. This is obviously against DevOps and agile practices in which you are prevented from creating a silo and instead, knowledge will be shared with team members and everyone is responsible.
Some see DevOps only at a technical level, therefore assuming DevOps means automating or infrastructure operations or even scripting. Of course, all of these things are part of DevOps but DevOps has an abstract level in which you can see your software development pipeline from a high-level point of view where you can extract your value stream map. There you can identify where you are doing well and where you are wasting time or having a bottleneck. Knowing this information and having a good understanding of your current way of working is a prerequisite to think about any tool, automation, and improvements. Once you have that high-level view, it will be so much easier to plan, develop, automate and adapt to DevOps practices.