DevOps : quel avenir pour l’automatisation de la production ?

Les grandes entreprises, et en premier lieu les opérateurs télécoms dans le début des années 2000, ont compris que la notion de "time to market" était essentielle pour attirer de nouveaux clients et élargir les parts de marché acquises.

• Intégration continue : pour fournir automatiquement les nouvelles versions sur les plateformes de test.

• Livraison en continu : livraison automatique sur les plateformes de pré-production.

• DevOps : étape ultime qui permet de livrer en automatique directement en production.

 

Dans la littérature, principalement sur internet, nous trouvons 2 définitions courantes du DevOps. Une définition orientée processus de développement et de livraison : Ensemble de compétences, d’outils et de processus dont l’objectif est de réduire les délais entre l’expression du besoin et la mise à disposition de la solution logicielle.Une définition plus limitée aux techniques d’automatisation des tâches Automatisation des tâches de préparation du livrable, de sa validation et de sa mise en production.

On constate cependant que la deuxième définition prédomine, et que la mise en place d’outils occupe une place prédominante dans l’esprit des directions informatiques. Pour automatiser les processus de déploiement, il est nécessaire d’intégrer dans l’équipe Agile, des compétences qui sont généralement disponibles dans les équipes de production et d’exploitation.

L’agilité a supprimé la frontière entre la "maîtrise d’ouvrage" et la "maîtrise d’œuvre". Le DevOps a pour objectif de supprimer la frontière entre la "fabrication" et "l’exploitation". La principale difficulté consiste à faire travailler des équipes qui ont des logiques de fonctionnement très différentes :

• Le Dev travaille sur le besoin, sur le développement de la solution. Il valorise la créativité et l’innovation.

• L’Ops travaille sur le service rendu à l’utilisateur. Il valorise le respect des procédures (ITIL), la traçabilité des opérations, et le respect des contrats de services, en termes de disponibilité et de performance.

Mais du point de vue du testeur les questions fondamentales qui se posent sont les suivantes :   

• Qui garantit la qualité du livrable finale, et qui s’assure que les points de contrôle qualité sont bien passés avec succès ?

• Le processus de vérification automatique est-il suffisant pour sécuriser les déploiements automatiques ?

Les questions qui se posent sur le contrôle qualité et l’apport dans des tests dans l’amélioration de la qualité logicielle et la sécurisation des déploiements est souvent associée au modèle de développement appelé Cycle en V, qui propose de faire correspondre chaque étape de la fabrication de la solution logicielle avec une étape de validation par les tests.

Ce modèle est repris par le référentiel ISTQB et depuis longtemps il est considéré comme le modèle qui permet de mieux assurer la qualité du produit final. Du point de vue du testeur certifié ISTQB, l’agilité et le DevOps ne font que raccourcir le cycle, mais les activités restent les mêmes. Elles sont faites plus régulièrement, avec des délais plus courts. Avec cette approche on peut présenter un tableau qui liste les grandes activités d’un projet agile, et proposer en face de chaque activité ce que l’ISTQB recommande comme activité de validation et de vérification.

Activité	ISTQB
Plan	Revue de spécification (User Stories) Testabilité / Cohérence
Code	Tests statiques : revue de code, qualimétrie Tests unitaires
Build	Tests d’intégration
Test	Tests systèmes
Release	Tests d’acceptation
Deploy, Operate	Tests de non-régression

 

Les divergences entre l’ancien modèle et le nouveau modèle ne se posent pas en termes d’activités à faire ou à ne pas faire, mais plutôt à quel moment il est opportun de réaliser l’activité de validation et de vérification, et jusqu’à quel niveau l’automatisation de l’activité est-elle possible ? En effet, à chaque fois qu’une activité de validation est ignorée, par manque de temps ou de conviction, on crée une date qualité, qu’il faudra ensuite gérer et absorber avant la mise en production.

Si la dette qualité s’accumule, la confiance de la qualité du produit final est altérée, et le cycle DevOps est rompu par l’introduction d’une phase de validation pour payer la dette qualité.

En conclusion, je suis convaincu que le vrai enjeu de la transition DevOps est un enjeu qui touche à la culture de gestion du projet.

Ildddfaut passer d’une logique de rattrapage, avec une phase de validation finale, qui sert à combler les lacunes accumulées pendant toute la phase de fabrication, à une logique de gestion de la dette qualité, qui en permanence pose la question du processus de validation, essaye d’anticiper et de positionner cette activité au plus tôt , et surtout laisse le temps à l’équipe projet pour mettre en place une approche préventive, au lieu de fonctionner systématiquement dans un mode curatif. Cette approche est présentée généralement par le modèle "Shift Left", qui incite l’équipe à déplacer l’effort qualité vers la gauche sur l’échelle du temps.