Test de qualité du code
- Rubriques :
- Cloud Manager
- Développement
Créé pour :
- Administration
- Développeur
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 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
Les tests de qualité du code analysent le code source afin de s’assurer qu’il répond à certains critères de qualité. Cette étape 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 règles spécifiques à AEM sont basées sur les bonnes pratiques de l’ingénierie AEM et sont connues sous le nom de règles de qualité du code personnalisé.
Vous pouvez télécharger la liste complète actuelle des règles via 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 : problèmes qui entraînent une défaillance immédiate du pipeline.
-
Important : 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, ce qui permet au pipeline de continuer. Au contraire, les problèmes peuvent également être acceptés, ce qui entraîne l’arrêt du pipeline avec un échec.
-
Info - Problèmes fournis uniquement à titre d’information et qui n’ont aucune incidence sur l’exécution du pipeline
Évaluations
Les résultats de cette étape sont fournis sous la forme notes.
Le tableau suivant résume les notes et les seuils d’échec pour chacune des catégories Critique, Important et 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.
| 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 :
| 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 Java :
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é Cloud Service identifiés | Infos | > 0 |
Traitement des faux positifs
Le processus d’analyse de la qualité n’est pas parfait et identifie parfois incorrectement les problèmes qui ne sont pas réellement des problèmes. Cet état est appelé 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 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.
@SuppressWarnings
aussi précise que possible (par exemple en annotant uniquement l’instruction ou le bloc à l’origine du problème), il est également possible d’annoter au niveau de la classe.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 est efficace lorsque certaines contraintes de conditionnement sont observées. L’optimisation la plus importante cible les projets qui produisent un seul package « all », contenant plusieurs packages de contenu de la version, 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.
all/myco-all-1.0.0-SNAPSHOT.zip
(package de contenu)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip
(package de contenu ignoré)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip
(package de contenu ignoré)
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
.
- Cette optimisation n’a aucune incidence sur les packages déployés dans AEM.
- La correspondance entre les packages de contenu incorporés et les packages de contenu ignorés repose sur les noms de fichier. Cette optimisation ne peut pas se produire si plusieurs packages ignorés partagent le même nom de fichier ou si le nom du fichier change lors de l’incorporation.