DevOps: roles and processes
It is not a set of notions, not really: DevOps is an approach, a mindset. But which roles are involved in the process and should know about it? Let’s see it in this article.
DevOps Engineer? Not really
It often happens, especially in the last period, to read on LinkedIn about professionals who qualify themselves as DevOps-something. It is not wrong in itself, it can surely make sense.
But, as I have already explained in this article, DevOps is not a title: the meaning that can be given to a figure like this is that that person has a role, Engineer for example, within a DevOps process.
Right, because several professionals enter and collaborate in those practices that lead to a fair process within the company. They are professionals that know well the Lean and Agile methodologies and the Toyota Way, and have a range of useful skills to carry out this workflow.
Which companies adopt DevOps
DevOps methodology is difficult to apply when confronted with certain types of companies, structured in a rigid and hierarchical manner.
In fact, in a company with a silo-mentality, where workers are compartmentalized, it is structurally impossible to carry out a process of this kind. Precisely, we remind you that the DevOps approach focuses on the team, that needs to be cross-functional, and on a shared goal, achievable only through a shared method. Virtually everything that is lacking in those businesses designed for separation and not for union, where teams are uniform and each have a different purpose and approach, completely detached from the others.
The same goes for those who adopt a Waterfall model, which provides for a trend in consequential and linear steps, where there is no room for the centrality of the user and his feedback - if not at the end of the process - or for a slow and continuous increase. Also, there is no room for Continuous Delivery and, consequently, for Continuous Improvement, which is another distinctive feature of DevOps.
Which teams, then, and which professionals can put this method into practice?
Very simple, Agile Teams, those with a single general rule: collaboration of multiple different roles, shared goal and method.
The professional figures in the DevOps process
Who is inside these Agile Teams and therefore needs to know the DevOps practices and approach?
Product Owner - Business Owner
This is a central figure within the process.
DevOps must be PO’s daily bread, he needs to know the product that is being built and the system in which it is in. He needs to work on analysis and planning: knowing the method and the workflow allows him/her to determine how to scale or also identify what may not be working.
Specifically, a PO does not necessarily need to have technical expertise: what matters is that he/she has an overall view and that is able to facilitate the team and work together to reach the goal.
This expert is the heart of the DevOps process. Why?
Simple, he has three big macro-responsabilities.
- The product that he develops shall be capable of being reproducible in multiple contexts, on different platforms.
- He needs to write code that stays editable in the future as well: in this respect, he’ll produce code via Git and implement a best practice of Continuous Integration.
- His code should not have flaws. For this reason he will follow a TDD approach, he will be guided in his work by automated tests.
As you can see, a developer must have some theoretical and concrete knowledge, but what is most important is the mindset, a working method that is inspired by the core principles of DevOps.
DevOps is often associated with the system administrator. Wrong!
This figure is the one that handles the system aspect, server and all that. His contribution is determinant, because he is the one who keeps it all stable.
His role in the DevOps process is just one: he is responsible for the efficient running of the software on the system.
QA - Quality Assurance
In 20tab we have introduced this figure for a few months now, extremely crucial for the DevOps approach: Quality Assurance, the tester has the task of verifying that the product passes the acceptance tests.
These tests are nothing “technical”, they confirm that the initial requirements are being met and the digital product is ready to land in the final user’s hands. Please note, the QA tester does not give subjective judgements but relies on the technical characteristics and the absence of bugs or usability issues.
Imagine this procedure:
- the client works in close contact with the Product Owner, that analyzes and design the product;
- System administrators and Devs build the software;
- the QA makes sure that everything that was designed during the first step has been respected.
It is the last step back to the client, the final piece that enables us to give back a digital product in line with the requests and expectations of the users.
Expertise or mindset?
As you have discovered, the DevOps process is a collective and synergistic journey, in which everyone gives value and works for a final goal. To reach and fulfil.
The expertise of each professional is the basis for a new mindset that will surely increase the quality of our products, making them more stimulating.
Would you like to learn more about the stages of the process and get into the 20tab model? Take a look here!