Teste de qualidade do código

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

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 o documento Configuração do seu pipeline de CI-CD para saber mais sobre os diferentes tipos de pipelines.

Regras de qualidade do código

O teste de qualidade do código verifica o código-fonte para garantir que atenda a determinados critérios de qualidade. Ele é implementado por uma combinação de SonarQube e exame em nível de pacote de conteúdo usando OakPAL. Há mais de 100 regras, que combinam regras Java genéricas e regras específicas do AEM. Algumas das regras específicas do AEM são criadas com base nas práticas recomendadas pela Engenharia do AEM e são chamadas de regras de qualidade do código personalizado.

OBSERVAÇÃO

Você pode baixar a lista completa de regras neste link.

Classificações de três níveis

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

  • Crítico - São problemas que causam a falha imediata do pipeline.

  • Importante - São problemas que fazem com que o pipeline entre no estado pausado. Um gerente de implantação, gerente de projetos ou proprietário da empresa pode substituir os problemas, caso em que o pipeline continua, ou pode aceitar os problemas, caso em que o pipeline é interrompido com uma falha.

  • Informações - São problemas fornecidos exclusivamente para fins informativos e não têm impacto na execução do pipeline.

OBSERVAÇÃO

Em um pipeline somente de qualidade do código, falhas importantes no portal de qualidade do código não podem ser substituídas, pois a etapa de teste de qualidade do código é a etapa final no pipeline.

Classificações

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.

Nome Definição Categoria Limite de falha
Classificação de segurança A = Sem vulnerabilidades
B = Pelo menos 1 vulnerabilidade baixa
C = Pelo menos 1 vulnerabilidade alta
D = Pelo menos 1 vulnerabilidade crítica
E = Pelo menos 1 vulnerabilidade limitante
Crítico < B
Classificação de confiabilidade A = Sem erros
B = Pelo menos 1 erro baixo
C = Pelo menos 1 erro alto
D = Pelo menos 1 erro crítico
E = Pelo menos 1 erro limitante
Crítico < D
Classificação da capacidade de manutenção Definido pelo custo de remediação pendente de code smells como uma porcentagem do tempo já dispendido no aplicativo
  • A = <=5%
  • B = 6-10%
  • C = 11-20%
  • D = 21-50%
  • E = >50%
Importante < A
Abrangência Definida por uma combinação de abrangências da linha de teste unitária e da condição utilizando a fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
  • CT = Condições que foram avaliadas como true pelo menos uma vez durante a execução dos testes da unidade
  • CF = Condições que foram avaliadas como false pelo menos uma vez durante a execução dos testes da unidade
  • LC = Linhas abrangidas = lines_to_cover - uncovered_lines
  • B = número total de condições
  • EL = número total de linhas executáveis (lines_to_cover)
Importante < 50%
Testes de unidade ignorados Número de testes de unidade ignorados Informações > 1
Problemas em aberto Tipos de problemas gerais - Vulnerabilidades, Erros e Code Smells Informações > 0
Linhas duplicadas Definido como o número de linhas envolvidas em blocos duplicados. Um bloco de código é considerado duplicado nas condições a seguir.
Projetos não Java:
  • Deve haver pelo menos 100 tokens sucessivos e duplicados.
  • Esses tokens devem estar distribuídos por pelo menos:
  • 30 linhas de código para COBOL
  • 20 linhas de código para ABAP
  • 10 linhas de código para outras linguagens
Projetos Java:
  • Deve haver pelo menos 10 declarações sucessivas e duplicadas, independentemente do número de tokens e linhas.
As diferenças de recuo, bem como nos literais de string são ignoradas ao detectar duplicidades.
Informações > 1%
Compatibilidade do Cloud Service Número de problemas de compatibilidade do Cloud Service identificados Informações > 0
OBSERVAÇÃO

Consulte Definições das métricas do SonarQube para obter definições mais detalhadas.

OBSERVAÇÃO

Para saber mais sobre as regras de qualidade do código personalizado executadas pelo Cloud Manager, consulte o documento Regras de qualidade do código personalizado.

Como lidar com falsos positivos

O processo de verificação da qualidade não é perfeito e, por vezes, identifica incorretamente problemas que não são realmente problemas. Isso é 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 identificará uma vulnerabilidade de bloqueador. Porém, depois de revisar o código, você reconhece que isso não é uma vulnerabilidade e pode 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.

OBSERVAÇÃO

Embora seja uma prática recomendada tornar a anotação @SuppressWarnings o mais específica possível — ou seja, anotar apenas a declaração ou o bloco específico que causa o problema —, é possível anotar em nível de classe.

OBSERVAÇÃO

Embora não haja uma etapa explícita de teste de segurança, há regras de qualidade do código relacionadas à segurança que são avaliadas durante a etapa de qualidade do código. Consulte o documento Visão geral de segurança para o AEM as a Cloud Service para saber mais sobre segurança no Cloud Service.

Otimização da verificação do pacote de conteúdo

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 são eficazes quando determinadas restrições de empacotamento são observadas. Mais importante é a otimização executada para projetos que geram um único pacote de conteúdo, geralmente chamado de pacote “tudo”, que contém vários outros pacotes de conteúdo produzidos pela compilação, 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.

  • all/myco-all-1.0.0-SNAPSHOT.zip (content-package)
  • ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip (skipped-content-package)
  • ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip (skipped-content-package)

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.

OBSERVAÇÃO
  • Essa otimização não afeta os pacotes implantados no AEM.
  • Como a correspondência entre os pacotes de conteúdo incorporados e os pacotes de conteúdo ignorados se baseia em nomes de arquivo, essa otimização não pode ser executada se vários pacotes de conteúdo ignorados tiverem exatamente o mesmo nome de arquivo ou se o nome de arquivo for alterado durante a incorporação.

Nesta página