Test de qualité du code code-quality-testing

Découvrez comment fonctionne le test de qualité du code des pipelines et comment il peut améliorer la qualité de vos déploiements.

Présentation introduction

Lors de l’exécution du pipeline, le logiciel capture plusieurs mesures. Ces mesures sont ensuite comparées aux indicateurs clés de performance (KPI) définis par la personne propriétaire de l’entreprise. Ou alors elles sont comparées aux normes définies par Adobe Managed Services.

Ces résultats sont signalés grâce à un système d’évaluation à trois niveaux.

Évaluation à trois niveaux three-tiered-ratings

Le pipeline comprend trois points de contrôle :

Pour chaque point de contrôle, il existe une structure à trois niveaux pour les problèmes identifiés par le point de contrôle.

Test de qualité du code code-quality-testing-step

Cette étape de test évalue la qualité du code de votre application, qui est l’objectif principal d’un pipeline de qualité de code uniquement. Il est exécuté immédiatement après l’étape de création dans tous les pipelines de production et hors production. Pour en savoir plus, voir Configurer des pipelines hors production.

Les tests de qualité du code analysent le code source afin de s’assurer qu’il répond à certains critères de qualité.

Le logiciel les implémente avec une combinaison d’analyses SonarQube, d’examen au niveau du package de contenu à l’aide d’OakPAL et de validation du Dispatcher à l’aide de l’outil d’optimisation du Dispatcher.

Il existe plus de 100 règles combinant des règles Java génériques et des règles spécifiques à AEM. Certaines des règles spécifiques à AEM sont créées en fonction des bonnes pratiques de l’équipe d’ingénierie AEM et sont appelées Règles de qualité du code personnalisées.

Les résultats des tests de qualité du code sont fournis sous forme d’évaluation, comme résumé dans ce tableau.

Traitement des faux positifs dealing-with-false-positives

Le processus d’analyse de qualité n’est pas parfait et identifie parfois de manière incorrecte des problèmes qui ne sont pas réellement problématiques. Ce scénario est connu sous le nom de faux positif.

Dans ces cas, le code source peut être annoté avec l’annotation standard Java @SuppressWarnings en spécifiant l’ID de la règle comme attribut d’annotation. Par exemple, un faux positif courant est que la règle de SonarQube permettant de détecter les mots de passe codés en dur peut être agressive sur la façon dont un mot de passe codé en dur est identifié.

Le code suivant est assez courant dans un projet AEM, qui comporte du code pour se connecter à un service externe.

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube soulève alors une vulnérabilité de blocage. Mais après avoir examiné le code, vous identifiez que ce problème n’est pas une vulnérabilité et vous pouvez l’annoter avec l’identifiant de règle approprié.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Cependant, si le code était en fait ceci :

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

La bonne solution consiste alors à supprimer le mot de passe codé en dur.

Test de sécurité security-testing

Cloud Manager exécute les contrôles d’intégrité de sécurité AEM existants sur l’environnement d’évaluation suite au déploiement et indique leur statut via l’interface utilisateur. Les résultats sont agrégés à partir de toutes les instances AEM de l’environnement.

Ces mêmes contrôles d’intégrité peuvent être exécutés à tout moment par l’intermédiaire de la console Web ou du tableau de bord d’opérations.

Si l’une des instances signale un échec pour un contrôle d’intégrité donné, l’ensemble de l’environnement ne réussit pas ce contrôle d’intégrité. Comme pour les tests de qualité du code et de performance, ces contrôles d’intégrité sont classés en catégories et signalés à l’aide du système de point de contrôle à trois niveaux. La seule différence réside dans le fait qu’il n’existe aucun seuil en cas de tests de sécurité. Tous les contrôles d’intégrité réussissent ou non.

Le tableau suivant répertorie les contrôles d’intégrité :

Test de performance performance-testing

AEM Sites aem-sites

