Si votre entreprise vient tout juste d’introduire des outils DevOps ou CI/CD, il peut être utile que vous vous familiarisiez avec les erreurs les plus courantes afin de ne pas les répéter et de ne pas empiéter sur le râteau de quelqu’un d’autre.
Équipe traduit l'article .
Manque de préparation à changer de culture et de processus
Si vous regardez le diagramme cyclique , il est clair que dans les pratiques DevOps, les tests sont une activité continue, un élément fondamental de chaque déploiement.
Graphique du cycle infini DevOps
Les tests et l'assurance qualité pendant le développement et la livraison sont une partie essentielle de tout ce que font les développeurs. Cela nécessite un changement de mentalité pour intégrer les tests dans chaque tâche.
Les tests font désormais partie du travail quotidien de chaque membre de l’équipe. La transition vers des tests constants n’est pas facile, vous devez vous y préparer.
Manque de retour
L'efficacité du DevOps dépend d'un feedback constant. L’amélioration continue est impossible s’il n’y a pas de place pour la collaboration et la communication.
Les entreprises qui n'organisent pas de réunions rétrospectives ont du mal à mettre en œuvre une culture de feedback continu en CI/CD. Des réunions rétrospectives ont lieu à la fin de chaque itération, au cours desquelles les membres de l'équipe discutent de ce qui s'est bien passé et de ce qui s'est mal passé. Les réunions rétrospectives sont le fondement de Scrum/Agile, mais elles sont également nécessaires pour DevOps.
En effet, les réunions rétrospectives inculquent l'habitude d'échanger des commentaires et des opinions. L’un des points les plus importants au départ est d’organiser des rétro-réunions récurrentes afin qu’elles deviennent compréhensibles et familières à toute l’équipe.
Lorsqu'il s'agit de qualité logicielle, tous les membres de l'équipe sont responsables de sa maintenance. Par exemple, les développeurs peuvent écrire des tests unitaires et également écrire du code en gardant à l'esprit la testabilité, contribuant ainsi à réduire les risques dès le départ.
Une façon simple de refléter le changement dans la façon de penser les tests consiste à appeler les testeurs non pas QA, mais testeur de logiciels ou ingénieur qualité. Ce changement peut paraître trop simple voire stupide. Mais qualifier quelqu'un de « responsable de l'assurance qualité des logiciels » donne une fausse idée de qui est responsable de la qualité du produit. Dans les pratiques Agile, CI/CD et DevOps, chacun est responsable de la qualité des logiciels.
Un autre point important est de comprendre ce que la qualité signifie pour l’ensemble de l’équipe et chacun de ses membres, l’organisation et les parties prenantes.
Incompréhension de l'achèvement de l'étape
Si la qualité est un processus continu et général, une compréhension commune de l’achèvement des étapes est nécessaire. Comment savoir quand une étape est terminée ? Que se passe-t-il lorsqu'une étape est marquée comme terminée sur un Trello ou un autre tableau Kanban ?
La Définition du Terminé (DoD) est un outil puissant dans le contexte de CD DevOps/CI. Cela aide à mieux comprendre les normes de qualité de ce que l’équipe construit et comment.
L'équipe de développement doit décider ce que signifie « Terminé ». Ils doivent s’asseoir et dresser une liste des caractéristiques qui doivent être remplies à chaque étape pour qu’elle soit considérée comme complète.
Le DoD rend le processus plus transparent et facilite la mise en œuvre de CI/CD s'il est compris par tous les membres de l'équipe et convenu d'un commun accord.
Manque d'objectifs réalistes et clairement définis
C’est l’un des conseils les plus fréquemment cités, mais il mérite d’être répété. Pour réussir toute entreprise majeure, y compris CI/CD ou DevOps, vous devez définir des objectifs réalistes et mesurer les performances par rapport à eux. Qu’essayez-vous de réaliser avec CI/CD ? Cela permet-il des versions plus rapides et de meilleure qualité ?
Tout objectif fixé doit non seulement être transparent et réaliste, mais également être cohérent avec les 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 plus rapidement s’il n’y a aucun avantage supplémentaire pour les utilisateurs.
De plus, vous n'avez pas toujours besoin d'implémenter à la fois CD et CI. Par exemple, les entreprises hautement réglementées telles que les banques et les cliniques médicales ne peuvent travailler qu'avec CI.
CI constitue un bon point de départ pour toute entreprise mettant en œuvre DevOps. Lorsqu’elle est mise en œuvre, les approches des entreprises en matière de livraison de logiciels changent considérablement. Une fois l’IC maîtrisé, vous pouvez penser à améliorer l’ensemble du processus, à augmenter la vitesse de déploiement et à d’autres changements.
Pour de nombreuses organisations, la CI seule suffit, et la CD ne doit être mise en œuvre que si elle ajoute de la valeur.
Manque de tableaux de bord et de mesures 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 son développement, il convient d'évaluer les paramètres qui seront surveillés.
Différents rapports et applications sont utiles pour différents membres de l'équipe. Le Scrum Master s'intéresse davantage au statut et à la portée. Tandis que la haute direction peut s'intéresser au taux d'épuisement professionnel 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 tout correctement ou s'il y a une erreur. Le rouge signifie que vous devez faire attention à ce qui se passe.
Cependant, si les tableaux de bord ne sont pas standardisés, ils peuvent être trompeurs. Analysez les données dont tout le monde a besoin, puis créez une description standardisée de ce que cela signifie. Découvrez ce qui a le plus de sens pour les parties prenantes : des graphiques, du texte ou des chiffres.
Pas de tests manuels
L'automatisation des tests jette les bases d'un bon pipeline CI/CD. Mais les tests automatisés à toutes les étapes ne signifient pas que vous ne devez pas effectuer de tests manuels.
Pour créer un pipeline CI/CD efficace, vous avez également besoin de tests manuels. Il y aura toujours certains aspects des tests qui nécessiteront une analyse humaine.
Cela vaut la peine d'envisager d'intégrer des efforts de tests manuels dans votre pipeline. Une fois le test manuel de certains cas de test terminé, vous pouvez passer à la phase de déploiement.
N'essayez pas d'améliorer les tests
Un pipeline CI/CD efficace nécessite l'accès aux bons outils, qu'il s'agisse de gestion ou d'intégration de tests et de surveillance continue.
Créer une culture forte et axée sur la qualité vise à , en surveillant les interactions avec les clients après le déploiement et en suivant les améliorations.
Voici quelques conseils pratiques que vous pouvez facilement mettre en œuvre :
- Assurez-vous que vos tests sont faciles à écrire et suffisamment flexibles pour ne pas se briser lorsque vous refactorisez le code.
- Les équipes de développement doivent être incluses dans le processus de test - consultez une liste des problèmes et des demandes des utilisateurs qu'il est important de tester pendant les pipelines CI.
- Vous ne disposez peut-être pas d'une couverture complète des tests, mais assurez-vous toujours que les flux importants pour l'UX et l'expérience client sont testés.
Dernier point mais non le moindre
La transition vers le CI/CD s'effectue généralement de bas en haut, mais en fin de compte, il s'agit d'une transformation qui nécessite l'adhésion des dirigeants, du temps et des ressources de la part de l'entreprise. Après tout, le CI/CD est un ensemble de compétences, de processus, d’outils et de restructuration culturelle ; de tels changements ne peuvent être mis en œuvre que systématiquement.
Quoi d'autre à lire sur le sujet:
- .
- .
- .
Source: habr.com