Tout au long de ma carrière de consultant informatique, en travaillant avec diverses plateformes et technologies, j’ai rencontré une myriade de termes qu’on me proposait pour expliquer comment leur entreprise abordait le développement logiciel moderne. Des termes comme Agile, DevOps, SAFe, entre autres.
Tous s’accompagnent d’un groupe fervent de défenseurs prêts à monter au créneau pour les défendre face au moindre scepticisme. Pour ma part, je ne suis ni pour ni contre aucun de ces termes. Si quelque chose fonctionne pour une organisation, tant mieux. En cherchant à reproduire cette réussite, de nombreuses entreprises tombent dans le piège d’une solution surmédiatisée, présentée comme un nouveau modèle auquel chacun doit se conformer pour réussir.
L’important, pour les entreprises, est de comprendre que DevOps n’est pas une solution universelle adaptée à toutes les entreprises. J’ai l’impression que si un précurseur comme Google, Facebook ou Microsoft décide de faire quelque chose, tout le monde doit forcément faire de même.
Ajoutez à cela la pression supplémentaire qui pousse à se prendre trop au sérieux – jusqu’à devenir quelque peu draconien – et vous obtenez un nouvel appât jeté dans l’étang pour des gens comme moi, généralement très cyniques après avoir mené tant de projets informatiques.
Pourquoi « DevOops » ?
Quand je demande aux entreprises où elles en sont dans leur maturité DevOps, la réponse que j’obtiens généralement ressemble à ceci : « Nous sommes en train d’y arriver. » On pourrait en dire autant des entreprises en matière de tests de performance continus : cela signifie généralement qu’elles font quelque chose, sans encore avoir tout à fait trouvé la bonne méthode.
C’est ce qui m’amène à qualifier désormais la plupart des initiatives DevOps actuelles de « DevOops » – autrement dit, une tentative mal orientée de mettre en place DevOps. La plupart des dirigeants et des entreprises cherchent constamment la dernière nouveauté, tendance ou expression à la mode pour accélérer l’innovation, gagner du temps et de l’argent et prendre l’avantage sur leurs concurrents. Ces dernières années, DevOps a été l’une des expressions à la mode les plus en vogue dans les entreprises du monde entier.
En définitive, l’un des principaux facteurs qui poussent les entreprises à adopter un modèle Agile ou DevOps est le F.O.M.O. (la peur de passer à côté). Les entreprises tentent ainsi d’adopter les pratiques DevOps simplement pour rester dans la course.
Cela finit par causer davantage de problèmes dans le processus de développement logiciel que leur ancienne approche traditionnelle. Cela ne signifie pas que votre modèle traditionnel représente l’avenir de votre entreprise. Vous devez vous assurer d’être prêt pour ce type de modèle.
L’imitation est la forme de flatterie la plus sincère… ou pas ?
Lorsque les entreprises imitent leurs concurrentes, elles cherchent à suivre le rythme de la concurrence et à rester pertinentes. Souvent, elles le font sans prendre le temps de déterminer quelle est la meilleure manière de mettre en œuvre un modèle DevOps pour elles – ni même si elles ont réellement besoin de pratiques DevOps. Si votre objectif principal est d’ajouter de la vitesse pour la vitesse, vous allez droit à la catastrophe (ou, dans ce cas, à des problèmes de développement produit).
En matière de tests de performance, privilégier la vitesse au détriment de la performance ne résout pas le problème. Les entreprises me demandent souvent s’il faut intégrer chaque test d’API ou test de performance de bout en bout dans un pipeline CI afin de recueillir des métriques de durée, et elles veulent le faire aussi rapidement que possible.
Cependant, les conséquences sont généralement que les métriques ne sont pas valides, qu’elles ne contribuent pas à résoudre les problèmes de performance et qu’elles deviennent une « activité de validation de case à cocher ». Vous vous demandez pourquoi ces métriques ne sont pas valides ? Parce que les données recueillies n’apportent pas de réelle valeur à leur public (c’est-à-dire les développeurs), qui finit par les négliger ou les considérer comme non pertinentes.
Pendant ce temps, les problèmes de performance déjà rencontrés par les entreprises continuent d’être détectés trop tard. Il s’agit généralement d’une panne en production ou d’un problème d’expérience client signalé dans un ticket de support qu’il faut ensuite traiter. L’automatisation n’a pas résolu le problème. La vitesse d’exécution des tests dans le pipeline CI ne l’a pas résolu non plus. Les maux de tête sont toujours là.
Mais attendez, il y a une lueur d’espoir !
D’après mon expérience, trois éléments m’indiquent qu’une entreprise a correctement mis en œuvre un modèle ou une stratégie DevOps ;
- La virtualisation des services (ou son équivalent) a été mise en œuvre : Cela leur permet de tester des fonctionnalités et des services inachevés sans devoir attendre la fin du développement. Si elles ne peuvent pas travailler à l’automatisation des tests pour les fonctions opérationnelles tandis que d’autres n’ont pas encore été créées, elles prendront du retard en matière d’automatisation, et les tests seront toujours à la traîne.
- La mise en production est découplée de l’accès des utilisateurs aux nouvelles fonctionnalités : Cela signifie qu’elles déploient silencieusement le code afin de permettre aux utilisateurs finaux d’y accéder au rythme choisi, par exemple via des groupes pilotes. Si un déploiement sème la pagaille, elles peuvent rapidement revenir à la version précédente grâce aux indicateurs de fonctionnalités.
- L’automatisation des tâches répétitives : Elles cherchent constamment à réduire les tâches laborieuses dans l’environnement de travail en automatisant les tâches répétitives, tout en veillant à maintenir des revues manuelles, même en cas d’exceptions aux critères standard de réussite ou d’échec. Tout n’est pas toujours aussi tranché – réussi ou échoué. Une bonne organisation DevOps sait trouver l’équilibre entre la réduction des tâches laborieuses et la vitesse irréfléchie des pipelines.
En définitive, la solution aux problèmes qui affectent les initiatives de test de performance d’une entreprise dépendra du type de résultat qu’elle espère tirer de ses tests. Si vous cherchez à obtenir des résultats de tests de performance fiables, qui permettront à votre entreprise de prendre des décisions éclairées en toute confiance, ne cherchez pas plus loin que l’expérience de l’utilisateur final.
Un DevOps tourné vers l’avenir
À l’heure actuelle, l’adoption de DevOps se trouve toujours dans la phase du « cycle du battage médiatique », ou dans la zone que Gartner appelle le « pic des attentes exagérées ». Résultat : de nombreux efforts ne sont pas entièrement sérieux dans leur démarche DevOps et rejettent les principes fondamentaux qui permettent à DevOps de fonctionner parce qu’ils sont difficiles à appliquer.
Au cours des cinq prochaines années, l’engouement pour DevOps ret retombera, car les entreprises feront monter leurs employés en compétences et exigeront des nouvelles recrues les compétences nécessaires aux Site Reliability Engineers. À ce stade, les entreprises comprendront comment en tirer la valeur adéquate, et certaines découvriront qu’elles peuvent obtenir de meilleurs résultats sans DevOps.
À propos de l’auteur :
Scott Moore, Director, Customer Engineering, Tricentis