Test Automation et analyse de code source : pourquoi mettre en place un nouveau portail de qualité ?

Par Nick Blamey

Quels enjeux pour les développeurs et pourquoi DevOps est une nécessité – un article de Nick Blamey, directeur des opérations en Europe du Nord chez ARCAD.

L’enjeu business :  La qualité continue des applications dépend de la mise en œuvre de politiques qui imposent une validation immédiate.  Mais les DSI responsables des divers actifs applicatifs manquent de lignes directrices sur la façon dont ils doivent mesurer la qualité du code, ainsi que des ressources à allouer à cette activité.

Qualité Continue (CQ) et DevOps

Les défaillances logicielles augmentent considérablement le coût du développement d’applications. Trouver et corriger les erreurs de production est souvent 100 fois plus coûteux que de les trouver et de les corriger pendant les phases de conception et de codage. Il est essentiel que les équipes intègrent la qualité à toutes les phases du développement logiciel et automatisent autant que possible la vérification de la qualité pour déceler les défauts tôt dans le processus et éviter les efforts répétés. C’est ce que l’on entend par « Qualité Continue » ou CQ, qui constitue aujourd’hui une garantie essentielle – ou une garantie de qualité – dans les cycles de livraison rapides des workflows DevOps et CI/CD.

Quelles sont les techniques disponibles pour la Qualité Continue ?

L’analyse statique du code est la méthode la plus simple et la plus efficace pour prévenir les défauts et sécuriser le code tout en accélérant l’exécution des applications.

L’automatisation de l’analyse du code dès la phase de construction ou d’intégration continue permet à votre équipe de détecter et de corriger les défauts systémiques lorsque le coût de remédiation est à son plus bas. Après l’investissement initial dans la configuration des règles et des métriques, les gains d’efficacité deviennent exponentiels tout au long du cycle de développement.

Pour atteindre une qualité continue, les organisations peuvent employer un certain nombre de stratégies :

• Analyse statique du code source pour identifier les points chauds de complexité, les déviations des normes, les failles de sécurité, etc.
• Examens par les pairs pour vérifier le code afin de s’assurer qu’il répond à des critères précis
• Tests unitaires pour exécuter et examiner les modules individuels, ou unités d’une application, pour en vérifier le bon fonctionnement
• Test de régression pour répéter un ensemble de scénarios de test sur une nouvelle version d’application afin d’identifier tout écart par rapport au fonctionnement normal
• Suivi de l’application en production pour s’assurer de son bon fonctionnement après chaque mise à jour et à tout moment

Pour être efficace dans un environnement DevOps, chacune des techniques ci-dessus doit être à la fois automatisée et continue, intégrée au workflow CI/CQ/CD.

Quelle est l’importance de l’analyse du code source (SCA) pour DevOps ?

Analyse du code source : quelles alternatives ?

Face au défi de l’audit de qualité d’une base de code IBM i existante, les DSI ont un nombre limité de choix :

• Processus complexe d’examen par les pairs : même soutenu par des outils collaboratifs, l’effort manuel d’un examen par les pairs peut être difficile à gérer au sein de grandes équipes possédant un large éventail d’expertise.
• Audit externe du code source par des experts : faute de connaissances applicatives, la courbe d’apprentissage des auditeurs externes est souvent trop longue, ce qui en fait une option coûteuse aux avantages souvent non quantifiables.
• Analyse continue du code source à l’aide d’une solution automatisée conçue spécifiquement pour une base de code IBM i RPG.

Le coût des défaillances dans le développement des applications

Une étude sur la qualité des logiciels réalisée par Capers Jones en 2008 a abouti à deux conclusions très importantes :

• Le  » gaspillage  » du développement et les correctifs de défauts (à partir du code déployé) ont absorbé près des deux tiers de la main-d’œuvre informatique américaine, ne laissant qu’un tiers pour le travail productif sur de nouveaux projets.
• 50 % des budgets des projets de développement de logiciels sont consacrés à la correction de codes de mauvaise qualité ; moins de 6 % des organisations ont mis en place des processus de gestion de logiciels clairement définis ; et les projets logiciels de la taille de 100 000 points fonctionnels échouent à 65%.

Des articles plus récents sur ce sujet suggèrent que pour de nombreuses organisations, les statistiques sont restées pratiquement inchangées aujourd’hui.

Depuis que DevOps est devenu le moteur clé de la plupart des développements, il existe un énorme potentiel d’optimisation pour éliminer les défis décrits ci-dessus et rendre les développeurs plus efficaces dans leur travail en passant plus de temps à coder et moins à réparer les défauts.

