English | EN 
Sometimes it seems like a competition: We talk about Dev(Test)Ops, Dev(Sec)Ops,… and many other forms. All perspectives are necessary together, because they are all aimed at addressing the same objective: focusing on the activities that are needed to be performed iteratively between Development (Dev) and Operations (Ops) in order to (1) ensure the value and (2) reducing the risk of the delivered software.
We need to consider “All” possible activities to be done in order to ensure what we are going to deploy and deliver, so we need to be capable to perform Dev(All)Ops, but as not everything is possible to be ensured, validated and performed with limited resources and time, we need to instantiate in each project what “All” means for us in terms of increasing value and reducing risk. No name battles are necessary, just understand that we need to take action from different views to be tackled.
Therefore, the Holy Grail of “All” is Quality Assurance (QA), since quality means many different aspects for many different perspectives, and this is why Dev(QA)Ops is the objective. The balance between the “All” different forms that QA adopts for improving the delivered software (functional tests at different levels, performance testing, security testing, monitoring, usability, user experience) is the critical decision to be taken when setting up a DevOps approach in a project. For sure, the development method and the deployment of contributions with technical excellence are a must which are boosted by “All” the QA activities of the Holy Grail that need to be performed (with the necessary roles and automation techniques) and to be orchestrated. What really matters is that Dev to Ops needs Quality Gates and activities to reduce the risk of passing contributions to Ops without checking them from different points of view. And this is the main responsibility of any project, unless someone likes risk and suffering.
When you read about many abbreviations between Dev and Ops, keep the idea simple, and face the complexity of transforming the focus on quality to concrete activities that realize “All” quality objectives and to take actions with an orchestrated view in a DevOps pipeline. If in a project, “All” is equal to “nothing” or “not too much”, the room for improvement is there, while the pain is near… This is when finding the Holy Grail of QA in DevOps becomes an amazing job and a requirement for survival.
