Table of Content
Un pipeline de livraison continue gère l’intégration, la livraison et le déploiement continus ; on parle souvent de « pipeline CI/CD ». Le pipeline CI/CD étant un sous-ensemble d’une chaîne d’outils plus vaste qui comprend les tests automatisés et le contrôle des versions, on emploie souvent le terme de « pipeline de livraison continue » pour décrire le système dans son ensemble.
Les pipelines de livraison continue récupèrent le code de l’application à la source (auprès des développeurs) et le livrent aux utilisateurs finaux sous la forme d’une application ou d’un service en ligne. Cependant, la création et la gestion d’un pipeline de livraison continue ne peuvent pas réussir sans une compréhension complète de la façon de gérer les risques qu’il présente. Mais qu’impliquent ces « risques », exactement ? Dans cet article, nous nous intéressons à cinq domaines de risque fondamentaux au sein d’un processus de livraison continue ainsi qu’à leurs causes, conséquences et solutions.
Les 5 risques
1. Automatisation des tests
L’automatisation des tests se trouve à la base de tous les pipelines de livraison modernes et constitue un élément essentiel qui peut faire le succès ou la perte de votre pipeline. Lorsqu’un développeur valide un nouveau code ou une mise à jour du code dans votre système de contrôle des versions (VCS), une série de tests se lance. Les tests automatisés remplissent de nombreuses fonctions, l’une des plus importantes consistant à agir comme un gardien qui évite qu’un code instable, risqué, ou dangereux soit publié et déployé auprès des clients.
Risques
Les plus grands risques associés à l’automatisation des tests ont un certain nombre de causes, comme une part trop importante de travail manuel (pas assez de tests automatisés) ou un nombre trop élevé de tests fonctionnels (et pas assez de tests d’intégration). Les équipes ou organisations qui souhaitent construire et utiliser un pipeline de livraison mais qui dépendent fortement des tests manuels courent le plus grand risque d’échouer. Cela s’explique par le fait que les pratiques de livraison DevOps actuelles mettent l’accent sur un système construit pour être efficace qui déploie les nouvelles versions logicielles le plus vite possible. Les tests manuels sont tout simplement incompatibles avec le DevOps, car ils sont lents, demandent beaucoup de main d’œuvre et génèrent des goulots d’étranglement.
Étant donné que l’écriture de nouveaux tests de A à Z pourrait retarder le lancement de votre processus automatisé, vous pourriez être tenté de réexploiter les tests automatisés existants. Malheureusement, il s’agit de tests unitaires fonctionnels que les développeurs utilisent pour vérifier que ce qu’ils construisent fonctionne. Ils ne sont pas conçus pour tester la façon dont les unités travaillent ensemble ou les aspects opérationnels de l’ensemble du système, comme les appels d’API, les performances et le fonctionnement en réseau. Ces tests doivent être exécutés avant le passage d’un produit en production, et non après.
Résolution
Le meilleur moyen de résoudre les risques associés à l’automatisation des tests est de créer un éventail complet de tests automatisés. Vous devez également créer des tests d’intégration détaillés afin de garantir que le nouveau code peut être intégré au système. Certains ensembles de tests comprennent des tests non fonctionnels qui vérifient les performances, le fonctionnement en réseau, les API externes, les dépendances et la sécurité. Vos ensembles de tests devraient comprendre des tests fonctionnels, mais ceux-ci ne devraient pas être effectués aux dépens des tests opérationnels ou d’intégration.
2. Outils
La qualité de tout processus automatisé dépend de celle des outils sélectionnés. Le processus doit être aussi transparent que possible du point de vue de l’utilisateur.
Risques
Un mauvais choix d’outils risque de donner lieu à une mauvaise expérience utilisateur. Si les utilisateurs estiment que les nouveaux outils alourdissent le processus, ceux qui seront forcés à les utiliser ne les apprécieront pas et se mettront à chercher des alternatives. Peu importe que les problèmes soient concentrés en un seul sous-système ou répartis dans l’ensemble du pipeline : le choix d’un mauvais ensemble d’outils CI/CD qui devient bloquant est un risque que vous devriez éviter à tout prix. Par ailleurs, si certains outils ne sont pas correctement configurés ou intégrés au système, ils entraineront des goulots d’étranglement. Un système qui crée des retards posera problème non seulement au sein d’une société mais également pour ses clients potentiels et existants extérieurs à la société.
Résolution
Une fois le système opérationnel, les risques associés aux outils sont plus difficiles à résoudre. Le meilleur moyen de résoudre ces risques est donc de s’en occuper lors des étapes de planification de votre pipeline. Trouver les bons outils nécessite d’effectuer des recherches approfondies, et toute équipe ou organisation qui n’est pas prête à allouer suffisamment de temps à ce processus de sélection prend déjà des risques superflus. Le nombre d’options disponibles pour tout produit donné est un facteur important à prendre en compte. Un ensemble d’outils qui essaie de couvrir des options trop nombreuses risque de ne pas produire les résultats attendus.
3. Code non versionné
La qualité de la sortie de votre pipeline de livraison dépend de celle de son entrée. En d’autres termes, la qualité de votre projet final dépend fortement de la qualité du code source original. Cela signifie que le contrôle des versions constitue un élément important pour réduire les coûts.
Risques
Si le contrôle des versions n’est pas appliqué et si les développeurs peuvent valider le code comme bon leur semble, ce code ne sera pas testé par vos tests automatisés. Ceci entrainera également de nouveaux problèmes potentiels ainsi que des défauts qui ne seront pas découverts avant les déploiements en production majeurs. Ce problème est souvent accentué lorsqu’une entreprises se retrouve à utiliser plusieurs systèmes de contrôle des versions. Si un développeur choisit de valider du code dans un référentiel qui ne fait pas partie du pipeline de livraison, ce code ne sera pas inclus dans la version finale.
Résolution
Un système de contrôle des versions constitue un élément clé de votre pipeline de livraison continue. Vous pourriez commencer par vous assurer que tous les développeurs valident leur code dans un seul système de contrôle des versions distribué, comme Git. L’instauration du contrôle des versions présente un autre avantage : elle pousse les développeurs dans le pipeline de livraison continue en les encourageant à améliorer la qualité des tests d’intégration automatisés de votre système et à les compléter par des tests supplémentaires si nécessaire.
4. Sécurité
Réduire les risques de sécurité implique de gérer un éventail de risques à la fois techniques et non techniques.
Risques
La construction d’un pipeline de livraison constitue une pratique importante du DevOps. Cependant, les adeptes du DevOps se concentrent sur la gestion des fonctionnalités des applications et sur le processus de construction, de publication et d’intégration logicielle. La plupart d’entre eux ne dispose pas de la formation ou de la motivation nécessaire au traitement de ces problèmes et, comme nous le savons tous, ignorer la sécurité logicielle est une proposition risquée qui se solde toujours par des conséquences tragiques.
L’un des principaux problèmes rencontrés lors de la construction d’un pipeline de livraison automatisé est le risque de donner une plus grande priorité à la commodité et à l’efficacité qu’à la sécurité. Une sécurité logicielle appropriée implique de prêter attention aux actualités, d’être conscient des derniers exploits et de déployer des correctifs. Ce processus peut être épuisant, surtout s’il ne s’agit pas de votre principal domaine d’expertise ou de responsabilité.
Résolution
De nombreux risques de sécurité découlent d’un manque de connaissances, que l’on peut résoudre par l’éducation et la formation. Il est plus facile d’identifier les risques potentiels et de comprendre comment les résoudre lors d’une période de calme que lorsque vous devez en même temps gérer leurs répercussions négatives.
5. Confusion organisationnelle
La réussite de votre pipeline dépend également des personnes de votre entreprise. Malheureusement, les personnes et les processus présentent leurs propres risques, l’un des plus importants étant la confusion associée à la construction et à l’exécution d’un pipeline de livraison.
Risques
Si personne ne sait quelle méthodologie est suivie, ce que celle-ci implique, pourquoi elle est importante, ni ne connait les objectifs et les résultats attendus, le projet est perdu. Si vous construisez un projet sur la base des principes d’Agile et du DevOps, un manque de normes communes associé à une mauvaise définition des conditions du projet généreront de la confusion. Souvent, cela entraine des disputes générales au sujet des définitions et de la façon de les appliquer. Peu importe que vous créiez d’excellents tests automatisés ou que vous ayez les outils parfaits. Votre pipeline de livraison échouera si vous ne créez pas un environnement et une culture organisationnelle qui le soutiennent.
Résolution
Les risques associés à la confusion et au chaos organisationnels peuvent être réduits par la création, la standardisation et l’instauration de directives et de pratiques. Cela implique de standardiser la terminologie et les pratiques pertinentes concernant Agile, le DevOps et le pipeline à travers votre organisation. De meilleurs outils et méthodes de communication peuvent également permettre de réduire ces risques. Il est tout aussi important de vous assurer que l’ensemble des parties prenantes et des membres de l’équipe reçoivent une formation appropriée à Agile et au DevOps.
La livraison continue sans risque
Ces risques ont de nombreuses causes similaires. Il s’agit des processus non gérés, du manque de renseignements exploitables et de données utiles et de l’incapacité à suivre et surveiller les projets dans l’ensemble d’une organisation.
This block renders a quote for the post drawn from the post's custom fields. Modify the quote below the content editor in the Quote fields.
C’est ici qu’un outil tiers peut vous aider à évaluer et à résoudre les cinq risques qui menacent votre pipeline de livraison continue et que nous venons d’évoquer. Avec Release Dynamix [RDx] de Panaya, vous pouvez gérer votre pipeline de livraison continue à partir des chaînes de valeur, projets, portefeuilles, tests et versions. La solution intégrée de Panaya offre des fonctionnalités de collecte de données, de planification, de suivi et de collaboration en temps réel qui permettent d’accélérer vos workflows. Bénéficiez de puissants outils d’analyse et de génération de rapports qui vous aident à prendre des décisions éclairées et à limiter les risques en gérant et en suivant de multiples projets à l’aide des tableaux de bord graphiques et des renseignements exploitables en temps réel de RDx.
Pour les tests de processus métier de bout en bout à travers de grandes entreprises, tirez parti de Panaya Test Dynamix pour éliminer les risques associés au processus de livraison. Grâce à un suivi et une surveillance en temps réel, obtenez des renseignements exploitables à jour concernant les risques et la qualité du projet, gérez les défauts et garantissez une traçabilité complète de l’ensemble des modifications.
La construction d’un pipeline de livraison continue présente de nombreux risques qui peuvent gravement mettre en échec votre pipeline et même le détruire. Les outils fournis par Panaya vous permettent de vous attaquer aux cinq risques abordés dans cet article, ainsi qu’à de nombreux autres risques, et peuvent être utilisés pour soutenir les processus de minimisation des risques, comme la gestion des spécifications, les examens du code et les tests basés sur les risques. Vous disposez ainsi d’une approche réellement intégrée de la gestion des risques pour les pipelines de livraison continue.