Les limites des tests fonctionnels

La plupart des organisations effectuent des tests fonctionnels de leurs applications par le biais de l’interface utilisateur, requis pour des raisons de conformité. Cependant, comme le test de la boîte noire, puisque chaque défaut doit être diagnostiqué à partir de l’interface utilisateur, cette approche n’apporte que peu d’informations pour aider les développeurs à résoudre réellement les problèmes. Le résultat est typiquement un flux constant de défauts classés comme :

• Ne peut pas reproduire le problème
• L’environnement de test n’est pas correctement configuré
• Besoin de plus d’informations

Avec une information médiocre pour les développeurs, les défis sont repoussés en aval. Les projets sont confrontés à des retards dus à une durée de compréhension du code trop longue et à une approche de débogage sous-optimale. Cela limite considérablement la capacité de toute équipe de développement IBM i à maintenir la « vitesse de livraison » nécessaire pour atteindre ses objectifs DevOps.

Analyse du code statique : Qui le fait et pourquoi ?

Il existe 3 approches principales de l’analyse de code statique dans le monde multi-plateforme : Analyse statique pour la sécurité, Analyse statique pour la complexité du code et Analyse statique pour la qualité du code.

De nombreux produits existent pour accomplir cette tâche et le marché est vaste et en expansion avec quelques acteurs dominants. Les solutions sont souvent extrêmement coûteuses et ont tendance à être moins pertinentes sur IBM i qui est moins sensible aux problèmes de sécurité que les autres plateformes.

IBM AppScan Source est le meilleur exemple du leader du marché de la sécurité du code, mais MicroFocus propose également Fortify Security Suite avec un certain nombre d’outils supplémentaires disponibles chez d’autres fournisseurs, tels que CheckMarx, Klocwork, CA Veracode.

En ce qui concerne la complexité des codes, les principaux acteurs sont CAST et McCabe, mais ni l’un ni l’autre n’offre de support pour le RPG sur IBM i.

Pourquoi les développeurs IBM i ont-ils besoin d’une analyse du code source ?

Compte tenu des multiples variantes du RPG et de la longévité des applications, les développeurs d’IBM i font face à un défi unique avec des bases de code Legacy contenant des millions de lignes de code qui ont été maintenues pendant parfois trente ans par des développeurs successifs. Il est laborieux de comprendre la logique du programme et d’évaluer la qualité du code – les ressources sont détournées pour traiter la  » dette technique  » de la base de code. Le défi est d’autant plus grand que les compétences en RPG sont de plus en plus rares sur le marché. La nouvelle syntaxe Free Form RPG a changé le jeu, offrant un moyen d’intégrer une nouvelle génération de développeurs – faisant de la conversion des applications RPGLE en Free Form la « plate-forme brûlante » de notre époque.

L’analyse du code source en tant qu’élément clé de tout « audit de base de code Legacy »

L’analyse du code source peut être réalisée dans le cadre d’un processus plus large de vérification du code source. Des entreprises comme ARCAD ont construit des solutions qui génèrent une vue d’ensemble complète des métadonnées de l’ensemble de la base de code, permettant un niveau d’analyse et de contrôle d’intégrité plus approfondi. Ici, l’analyse du code source est livrée dans le cadre de l’audit du code et les règles et métriques sont utilisées pour faire respecter les standards locaux.

ARCAD CodeChecker peut créer un Code Quality Baseline à partir duquel le RPG Code Base peut être continuellement amélioré par une mesure précise et régulière de la qualité du code. Cela permet aux DSI et aux responsables du développement de montrer aux propriétaires d’applications qu’ils respectent constamment les objectifs d’amélioration continue ISO 27001 de l’organisation au sens large.

Élargissez votre réseau pour prendre en compte les problèmes de qualité du code pour les RPG

Comme décrit plus haut, le RPG est un cas particulier dans le monde du développement. Parmi les outils d’analyse de code source standard, quelques-uns (comme SonarCube) sont capables d’effectuer une simple révision de code RPG et une analyse de qualité statique, mais ils sont très limités dans leur périmètre (par exemple, le manque de support des nombreuses variantes RPG) et le nombre de règles qu’ils peuvent appliquer (limité à environ une trentaine, pour la plupart des règles de documentation du code).

Le risque business potentiel de ces outils limités est le suivant :

