Test de qualité du code

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

Le test de qualité du code évalue votre code d’application en fonction d’un ensemble de règles de qualité. Il s’agit de l’objectif Principal d’un pipeline de qualité de code uniquement et qui est exécuté immédiatement après l’étape de création dans tous les pipelines de production et hors production.

Reportez-vous au document Configuration de votre pipeline CI-CD pour en savoir plus sur les différents types de pipelines.

Règles de qualité du code

Les tests de qualité du code analysent le code source afin de s’assurer qu’il répond à certains critères de qualité. Cela est mis en oeuvre par une combinaison de SonarQube et d’examen 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 à l’AEM sont créées en fonction des bonnes pratiques d’AEM Engineering et sont appelées règles de qualité du code personnalisé.

REMARQUE

Vous pouvez télécharger la liste complète des règles avec ce lien.

Évaluation à trois niveaux

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

  • Critique - il s’agit des problèmes qui entraînent une défaillance immédiate du pipeline.

  • Important - il s’agit des problèmes qui entraînent la mise en pause du pipeline. Un responsable de déploiement, un responsable de projet ou un propriétaire d’entreprise peuvent soit contourner les problèmes, auquel cas le pipeline continue, soit accepter les problèmes, auquel cas le pipeline s’arrête avec un échec.

  • Infos - Il s’agit de problèmes qui sont fournis uniquement à titre d’information et qui n’ont aucun impact sur l’exécution du pipeline.

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 critiques, importantes et d’informations.

Nom Définition Catégorie Seuil d’échec
Note de sécurité A = Aucune vulnérabilité
B = au moins 1 vulnérabilité mineure
C = au moins 1 vulnérabilité majeure
D = au moins 1 vulnérabilité critique
E = au moins 1 vulnérabilité bloquante
Critique < B
Note de fiabilité A = Aucun bug
B = au moins 1 bug mineur
C = au moins 1 bug majeur
D = au moins 1 bug critique
E = au moins 1 bug bloquant
Critique < D
Note de maintenabilité Défini par le coût de remédiation en suspens pour les code smells, comme un pourcentage du temps qui a déjà été consacré à l’application.
  • A = <= 5 %
  • B = 6-10 %
  • C = 11-20 %
  • D = 21-50 %
  • E = > 50 %
Important < A
Couverture Défini par un mélange de couverture de ligne de test unitaire et de couverture de condition à l’aide de la formule :
Coverage = (CT + CF + LC)/(2*B + EL)
  • CT = Conditions qui ont été évaluées comme true au moins une fois lors de l’exécution de tests unitaires
  • CF = Conditions qui ont été évaluées comme false au moins une fois lors de l’exécution de tests unitaires
  • LC = Lignes couvertes = lines_to_cover - uncover_lines
  • B = nombre total de conditions
  • EL = nombre total de lignes exécutables (lines_to_cover)
Important < 50 %
Tests unitaires ignorés Nombre de tests unitaires ignorés Infos > 1
Problèmes en cours Types de problèmes généraux – Vulnérabilités, bogues et smells de code Infos > 0
Lignes dupliquées Défini comme le nombre de lignes impliquées dans les blocs dupliqués. Un bloc de code est considéré comme dupliqué dans les conditions suivantes.
Projets non Java :
  • Il doit y avoir au moins 100 jetons successifs et dupliqués.
  • Ces jetons doivent être répartis au moins sur :
  • 30 lignes de code pour COBOL
  • 20 lignes de code pour ABAP
  • 10 lignes de code pour d’autres langages
Projets Java :
  • Il devrait y avoir au moins 10 déclarations successives et dupliquées, quel que soit le nombre de jetons et de lignes.
Les différences dans la mise en retrait ainsi que dans les littéraux de chaîne sont ignorées lors de la détection des doublons.
Infos > 1 %
Compatibilité Cloud Service Nombre de problèmes de compatibilité du service cloud identifiés Infos > 0
REMARQUE

Voir Définitions des mesures de SonarQube pour des définitions plus détaillées.

REMARQUE

Pour en savoir plus sur les règles de qualité du code personnalisé exécutées par Cloud Manager, reportez-vous au document Règles de qualité du code personnalisé.

Traitement des faux positifs

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.

REMARQUE

Bien qu’il soit préférable de rendre l’annotation @SuppressWarnings aussi précise que possible, c’est-à-dire de n’annoter que l’énoncé ou le bloc qui cause le problème, il est tout de même possible de le faire à un niveau qui se rapporte à la classe.

REMARQUE

Bien qu’il n’existe pas d’étape de test de sécurité explicite, des règles de qualité du code liées à la sécurité sont évaluées à l’étape de qualité du code. Reportez-vous au document Présentation de la sécurité pour AEM as a Cloud Service pour en savoir plus sur la sécurité en Cloud Service.

Optimisation de l’analyse des packages de contenu

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. La plus importante est l’optimisation effectuée pour les projets qui génèrent un seul package de contenu, généralement appelé package « all », qui contient un certain nombre 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.

  • all/myco-all-1.0.0-SNAPSHOT.zip (module de contenu)
  • ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip (module de contenu ignoré)
  • ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip (module de contenu ignoré)

Si les seuls éléments contenus dans myco-all-1.0.0-SNAPSHOT.zip sont les deux modules de contenu ignorés, les deux modules intégrés seront analysés au lieu du module 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 module de contenu « all » contient une combinaison de modules 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 module est toujours nommé cloudmanager-synthetic-jar-package et les lots contenus sont placés dans /apps/cloudmanager-synthetic-installer/install.

REMARQUE
  • Cette optimisation n’a aucune incidence sur les packages déployés dans AEM.
  • Étant donné que la correspondance entre les packages de contenu incorporés et les packages de contenu ignorés est basée sur les noms de fichier, cette optimisation ne peut pas être effectuée si plusieurs packages de contenu ignorés portent exactement le même nom de fichier ou si le nom du fichier est modifié lors de l’incorporation.

Sur cette page