Vous avez dit DevOps ?

Les DevOps tel qu’il est (souvent) mal perçu

On parle régulièrement de DevOps. Ce mot est devenu un mot « valise » derrière lequel on met beaucoup de choses toutes plus merveilleuses les unes que les autres.

Le plus souvent ce qui est « sous-entendu » par DevOps est une chaîne d’intégration continue, une automatisation à 100% de la chaîne de déploiement permettant de mettre en production toute modification en seulement quelques secondes!

D’un point de vue testeur certains imaginent également que DevOps va vouloir dire des tests 100% automatisés n’ayant pas besoin de l’homme pour être efficace. Pour cela on irait avec une automatisation des tests d’acceptation, de la régression… et même de la conception des tests… grâce à un IA ultra performante.

Mais le DevOps c’est loin d’être ça tout en étant bien plus!

En effet, le mythe des tests exécutés en quelques secondes permettant d’avoir la nouvelle version en production nécessite trop de contraintes techniques (dans la quasi totalité des contextes) pour être vraiment mis en place. En effet « en quelques secondes » nécessite d’avoir accès à la production très facilement (ce qui peut être le cas en web mais pas sur d’autres supports comme les mobiles), des campagnes de test ultra rapides et donc la possibilité d’avoir des tests unitairement très rapides et de les paralléliser un maximum (si on veut garder un niveau de qualité suffisant).

De même le mythe du tout automatisé ne fonctionne pas. La conception des tests doit se faire! Certes le shift left fonctionne mais cela n’exclut pas des vérifications manuelles à travers du test exploratoire et de l’acceptation avant le déploiement… Dans le cas où l’on souhaite aller directement en production il reste possible de faire du test en production et dans ce cas il peut être intéressant de faire du canary testing… mais dans ce cas le déploiement n’est que partiel.

Bref même si certaines « idées reçues » très axée sur des outils et des techniques du DevOps ne sont en fait pas réalisées voir réalisable in n’en reste pas mois que le DevOps est bien plus que de la simple technique!

Le DevOps c’est avant tout de l’humain

Au delà de technique et des outils qui restent un des piliers du DevOps cette dernière n’est pas suffisante. Les 4 piliers de DevOps sont:

  • La culture: une culture de partage, d’échange, d’apprentissage, d’échec et d’apprentissage
  • Le produit au plus juste: s’axer sur le développement de valeur
  • L’architecture: pour pouvoir faire évoluer le produit facilement et petit à petit
  • La technologie: l’utilisation des bons outils et l’accès aux environnement techniques adéquates

La culture et le produit sont des facteurs essentiellement humain. La culture dépend des personnes dans les équipes et de leur état d’esprits. De nombreuses initiatives Devops échouent à cause de ce point (c’est d’ailleurs également le cas avec les transformation Agile). De même proposer un produit au plus juste nécessite des démarches de shift left avec, par exemple, du BDD mais aussi de petits incrément dont on peut voir les impacts… avec du shift right ou du test en production.

De même, l’architecture doit être pensée, souvent fonctionnellement, afin de pouvoir bien découper le produit et limiter les impacts.

Au final, la technologie et les outils ne sont qu’un support permettant la réalisation de ce qui a été imaginé par les personnes. Les outils sont au service du DevOps et ne sont donc pas le DevOps!

D’ailleurs, quand on pousse la réflexion plus loin on peut arriver à la conclusion que le DevOps c’est en fait de l’Agile!

Le DevOps, la continuité de l’Agile mis en place dans nos équipes

La culture/philosophie DevOps s’appuie énormément sur l’Agile, son manifeste et ses principes. De même le DevOps requiert régulièrement de « casser les silos » souvent présents entre les équipes de développement (en Agile) et la production. Il est étonnant de voir que notre manière de faire de l’Agile ait laissé ce fossé entre le développement et la production.

En effet l’Agile doit livrer de petits incréments/nouvelles versions du produit régulièrement. Cette nouvelle version n’a de sens que si elle se retrouve en production. Néanmoins, l’Agile le plus fréquemment mis en place actuellement se borne à intégrer tous les acteurs du métier au testeur (en passant par le développeur). La chaîne s’arrête là et on propose des versions qui ne sont pas forcément déployées voir déployable facilement.

Le DevOps (pour Développement et Opérations) propose juste de continuer la démarche Agile initiée par l’Agile mis en place dans les entreprises et livrant réellement des nouvelles version régulièrement. Pour réussir cela le DevOps propose, comme l’Agile, d’avoir des compétences de gestion de la production dans son équipe pluridisciplinaire. L’équipe Agile se retrouve donc à devoir avoir des compétences métiers, de développement, de test et de gestion de la production. Cela se traduit régulièrement par l’introduction d’un spécialiste du sujet dans l’équipe même si ce n’est pas forcément obligatoire.

Conclusion

Le DevOps n’est pas le DevOps fantasmé de l’automatisation. Le DevOps ne va pas (forcément) jusque là mais est en fait bien plus. En effet le DevOps, comme l’Agile, est avant tout un état d’esprit. Une relation entre personne avec une volonté commune de travailler en s’articulant sur des piliers et les valeurs agiles. En ce sens je vois le Devops non pas comme une pratique à part ou un mot valise mais bien comme la suite logique de la mise en place de l’Agile. Le « vrai » Agile n’est, selon moi, atteint que lorsque l’on a mis en place une démarche DevOps fonctionnelle, lorsque l’incrément du produit se retrouve à aller, sans difficulté liée à des silos, en production

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Image présentant les thématiques du RGESN
Qualité durable

Présentation du RGESN 2024: les spécifications (2/9)

Le RGESN, Référentiel Général d’Ecoconception des Services Numériques, est un référentiel qui a pour but de s’assurer une conception des services numériques. Il est, à l’heure actuelle, divisé en 9 thématiques : Dans cet article je vais me concentrer sur la thématique des spécifications. Les autres thématiques ont fait ou feront

Lire la suite »
Agilité

Le test « à distance » en Agile

Jeudi 17 octobre dernier s’est tenue une table ronde particulièrement enrichissante pendant la STLS. Une des questions abordées était « Peut-on faire du test Agile à distance ?« . Pour être honnête j’ai été très surpris des réponses et des différents retours d’expériences positifs sur cette pratique. En effet, jusqu’à maintenant les

Lire la suite »
Agilité

Que devons-nous tester ?

Que devons-nous tester ? Cette question qui semble élémentaire se trouve être une des plus complexes dans le monde de la qualité et du test… tout en étant peut être la plus importante car, mais est-il nécessaire de le rappeler ?, les tests exhaustifs sont impossible. Vous l’aurez reconnu, on

Lire la suite »