• Ils ne sont pas vraiment utilisables pour l’application des lignes directrices sur la qualité des codes, en particulier pour RPG
• Ils ont tendance à créer un certain nombre de faux résultats qui limitent leur efficacité et pourraient en théorie éliminer toute valeur introduite dans le processus d’évaluation par les pairs, en forçant les développeurs à déboguer les problèmes qui sont causés par l’outil lui-même

Les organisations DevOps modernes recherchent maintenant une solution  » industrielle performante  » à ce défi pour s’assurer qu’une implémentation d’un outil d’analyse de code open source ne devienne pas elle-même un goulot d’étranglement dans le workflow DevOps.

Les objectifs de conception d’ARCAD CodeChecker ont donc été de s’adapter aux grandes équipes de développement modernes DevOps orientées IBM i RPG, en se concentrant sur :

• Le balayage rapide de l’ensemble d’une base de code
• L’ auto-ajustement des règles de qualité pour l’application sur une base de code par base de code, étape par étape.
• L’ apport d’une valeur réelle aux développeurs qui effectuent le travail de codage par un feedback rapide de leur travail après chaque édition. (voir la section ci-dessous)
• L’intégration en toute transparence dans une chaîne plus large d’outils ARCAD DevOps, complète et rapide de référencement X et d’audit, de gestion du code source, de création de dépendances, de tests automatiques (avec diagnostic en profondeur des erreurs) et de gestion de l’environnement IBM i LPAR (Déploiement et Release Automation)

Création de valeur rapide pour votre CodeBase avec ARCAD CodeChecker

Gains de productivité grâce à l’analyse du code source et à l’application du Quality Gate

Typiquement, si un développeur sait dans les minutes qui suivent l’écriture du code qu’une directive n’a pas été respectée avec un produit de vérification de code comme ARCAD CodeChecker, il peut résoudre les problèmes immédiatement avec un impact minimal sur la qualité. Si le code est « revu par les pairs », un développeur peut attendre des jours, voire des semaines, avant de recevoir un retour d’information, et il sera passé ensuite à d’autres tâches. La meilleure analogie serait un correcteur grammatical avec traitement de texte, c’est-à-dire que si vous savez immédiatement, en écrivant un texte, que vous avez commis une erreur grammaticale, vous pouvez la corriger immédiatement pendant que la phrase est encore dans votre esprit – comparé au temps qu’il vous faudra pour effectuer une vérification grammaticale 2 semaines après avoir écrit la phrase. Dans ce cas, le rédacteur du texte consacrera 90% du temps de vérification grammaticale et de correction à essayer de comprendre le contexte de ce qu’il a écrit 2 semaines auparavant.

Piloter l’application de la Qualité du Code en offrant une valeur réelle et immédiate aux développeurs

De nombreux outils d’analyse de code source ont une mauvaise réputation. Les DSI et les responsables du développement doivent constamment prendre des décisions en matière de gestion des risques entre : le ralentissement du processus de développement et la pression des dirigeants pour maintenir la fréquence des livraisons ou le risque d’engendrer des dettes techniques qui pourraient causer un risque important à l’avenir si les directives de qualité du code ne sont pas respectées.

CodeChecker d’ARCAD a été conçu pour apporter une valeur ajoutée immédiate directement dans l’espace de travail / bureau du développeur grâce à son intégration avec RDi et SEU. ARCAD a conçu CodeChecker pour répondre aux commentaires réguliers des développeurs RPG « Si vous allez noter mes devoirs, au moins dites-moi comment vous allez juger mon succès ou mon échec ».

En plus de l’optimisation du processus d’évaluation par les pairs grâce à l’analyse statique automatique de la qualité du code, ARCAD CodeChecker peut offrir de la valeur aux développeurs et à vos projets en cours :

• La création et l’application des directives de qualité du code source fournies automatiquement évitent la nécessité d’un examen par les pairs : les développeurs peuvent se concentrer sur le codage plus rapidement que sur l’examen par les pairs.
• La mise en place d’un processus d’analyse du code source pour l’élimination de la dette technique permet à l’équipe IBM i RPG de rester en phase avec les autres équipes de l’organisation dans un monde DevOps.

Combiner l’analyse du code source avec l’automatisation des tests, le contrôle de l’intégrité des bases de données et aider les développeurs à déboguer plus rapidement les problèmes complexes.

Les équipes de développement modernes sont confrontées à ce problème

L’effet de goulot d’étranglement de DevOps à partir de l’analyse, du test, du débogage et du cycle de re-test manuels du code source