Cloud Manager exécute des tests de performances pour les programmes AEM Sites. Le test de performance est exécuté pendant environ 30 minutes en émulant des utilisateurs virtuels (conteneurs) qui simulent des utilisateurs réels pour accéder aux pages sur l’environnement d’évaluation, et par là le trafic qu’ils généreraient. Vous pouvez trouver ces pages à l’aide d’un robot d’exploration.

Utilisateurs virtuels virtual-users

Cloud Manager crée une rotation des utilisateurs et utilisatrices virtuels ou des conteneurs en fonction des KPI (temps de réponse et pages vues/min) définis par le rôle Personne propriétaire de l’entreprise. Ces KPI sont définis lors de la création ou modification du programme.

En fonction des KPI définis, il est possible d’émuler jusqu’à dix conteneurs de simulation d’utilisateurs et d’utilisatrices réels. Les pages sélectionnées pour les tests sont divisées et attribuées à chaque utilisateur virtuel.

Robot d’exploration crawler

Avant le début de la période de test de 30 minutes, Cloud Manager explore l’environnement d’évaluation à l’aide d’une ou de plusieurs URL d’amorçage configurées par l’équipe d’ingénierie chargée du succès client. À partir de ces URL, le code HTML de chaque page est examiné et les liens sont parcourus en largeur d’abord.

Ensembles de pages pour les tests page-sets

Trois ensembles de pages sélectionnent les pages. Cloud Manager utilise les journaux d’accès des instances AEM à travers les environnements de production et d’évaluation pour déterminer les ensembles suivants :

Répartition du trafic entre les ensembles de pages sélectionnés distribution-of-traffic

Vous pouvez choisir entre un jeu et les trois jeux dans l’onglet Testing de votre configuration de pipeline. La répartition du trafic est basée sur le nombre d’ensembles sélectionnés. En d’autres termes, si les trois éléments sont sélectionnés, 33 % du total des pages vues sont placés dans chaque ensemble. Si deux sont sélectionnés, 50 % sont affectés à chaque ensemble. Si seulement l’un d’entre eux est sélectionné, 100 % du trafic est affecté à cet ensemble.

Prenons cet exemple.

Pendant la période de test de 30 minutes :

Tests et rapports testing-reporting

Cloud Manager exécute des tests de performance pour les programmes AEM Sites en demandant des pages en tant qu’utilisateur non authentifié par défaut sur le serveur de publication d’évaluation pendant une période de test de 30 minutes. Il mesure les mesures virtuelles générées par l’utilisateur (temps de réponse, taux d’erreur, vues par minute, etc.) pour chaque page et diverses mesures au niveau du système (unité centrale, mémoire, données réseau) pour toutes les instances.

Le tableau suivant résume la matrice de test de performance à l’aide du système de point de contrôle à trois niveaux :

Pour plus d’informations sur l’utilisation de l’authentification de base pour les tests de performances de Sites et Assets, voir Test de performance authentifié .

Test de performances avec authentification authenticated-performance-testing

Si nécessaire, les clientes et clients AMS disposant de sites authentifiés peuvent spécifier un nom d’utilisateur ou d’utilisatrice et un mot de passe que Cloud Manager utilise pour accéder au site web lors des tests de performance des sites.

Le nom d’utilisateur ou d’utilisatrice et le mot de passe sont spécifiés sous la forme de variables de pipeline avec les noms CM_PERF_TEST_BASIC_USERNAME et CM_PERF_TEST_BASIC_PASSWORD.

Le nom d’utilisateur ou d’utilisatrice doit être stocké dans une variable string et le mot de passe dans une variable secretString. Si ces deux variables sont spécifiées, chaque requête du robot de tests de performances et des utilisateurs et utilisatrices virtuels de test contient ces informations d’identification sous forme d’authentification HTTP basique.

Pour définir ces variables à l’aide de l’interface de ligne de commande de Cloud Manager, exécutez ce qui suit :

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Consultez la documentation de l’API Correctif des variables de pipeline de l’utilisateur ou de l’utilisatrice pour apprendre à utiliser l’API.

AEM Assets aem-assets

