Si votre entreprise vient d'adopter DevOps ou des outils CI/CD, il peut être utile de vous familiariser avec les erreurs les plus courantes pour éviter de les répéter et de trébucher sur les mêmes pièges.
Commande a traduit l'article .
Résistance au changement de culture et de processus
Si l'on regarde le diagramme circulaire , on voit que dans les pratiques DevOps, le test est un travail continu, une partie fondamentale de chaque déploiement.
Diagramme circulaire infini de DevOps
Le test et l'assurance qualité dans le processus de développement et de livraison font partie intégrante de tout ce que font les développeurs. Cela nécessite un changement d'état d'esprit pour intégrer les tests dans chaque tâche.
Le test devient une partie du travail quotidien de chaque membre de l'équipe. Passer à des tests continus n'est pas facile, il faut s'y préparer.
Absence de retours d'information
L'efficacité de DevOps dépend des retours d'information constants. L'amélioration continue est impossible sans un espace pour la collaboration et la communication.
Les entreprises qui n'organisent pas de réunions de rétrospective ont du mal à instaurer une culture de retours d'information continus dans le CI/CD. Les réunions de rétrospective sont tenues à la fin de chaque itération, où les membres de l'équipe discutent de ce qui a bien ou mal fonctionné. Les réunions de rétrospective sont fondamentales pour Scrum/Agile, mais elles sont également nécessaires pour DevOps.
Cela est dû au fait que les réunions de rétrospective inculquent l'habitude d'échanger des retours et des opinions. L'un des points les plus importants au début est d'organiser des réunions de rétrospective récurrentes pour qu'elles deviennent claires et habituelles pour toute l'équipe.
En ce qui concerne la qualité des logiciels, tous les membres de l'équipe sont responsables de son maintien. Par exemple, les développeurs peuvent écrire des tests unitaires ainsi que rédiger du code avec la testabilité à l'esprit, aidant à réduire les risques dès le départ.
L'une des manières simples de refléter le changement de perception concernant les tests est de ne pas appeler les testeurs QA, mais plutôt testeurs de logiciels ou ingénieurs qualité. Ce changement peut sembler trop simple ou même ridicule. Mais si l'on appelle quelqu'un « spécialiste de l'assurance qualité des logiciels », cela donne une vision erronée de qui est responsable de la qualité du produit. Dans les pratiques Agile, CI/CD et DevOps, tout le monde est responsable de la qualité des logiciels.
Un autre point important est de comprendre ce que signifie la qualité pour l'ensemble de l'équipe et pour chaque membre, l'organisation et les parties prenantes.
Mauvaise compréhension de l'achèvement d'une étape
Si la qualité est un processus continu et commun, il faut une compréhension commune de l'achèvement d'une étape. Comment savoir quand une étape est terminée ? Que se passe-t-il lorsque l'étape est marquée comme accomplie sur un tableau Trello ou un autre tableau kanban ?
La définition de la Done (DoD) est un outil puissant dans le contexte du CD DevOps/CI. Elle aide à mieux comprendre les normes de qualité de ce que l'équipe construit et comment.
L'équipe de développement doit déterminer ce que signifie « Fini ». Elle doit s'asseoir et établir une liste de caractéristiques qui doivent être respectées à chaque étape pour qu'elle puisse être considérée comme terminée.
Le DoD rend le processus plus transparent et facilite la mise en œuvre du CI/CD, à condition qu'il soit compris par tous les membres de l'équipe et mutuellement accepté.
Absence d'objectifs réalistes et clairement définis
C'est l'un des conseils les plus souvent cités, mais il mérite d'être répété. Pour réussir toute entreprise sérieuse, y compris la mise en œuvre du CI/CD ou DevOps, il est essentiel de fixer des objectifs réalistes et de mesurer la performance par rapport à ceux-ci. Que cherchez-vous à accomplir avec le CI/CD ? Cela permet-il de publier des versions plus rapidement avec une meilleure qualité ?
Tous les objectifs fixés doivent non seulement être transparents et réalistes, mais aussi correspondre aux activités actuelles de l'entreprise. Par exemple, à quelle fréquence vos clients ont-ils besoin de nouveaux correctifs ou versions ? Il n'est pas nécessaire de surcharger les processus et de publier des versions plus rapidement, s'il n'y a pas d'avantages supplémentaires pour les utilisateurs.
De plus, vous n’avez pas toujours besoin de mettre en œuvre à la fois CD et CI. Par exemple, les entreprises soumises à une forte réglementation, telles que les banques et les cliniques médicales, peuvent ne travailler qu'avec CI.
Le CI constitue un bon point de départ pour toute entreprise adoptant DevOps. Son adoption modifie considérablement les approches de livraison des logiciels dans l’entreprise. Une fois le CI maîtrisé, il devient possible de réfléchir à l'amélioration de l'ensemble du processus, à l'accélération des mises en production, et à d'autres changements.
Pour de nombreuses organisations, un seul CI suffit, et le CD ne doit être mis en œuvre que s'il apporte une valeur ajoutée.
Absence de tableaux de bord et de métriques appropriés
Une fois que vous avez défini vos objectifs, l'équipe de développement peut créer un tableau de bord pour mesurer les KPI. Avant sa conception, il convient d'évaluer les paramètres qui seront suivis.
Différents rapports et applications sont utiles pour différents membres de l'équipe. Les Scrum Masters sont davantage intéressés par l'état et la couverture. Tandis que la direction peut s'intéresser à la vitesse de l'épuisement des spécialistes.
Certaines équipes utilisent également des tableaux de bord avec des indicateurs rouges, jaunes et verts pour évaluer l'état du CI/CD, afin de comprendre si elles font bien les choses ou si une erreur s'est produite. Le rouge signifie qu'il faut prêter attention à ce qui se passe.
Cependant, si les tableaux de bord ne sont pas standardisés, ils peuvent prêter à confusion. Analysez quelles données sont nécessaires pour tous, puis créez une description standardisée de ce qu'elles signifient. Découvrez ce qui a le plus de sens pour les parties prenantes : graphiques, texte ou chiffres.
Absence de tests manuels
L'automatisation des tests jette les bases d'un bon pipeline CI/CD. Mais des tests automatisés à toutes les étapes ne signifient pas que vous ne devez pas effectuer de tests manuels.
Pour construire un pipeline CI/CD efficace, des tests manuels sont également nécessaires. Il y aura toujours certains aspects des tests nécessitant une analyse humaine.
Il est utile de réfléchir à l'intégration des efforts de test manuel dans le pipeline. Une fois les tests manuels de certains cas de test terminés, vous pouvez passer à l'étape de déploiement.
Ne pas essayer d'améliorer les tests
Un pipeline CI/CD efficace nécessite un accès aux bons outils, qu'il s'agisse de gestion des tests ou d'intégration et de surveillance continue.
Créer une culture forte, axée sur la qualité, vise à , surveiller les interactions avec les clients après le déploiement et suivre les améliorations.
Voici quelques conseils pratiques que vous pouvez facilement mettre en œuvre :
- Assurez-vous que les tests sont simples à écrire et suffisamment flexibles pour ne pas casser lors du refactoring du code.
- Les équipes de développement doivent être impliquées dans le processus de test — voir la liste des problèmes et demandes des utilisateurs, qui sont importants à vérifier pendant les pipelines CI.
- Vous n'avez peut-être pas une couverture de tests complète, mais assurez-vous toujours que les flux, qui sont importants pour l'UX et l'interaction avec les clients, sont testés.
Dernier point, mais non des moindres,
La transition vers CI/CD est généralement initiée de bas en haut, mais en fin de compte, c'est une transformation qui nécessite l'engagement de la direction, des investissements en temps et en ressources de la part de l'entreprise. En effet, CI/CD est un ensemble de compétences, de processus, d'outils et un changement culturel, dont la mise en œuvre ne peut se faire que de manière systématique.
Suggestions de lecture supplémentaires:
- .
- .
- .
Source : habr.com
