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

Le test de qualité du code évalue le code de votre application en fonction d’un ensemble de règles de qualité. Il s’agit de l’objectif principal d’un pipeline dédié uniquement à la qualité du code. Cette étape est exécutée immédiatement après l’étape de création dans tous les pipelines, aussi bien en production que hors production.

Voir Configuration de votre pipeline CI-CD pour en savoir plus sur les différents types de pipelines.

Règles de qualité du code understanding-code-quality-rules

Les tests de qualité du code analysent le code source afin de s’assurer qu’il répond à certains critères de qualité. Cette analyse est implémentée par une combinaison de SonarQube et d’examens au niveau du package de contenu à l’aide d’OakPAL. 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é.

Évaluation à trois niveaux three-tiered-gate

Les problèmes identifiés par le test de qualité du code sont affectés à l’une des trois catégories.

Évaluations ratings

Les résultats de cette étape sont fournis sous forme de notes.

Le tableau suivant résume les notes et les seuils d’échec pour chacune des catégories Critique, Important et Informations.

Traitement des faux positifs dealing-with-false-positives

Le processus d’analyse de qualité n’est pas parfait et identifiera parfois de manière incorrecte des problèmes qui ne sont pas réellement problématiques. On parle alors 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 lèvera alors une vulnérabilité de blocage. Mais après avoir examiné le code, vous identifiez qu’il ne s’agit pas d’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.

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 sont efficaces lorsque certaines contraintes de conditionnement sont observées. Le plus significatif est l’optimisation effectuée pour les projets qui génèrent un module de contenu unique, généralement appelé "tout", qui contient plusieurs autres modules de contenu générés, qui sont marqués comme 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.