Pour faire face à l’accélération des cycles DevOps de quelques versions par an à des versions plus régulières, mensuelles ou même hebdomadaires, les organisations sont amenées à effectuer des tests plus réguliers, normalement fournis par l’automatisation.  Ils sont également poussés à se libérer d’une grande partie des efforts consacrés à la « localisation des défauts » pour s’assurer que les développeurs puissent générer un code de meilleure qualité sans impact sur les délais requis par les propriétaires des applications.

« Shift left » comme facteur clé pour DevOps :

Le graphique ci-dessous montre un graphique typique de défauts IBM i / RPG, soit le volume de défauts qui surviennent entre le début du projet et la date de sortie réelle.

Coût des défauts tout au long du cycle de développement

Bien que 85 % des défauts soient généralement introduits dans les premières phases de codage du cycle DevOps, le coût de réparation des défauts augmente de façon exponentielle au cours des phases ultérieures de test et de livraison, atteignant des coûts incroyablement élevés quand un défaut est détecté en production, avec potentiellement un impact significatif sur le bénéfice net et la réputation des sociétés.

Il est clair qu’avec un « shifting left » de détection des défauts, leur coût et leur impact sont minimisés.

ARCAD Software, à travers son travail avec de nombreuses équipes de développement sur RPG, a constaté que les développeurs effectuent un certain nombre de tâches pour faire progresser la détection des erreurs. Il s’agit notamment de :

• L’unité de codage manuel se teste elle-même afin de tester les fonctionnalités de chaque programme et de s’assurer qu’elles n’ont pas créé de défauts au fur et à mesure de leur développement.
• Les processus de test de Batch individuels continuent de fonctionner après que des modifications aient été apportées à des programmes spécifiques.
• Reconfigurer et travailler avec des données de test complexes, y compris les exigences d’anonymisation.
• Référencer des défauts sur une multitude de composants / programmes pour comprendre l’impact de chaque changement de code sur les autres programmes RPG et aussi sur les références NON -IBM i x.
• Scripter le déploiement du nouveau code une fois compilé sur les différents LPARS (dev, QA, Prod, etc.) et effectuer ensuite un contrôle manuel qui, une fois déployé, permet à chacun des LPARS de fonctionner pleinement. Ce processus est généralement appelé « assurance de l’environnement de test ».
• Préparer le LPAR pour une exécution de test de bout en bout complète, y compris les tests de charge et les tests fonctionnels de bout en bout.

Pourtant, selon l’expérience d’ARCAD, chacun de ces processus, lorsqu’ils sont exécutés manuellement, entraîne des coûts, des efforts et des risques supplémentaires de goulots d’étranglement dans un processus de déploiement DevOps.

Pour faire face à ces défis, ARCAD offre un certain nombre d’outils en complément de CodeChecker (analyse du code source) pour éliminer les goulots d’étranglement dans le processus DevOps et fournir un processus sans failles depuis les spécifications fonctionnelles vers le codage, le test unitaire, la compilation, le développement, le contrôle final et la production de déploiement :

• ARCAD Verifier (BATCH et UI Testing)
• ARCAD DOT Anonymizer,
• ARCAD Observer pour le référencement X
• ARCAD Builder and Drops pour l’automatisation du déploiement et le Release Management

Chacune de ces solutions peut apporter une valeur ajoutée à votre processus de développement, le « Shifting Left » réduisant ainsi le coût global dans le cycle de développement :

Contribution des solutions ARCAD à un «Shift Left» des coûts de développement

Vue et positionnement d’ARCAD

En tant qu’entreprise, ARCAD a entamé son évolution en corrigeant le problème de l’analyse du code source des changements de format de date de l’an 2000. Depuis lors, ARCAD a fourni des solutions aux défis les plus brûlants et les plus actuels auxquels nos plus de 350 clients sont confrontés avec leurs bases de code RPG : X référencement, audit, gestion du code source, Build, test et déploiement.

ARCAD pour DevOps: suite de solutions intégrées sur un noyau référentiel

Suggestion de prochaine étape :

Un processus d’audit en utilisant l’expertise et l’outillage d’ARCAD est un excellent point de départ pour votre cheminement vers un processus DevOps de qualité.

Pour en savoir plus sur la façon dont ARCAD a conçu ses solutions pour résoudre le prochain problème dans l’analyse du code source, contactez ARCAD et découvrez comment CodeChecker et d’autres outils ARCAD DevOps pour IBM i peuvent vous aider avec vos processus de CodeReview, Audit, Testing et DevOps.

Lecture complémentaire :

• Brian Chess
• Shift Left Testing definition