Les bonnes raisons de passer de DevOps à DevTestOps

Article

Mon premier n’est ni vraiment une organisation, ni une suite de process, ni un outillage mais un peu tout cela à la fois. Mon tout vise à dépasser les clivages habituels d’une Direction des Systèmes d’Information tout en conciliant les enjeux Métiers avec ceux des équipes IT. Qui suis-je ?
Tout le monde aura ici reconnu le DevOps. Le sujet a beau générer des centaines de tweets chaque jour (si, si…), il n’en reste pas moins source de confusion. À tel point que l’InnovationLab de Nexworld a opté pour la qualification d’un autre modèle (pas concurrent bien évidemment mais complémentaire), le DevTestOps.

Tout le monde aura ici reconnu le DevOps. Le sujet a beau générer des centaines de tweets chaque jour (si, si…), il n’en reste pas moins source de confusion. À tel point que l’InnovationLab de Nexworld a opté pour la qualification d’un autre modèle (pas concurrent bien évidemment mais complémentaire), le DevTestOps.

Explications :

Entre des métiers challengés au quotidien par la nouvelle donne de la transformation numérique, des équipes projets pressés de construire de nouvelles applications et des exploitants soucieux de préserver la disponibilité et la stabilité des services, le SI se retrouve inévitablement sous tension. DevOps est arrivé à point nommé pour baisser cette tension de la même manière que l’on soulève la soupape d’une marmite qui commence à siffler.
Il faut avouer que les symptômes de cette tension se multipliaient : retards dans les développements, livraisons approximatives, phases de recette longues et coûteuses, communication difficile (euphémisme) entre les équipes, plannings et budgets difficiles à maîtriser. Dans ce contexte, les promesses initiales de DevOps ne pouvaient que capter l’attention. Comment ne pas s’intéresser à une démarche qui propose de prendre en compte rapidement les nouveaux besoins, de fluidifier les développements et les livraisons ? Sauf, que dans l’enthousiasme et l’empressement ambiants, des raccourcis malheureux se sont glissés dans l’esprit DevOps.
Nous pouvons en compter au moins 3 :

Malentendu #1 : La plateforme d’intégration continue (PIC) couvre le cycle DevOps

Pas de DevOps sans une « PIC ». Autrement dit, sans une plateforme pour versionner, compiler, packager et tester de manière continue et industrialisée. Problème : cette PIC a rapidement été considérée comme la plateforme globale du cycle DevOps. Un premier raccourci dommageable car le rôle principal de la PIC est de soutenir l’industrialisation des développements et des tests unitaires.
Assez logiquement, les développeurs se sont donc appropriés la PIC pour la réserver à leur usage exclusif. Autrement dit, elle ne couvre que la première partie seulement du cycle DevOps et s’adresse exclusivement aux développeurs.

Malentendu #2 : L’amélioration continue se joue dans une étape spécifique du cycle

Prise au pied de la lettre, la démarche DevOps conduit à enchaîner des cycles sur un rythme soutenu et à traiter l’ensemble des dysfonctionnements (fonctionnels, techniques, Architecturaux) lors d’une phase dédiée. Dans la pratique, jouer l’amélioration continue lors d’une telle phase spécifique du cycle DevOps se fait au détriment de la qualité. Impossible en effet de parvenir à un code de qualité si les tests et la recette ne sont pas traités de manière distincte. Pour analyser le sujet de manière complète, il faudrait d’ailleurs différencier :
  • Les tests unitaires
  • Les tests d’intégration
  • Les tests fonctionnels
  • Les tests de sécurité
  • Les tests de qualimétrie
  • Les tests de performance
  • Les tests d’exploitabilité

Si les premiers (les tests unitaires) relèvent bien de la responsabilité des développeurs et prennent place dans le cadre de la PIC, les autres sont dans les mains des Métiers, des exploitants et d’autres acteurs de la DSI. Pour être menés de manière qualitative, les tests d’intégration comme la recette utilisateur appellent donc des activités distinctes qui se jouent à différentes étapes du cycle DevOps et non dans une étape unique.

Malentendu #3 : Livraisons et déploiements s’enchainent sur un même rythme

Dans le langage DevOps, livraison continue et déploiement continu sont souvent évoqués de concert comme s’ils étaient synchrones. Là aussi, dans la pratique, ce n’est pas le cas. De la livraison au déploiement, un phasing s’impose et requiert de saines interruptions afin que chacun (développeurs, Métiers et exploitants) puisse exercer ses propres contrôles.

Voilà pourquoi, face à ces malentendus assez courants sur le terrain, plutôt que le DevOps, nous préférons évoquer (et pratiquer) une approche DevTestOps. Et substituer à la vision DevOps traditionnelle une approche qui considère l’amélioration continue comme une préoccupation transverse. Contrairement à la vue cyclique habituelle, finalement contraignante, le DevTestOps propose de contribuer à l’amélioration continue dans chaque étape du cycle. Avec des gains bien tangibles pour la qualité des projets mais aussi pour leur sécurité – nous y reviendrons très prochainement.

Auteur