Teste de qualidade do código code-quality-testing

Saiba como funciona o teste de qualidade do código dos pipelines e como ele pode melhorar a qualidade das suas implantações.

Introdução introduction

O teste de qualidade do código avalia o código do aplicativo com base em um conjunto de regras de qualidade. É o objetivo principal de um pipeline somente de qualidade do código e é executado imediatamente após a etapa de compilação em todos os pipelines de produção e não produção.

Consulte Configuração do pipeline de CI-CD para saber mais sobre os diferentes tipos de pipelines.

Regras de qualidade do código understanding-code-quality-rules

O teste de qualidade do código verifica o código-fonte para garantir que atenda a determinados critérios de qualidade. Uma combinação de SonarQube e exame em nível de pacote de conteúdo usando OakPAL implementa essa etapa. Há mais de 100 regras, que combinam regras do Java genéricas e regras específicas do AEM. Algumas regras específicas do AEM são baseadas nas práticas recomendadas pela Engenharia do AEM e são conhecidas como regras de qualidade do código personalizado.

Você pode baixar a lista completa atual de regras usando este link.

Classificações de três níveis three-tiered-gate

Os problemas identificados pelos testes de qualidade do código são atribuídos a uma de três categorias.

Classificações ratings

Os resultados desta etapa são fornecidos como Classificações.

A tabela a seguir resume as classificações e os limites de falha para cada uma das categorias: crítico, importante e informativo.

Como lidar com falsos positivos dealing-with-false-positives

O processo de verificação da qualidade não é perfeito e, por vezes, identifica incorretamente problemas que não são realmente problemas. Este estado é chamado de falso positivo.

Nesses casos, o código-fonte pode ser anotado com a anotação Java padrão @SuppressWarnings especificando a ID da regra como o atributo de anotação. Por exemplo, um falso positivo comum é que a regra do SonarQube para detectar senhas codificadas pode ser rígida quanto à forma como uma senha codificada é identificada.

O código a seguir é bastante comum em um projeto AEM, que tem código para se conectar a serviços externos.

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

O SonarQube gera uma vulnerabilidade de bloqueador. Porém, depois de revisar o código, é possível reconhecer que não se trata de uma vulnerabilidade e anotar o código com a ID de regra apropriada.

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

No entanto, se o código fosse este:

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

Então, a solução correta seria remover a senha codificada.

Otimização da verificação do pacote de conteúdo content-package-scanning-optimization

Como parte do processo de análise de qualidade, o Cloud Manager realiza a análise dos pacotes de conteúdo produzidos pela compilação Maven. O Cloud Manager oferece otimizações para acelerar esse processo, que é eficaz quando determinadas restrições de empacotamento são observadas. A otimização mais significativa tem como alvo projetos que produzem um único pacote "all", contendo vários pacotes de conteúdo da build, que são marcados como ignorados. Quando o Cloud Manager detecta esse cenário, em vez de descompactar o pacote “all”, os pacotes de conteúdo individuais são diretamente verificados e classificados com base nas dependências. Por exemplo, considere a saída de compilação a seguir.

Se os únicos itens dentro de myco-all-1.0.0-SNAPSHOT.zip são os dois pacotes de conteúdo ignorados, então os dois pacotes incorporados serão verificados no lugar do pacote de conteúdo “all”.

Para projetos que produzem dezenas de pacotes incorporados, essa otimização economiza mais de 10 minutos por execução de pipeline.

Um caso especial pode ocorrer quando o pacote de conteúdo “all” contiver uma combinação de pacotes de conteúdo ignorados e pacotes OSGi. Por exemplo, se myco-all-1.0.0-SNAPSHOT.zip continha os dois pacotes incorporados mencionados anteriormente, bem como um ou mais pacotes OSGi, então um novo pacote de conteúdo mínimo é construído apenas com os pacotes OSGi. Esse pacote é sempre nomeado cloudmanager-synthetic-jar-package e os pacotes contidos são colocados em /apps/cloudmanager-synthetic-installer/install.