Par Alan Ashley
Nous avons tous entendu parler du pipeline CI/CD dans le cadre de DevOps, c’est une expression standard. Cependant, vous remarquerez souvent que le CT est mis de côté, c’est-à-dire l’aspect des tests continus. Ces tests peuvent inclure la vérification de la qualité du code et de la sécurité, ainsi que des tests unitaires ou de régression. Ces étapes sont cruciales pour réaliser un « Shift Left » ou « Fail Fast » dans le pipeline. L’automatisation dans la phase de test continu peut rendre le processus plus fluide et réduire le temps nécessaire pour les tests. Il est possible que vos développeurs effectuent des tests au fur et à mesure qu’ils développent, mais intégrer pleinement les tests continus dans le pipeline peut améliorer considérablement l’efficacité du processus de développement.
- Est-ce qu’ils effectuent des tests pour s’assurer que le code soit compilé ?
- Est-ce qu’ils vérifient que les modifications n’ont pas d’impact sur le fonctionnement global du système ?
- Après ces deux étapes, est-ce qu’ils effectuent une validation de la qualité ou des tests par les pairs ? Dans les grandes entreprises, ces tests peuvent être effectués en raison de la taille de l’équipe, mais dans les petites entreprises, ils peuvent être négligés en raison de contraintes de ressources.
Dans tous les cas, l’automatisation des tests est indispensable pour le succès du pipeline CI/CT/CD, et avec la suite d’outils de test ARCAD, nous sommes parfaitement alignés avec l’automatisation, quelle que soit la configuration du pipeline utilisé.
Avant de nous lancer dans la construction du pipeline, prenons un peu de recul. Dans votre entreprise, commencez par définir ce qui doit être testé et pourquoi. Comme mentionné précédemment, cela peut inclure la qualité du code, les tests unitaires et les tests de régression. Maintenant, essayons d’identifier ce qui pourrait vous manquer.
Sommaire
1. Qualité et sécurité du code
Abordons dans un premier temps, le début du SEC dans DevSecOps. En réalité, on ne peut jamais vraiment considérer la qualité et la sécurité de son code comme achevées. Il s’agit d’un processus continu. Mais pourquoi cela ? Pour commencer, voici quelques aspects sur lesquels vous devriez réfléchir en matière de qualité et de sécurité. Comme vous le découvrirez, cela dépasse largement ces deux sujets.
- Les développeurs doivent veiller à suivre les meilleures pratiques de développement adaptées à l’entreprise et à l’ensemble de la communauté internationale. Ainsi, tout nouvel arrivant dans votre entreprise remarquera rapidement une cohérence dans le style de codage, ce qui réduit le temps d’intégration et améliore le retour sur investissement pour les nouveaux employés.
- Vous avez récemment pris la décision, ou avez été contraint, de vérifier la qualité et la sécurité de l’ensemble de votre code ? Ce processus peut être intégré au cycle de développement et utilisé par les développeurs lorsqu’ils mettent à jour le code, ou bien il peut être intégré à un pipeline pour lancer un processus de révision du code plus ancien afin de garantir qu’il respecte les normes actuelles.
- Vous avez peut-être récemment acquis une nouvelle entreprise et constaté que le code est en désordre. Comment pouvez-vous identifier et corriger les failles ? Cette tâche pourrait s’avérer être un défi de taille.
C’est ici que l’outil CodeChecker d’ARCAD entre en jeu. Notre produit est livré avec près de 100 règles (telles que la vérification des instructions GO TO, DUMP, etc.) qui ont été recueillies à partir des normes de l’industrie et des CVE (Common Vulnerabilities and Exposures) en matière de sécurité pour l’IBM i. Si ces règles ne couvrent pas vos besoins, une option personnalisée permet d’ajouter d’autres règles pour répondre aux exigences de votre entreprise. Par exemple, vous pouvez valider que le copyright a été ajouté à chaque membre de la source.
Avec CodeChecker, il vous suffit d’un simple clic dans RDI lorsque vous utilisez la suite ARCAD for DevOps, ou il peut être installé de manière autonome avec un client Eclipse. Quelle que soit la méthode choisie, les fonctionnalités restent les mêmes, le serveur pouvant être exécuté sur IBM i ou Windows.
Avant d’aborder les tests unitaires, voici quelques points clés supplémentaires concernant CodeChecker :
- Il prend en charge plusieurs langages IBM i tels que RPG, COBOL, CL et SQL.
- Il est compatible avec les pipelines et l’automatisation.
- Il charge des règles préconfigurées pour vous aider à démarrer.
Je sais que la qualité du code ne fait pas partie de la définition stricte des tests, bien qu’elle soit cruciale pour garantir une base de code solide. Cependant, la vérification des violations de sécurité en fait partie, car leur impact sur la production peut être considérable.
2. Tests unitaires
L’outil ARCAD iUnit pour les tests unitaires s’inscrit une fois de plus dans la méthodologie « Fail Fast, Shift Left ». Cela permet à vos développeurs de tester les modules et les procédures sans avoir besoin de terminer l’ensemble du programme. Ainsi, que vous codiez en RPG, COBOL ou même en CL, iUnit vous couvre. Grâce à sa détection automatique des paramètres simples ou complexes en RPG, ses capacités de modélisation (mocking), et son héritage des fonctionnalités de JUnit, iUnit possède toutes les fonctionnalités nécessaires pour répondre à vos besoins.
Parmi les éléments qui peuvent être testés figurent les fonctions, les procédures, les programmes, les programmes de service ainsi que les procédures SQL. Toutes ces fonctionnalités sont accessibles directement depuis RDi, et bientôt, une intégration plus poussée sera disponible dans le plugin Skipper de la suite DevOps. Cette nouvelle fonctionnalité permettra d’accéder aux tests unitaires en un simple clic droit.
Avec les fonctionnalités héritées de JUnit, ARCAD propose une autre méthode pour inciter les nouveaux développeurs du monde Open System à découvrir le RPG et l’IBM i. Comme il est compatible avec JUnit, il peut également être intégré directement dans le pipeline d’automatisation avec Jenkins, si nécessaire. Personnellement, je pense que la capacité de tester les modules instantanément est le meilleur moyen d’obtenir des résultats rapidement.
3. Test de régression avec Verifier
Pour compléter la phase de test, nous avons les tests de régression. Comment s’assurer que les applications développées et testées précédemment continuent de fonctionner de la même manière après une modification ?
Ces tests sont généralement réalisés par l’équipe d’assurance qualité ou, tout aussi souvent, par toute personne disponible. Vous avez la possibilité de réaliser des tests manuels ou automatisés sur un seul scénario ou une seule opération, couvrant ainsi plusieurs domaines. La question est de savoir quel scénario exécuter.
Avec ARCAD Verifier, un référentiel de références croisées est constamment mis à jour pour déterminer le scénario à exécuter. Si vous modifiez le programme PGM001, tous les scénarios et campagnes associés à ce programme seront automatiquement identifiés ou sélectionnés pour être exécutés. Cette fonctionnalité seule peut vous faire gagner du temps, ce qui se traduit par des économies financières à long terme.
ARCAD Verifier gère à la fois les comparaisons 5250 et les comparaisons de fichiers spooled, ce qui est utile, mais il examine également la base de données DB2 sur IBM i pour identifier les différences au niveau des fichiers et des champs. Avec l’examen DB2 sur IBM i, des outils comme Selenium peuvent être utilisés pour vérifier que les données entrées et traitées au niveau de l’interface web correspondent à ce qui est attendu dans la base de données DB2 en backend.
Vous avez également la possibilité de comparer une entrée 5250 avec une entrée enregistrée par Selenium afin de repérer toute erreur dans le traitement de l’application. De plus, il teste également les différences au niveau de l’interface utilisateur.
Enfin, il prend en charge les traitements par lots et les tâches interactives. À mesure que le pipeline se rapproche du déploiement, les tests de régression deviennent la dernière étape du processus pour prévenir l’apparition de défauts dans la production, y compris la découverte de problèmes liés à un projet de modernisation.
4. Le mot de la fin : le test continu dans le processus CI/CD
Les principaux objectifs de l’intégration des tests continus dans le flux de travail CI/CD sont les suivants :
- « Shift left » pour détecter les problèmes le plus tôt possible.
- Passer d’un processus manuel à un processus automatisé pour garantir la cohérence, la vérifiabilité et la scalabilité.
- Favoriser un processus de développement agile.
Nous avons abordé trois domaines majeurs du pipeline de test, chacun étant couvert par une solution ARCAD. Le « bonus » ici est que ces produits peuvent s’intégrer à un pipeline ARCAD for DevOps existant ou être ajoutés à un pipeline de développement existant en tant qu’installations autonomes.
Si vous vous demandez par où commencer, la réponse est simple : quels sont vos besoins ? Il n’est pas nécessaire de suivre un ordre spécifique pour mettre en œuvre les mesures. Identifiez la zone problématique et nous pourrons vous aider à trouver une solution. Bonne phase de test !
Attendez, pas si vite ! Saviez-vous que vous pouvez également extraire des informations de ces outils pour les refléter dans un tableau de bord ? Cela peut parfois fournir une vue d’ensemble. Ci-dessous, vous trouverez quelques exemples de ce qui peut être extrait du tableau de bord ARCAD VSM associé à la suite d’outils de test :
Figure 1 – CodeChecker via Dashboard
Figure 2 – Verifier via Jenkins and Dashboard
Maintenant, n’hésitez pas à vous lancer et à tester encore et encore.
Alan Ashley
Solution Architect, ARCAD Software
Alan travaille depuis plus de 30 ans dans le domaine du support et de la promotion de la plateforme IBM i. Il est consultant avant-vente pour le rôle DevOps sur IBM i chez ARCAD Software. Avant de rejoindre ARCAD Software, il a occupé pendant de nombreuses années de multiples fonctions au sein d’IBM, de l’assistance aux clients par le biais de HA (Haute Disponibilité) à DR (Reprise après Sinistre) à la promotion des applications et aux migrations de l’IBM i vers le cloud. Dans le cadre de ces fonctions, il a pu constater de visu les difficultés rencontrées par de nombreux clients en matière de gestion du cycle de vie des applications, de modernisation et de protection des données. Sa passion dans ces domaines s’inscrit parfaitement dans la suite de produits ARCAD.
