The field of software development grows and changes quickly. Learning new skills becomes one more of the responsibilities and skills that a worker in computer science must improve. And, just as the specializations available increase, the same happens with the possible job positions. “DevOps” is one of the newest ones, and with it brings a change in business culture.
Historically, each specialization in Information Technologies created its own silo. Developers and Software Architects on one side, Infrastructure on other, DBAs on their own, etc. Thus, knowledge and documentation is rarely shared amongst each team. Even now, most big businesses keep up the barriers between departments, and hold meetings with the excuse of “information exchange”. DevOps was born with the idea of bringing down this artificial blockade, as this barrier benefits no-one in the long run.
The role of DevOps is deeply rooted within the mindset of Agile methodologies. And thus, there is no valid job description without proper context in a specific business culture. Some might consider “DevOps” as a “disposition”, as a way to define work to be done between departments. Others might create a transversal position that collaborates and brings together the different actors.
There are no specific tools of the trade when it comes to daily work. No, allow me to correct myself: documentation is THE weapon of choice. Wiki-style software, or a common documents repository open for everyone involved, allows for an efficient knowledge pool. That is a strong basis to build the foundations of proper cooperation. Orchestrating software, build pipelines, automated tests… All of that is useless without the proper approach to information sharing. Preventing the loss of know-how should be a priority for management, and a critical mission for all DevOps involved.
So, is your company riding this cultural wave, or stuck in the old way of doing?