Cloud Manager effectue des tests de performance pour les programmes AEM Assets en chargeant de manière répétée des ressources pendant 30 minutes.

Exigences de l’intégration onboarding-requirement

Pour les tests de performances Assets, votre équipe d’ingénierie du succès client crée un utilisateur ou une utilisatrice cloudmanager et un mot de passe lors de l’intégration de l’environnement de création à celui d’évaluation. Les étapes du test de performance nécessitent une personne appelée cloudmanager et le mot de passe associé configuré par votre CSE.

Cette méthode doit rester dans l’instance de création avec ses autorisations inchangées. Sa modification ou sa suppression peut entraîner l’échec des tests de performances d’Assets.

Images et ressources pour les tests assets-for-testing

Les clients peuvent charger leurs propres ressources pour les tester. Ce processus peut être effectué à partir de l’écran Configuration du pipeline ou Modifier. Les formats d’image courants tels que JPEG, PNG, GIF et BMP sont pris en charge, ainsi que les fichiers Photoshop, Illustrator et PostScript.

Si aucune image n’est chargée, Cloud Manager utilise une image et des documents PDF par défaut à des fins de test.

Répartition des ressources pour les tests distribution-of-assets

La répartition du nombre de ressources de chaque type qui sont chargées par minute est définie dans l’écran Configuration du pipeline ou Modifier.

Par exemple, si une répartition 70/30 est utilisée et que 10 ressources sont chargées par minute, 7 images et 3 documents sont chargés par minute.

Tests et rapports testing-and-reporting

Cloud Manager crée un dossier sur l’instance de création à l’aide du nom d’utilisateur ou d’utilisatrice et du mot de passe configurés par le CSE. Les ressources sont ensuite chargées dans le dossier à l’aide d’une bibliothèque open source. Les tests exécutés par l’étape de test Assets sont écrits à l’aide d’une bibliothèque open source. Le temps de traitement de chaque ressource et de diverses mesures au niveau du système sont mesurés sur la durée des tests de 30 minutes. Cette fonctionnalité permet de charger des images et des documents PDF.

Graphiques des résultats des tests de performance performance-testing-results-graphs

Un certain nombre de mesures sont disponibles dans la Boîte de dialogue des tests de performance.

Les panneaux de mesures peuvent être développés pour afficher un graphique, fournir un lien vers un téléchargement ou les deux.

Cette fonctionnalité est disponible pour les mesures suivantes.

Optimisation de l’analyse des packages de contenu content-package-scanning-optimization

Dans le cadre du processus d’analyse de la qualité, Cloud Manager effectue une analyse des packages de contenu générés par la version Maven. Cloud Manager propose des optimisations pour accélérer ce processus, qui est efficace lorsque certaines contraintes de conditionnement sont observées.

La principale optimisation est effectuée pour les projets qui génèrent un seul package « all », qui contient d’autres packages de contenu générés par la version, qui sont marqués comme étant ignorés. Lorsque Cloud Manager détecte ce scénario, plutôt que de décompresser le package « all », les packages de contenu individuels sont analysés directement et triés en fonction des dépendances. Par exemple, considérez la sortie de génération suivante.

Si les seuls éléments contenus dans myco-all-1.0.0-SNAPSHOT.zip sont les deux packages de contenu ignorés, les deux packages incorporés sont analysés au lieu du package de contenu « all ».

Pour les projets qui produisent des dizaines de packages incorporés, il a été démontré que cette optimisation permet de gagner jusqu’à 10 minutes par exécution de pipeline.

Un cas particulier peut se produire lorsque le package de contenu « all » contient une combinaison de packages de contenu ignorés et de lots OSGi. Par exemple, si myco-all-1.0.0-SNAPSHOT.zip contient les deux packages incorporés mentionnés précédemment ainsi qu’un ou plusieurs lots OSGi, un nouveau package de contenu minimal est créé avec uniquement les lots OSGi. Ce package est toujours nommé cloudmanager-synthetic-jar-package et les lots contenus sont placés dans /apps/cloudmanager-synthetic-installer/install.