Queremos compartilhar nossa experiência de implementação da plataforma SonarQube para análise contínua e medição da qualidade do código nos processos de desenvolvimento existentes do sistema DPO (adição ao depositário Alameda e sistema de compensação de contabilidade) do National Settlement Depository.
O National Settlement Depository (grupo de empresas da Bolsa de Moscou) é uma das principais empresas na infraestrutura financeira, armazenando e contabilizando títulos de emissores russos e estrangeiros no valor de mais de 50 trilhões de rublos. O crescente volume de operações realizadas pelo sistema, bem como a contínua expansão das funcionalidades, exigem a manutenção do código-fonte dos sistemas de alta qualidade. Uma ferramenta para atingir esse objetivo é o analisador estático SonarQube. Neste artigo descreveremos a experiência bem-sucedida de implementação perfeita do analisador estático SonarQube nos processos de desenvolvimento existentes em nosso departamento.
Resumidamente sobre o departamento
Nossa competência inclui os seguintes módulos: pagamentos a clientes NSD, gestão eletrônica de documentos (EDF), processamento de mensagens de repositórios de transações (registro de transações de balcão), canais de interação eletrônica entre clientes e NSD e muito mais. Em geral, há muito trabalho a ser feito no lado técnico das atividades operacionais. Trabalhamos com base em solicitações. As solicitações dos diretores de operações são processadas por analistas: eles coletam os requisitos do cliente e nos apresentam sua visão de como isso deve se encaixar no programa. A seguir vem o esquema padrão: desenvolvimento de código – teste – operação experimental – entrega do código no circuito de produção ao cliente direto.
Por que SonarQube?
Esta é a primeira experiência do nosso departamento na implementação de uma plataforma para controle de qualidade de código - antes fazíamos isso manualmente, realizando apenas revisões de código. Mas o crescente volume de trabalho exige a automatização deste processo. Além disso, a equipe também conta com colaboradores inexperientes, que não estão totalmente familiarizados com as normas internas de desenvolvimento e tendem a cometer mais erros. Para controlar a qualidade do código, optou-se por implementar um analisador estático. Como o SonarQube já era usado em alguns sistemas NSD, a escolha não demorou muito. Anteriormente, colegas de outros departamentos utilizavam-no para analisar o código de microsserviços no sistema Alameda (sistema de depósito e compensação contábil próprio da NSD), no CFT (sistema de informação para manutenção de contabilidade, balanços, preparação de relatórios obrigatórios e internos), em alguns outros sistemas. Para experiências, decidimos começar com a versão gratuita do SonarQube. Então, vamos ao nosso caso.
Processo de implementação
Nós temos:
- montagem automática de sistema no TeamCity;
- o processo de upload de código via MergeRequest do branch feature para o branch master no GitLab foi configurado (processo de desenvolvimento de acordo com GitHub Flow);
- SonarQube, configurado para analisar o código do sistema DPO de acordo com uma programação.
Nosso objetivo: implementar análise automática de código em processos CI/CD de DPO.
Precisa configurar: o processo de verificação automática do código com um analisador estático a cada MergeRequest para a ramificação principal.
Aqueles. A imagem alvo é a seguinte: assim que o desenvolvedor carrega as alterações no branch de recursos, uma verificação automática de novos erros no código é iniciada. Se não houver erros, as alterações poderão ser aceitas, caso contrário os erros deverão ser corrigidos. Já na fase inicial conseguimos identificar um certo número de erros no código. O sistema possui configurações muito flexíveis: pode ser configurado de forma que funcione para as tarefas específicas dos desenvolvedores, para cada sistema e estilo de programação.
Configurando QualityGate no SonarQube
A análise QualityGate é algo que lemos nas profundezas da Internet. Inicialmente, utilizamos uma abordagem diferente, mais complexa e, em alguns aspectos, não totalmente correta. Primeiro, executamos a varredura duas vezes por meio do SonarQube: verificamos a ramificação do recurso e a ramificação onde iríamos mesclar a ramificação do recurso e, em seguida, comparamos o número de erros. Este método não era estável e nem sempre produzia o resultado correto. E então descobrimos que em vez de executar o SonarQube duas vezes, podemos definir um limite para o número de erros cometidos (QualityGate) e analisar apenas o branch que você carrega e compara.
Por enquanto ainda estamos usando uma revisão de código bastante primitiva. Vale ressaltar que o SonarQube não é compatível com algumas linguagens de programação, incluindo Delphi. No momento, analisamos apenas o código PLSQL do nosso sistema.
Funciona assim:
- Analisamos apenas código PL/SQL para nosso projeto.
- SonarQube possui QualityGate configurado para que o número de erros não aumente com um commit.
- O número de erros na primeira inicialização foi 229. Se houver mais erros durante um commit, a mesclagem não será permitida.
- Além disso, se os erros forem corrigidos, será possível reconfigurar o QualityGate.
- Você também pode adicionar novos pontos para análise, por exemplo, cobertura de código com testes, etc.
Esquema de trabalho:
Os comentários do script mostram que o número de erros na ramificação do recurso não aumentou. Então está tudo bem.
O botão Mesclar fica disponível.
Nos comentários do script, você pode ver que o número de erros na ramificação do recurso tornou-se mais do que aceitável. Então está tudo RUIM.
O botão Mesclar é vermelho. No momento, não há proibição de upload de alterações com base em código incorreto, mas isso fica a critério do desenvolvedor responsável. No futuro, você pode evitar que tais commits sejam adicionados ao branch principal.
Trabalho independente sobre erros
A seguir, é necessário verificar todos os erros detectados pelo sistema, pois o SonarQube analisa de acordo com seus rígidos padrões. O que ele considera um erro pode não ser realmente um erro em nosso código. Portanto, é preciso verificar e observar se isso é realmente um erro, ou se não há necessidade de edição em nossas condições. Desta forma reduzimos o número de erros. Com o tempo, o sistema aprenderá a compreender essas nuances.
A que ponto chegamos
Nosso objetivo era entender se seria aconselhável no nosso caso transferir a revisão de código para a automação. E o resultado correspondeu às expectativas. SonarQube nos permite trabalhar com as linguagens que precisamos, faz análises bastante competentes e tem potencial para aprender com dicas de desenvolvedores. No geral, estamos satisfeitos com a nossa primeira experiência com o SonarQube e planejamos desenvolver ainda mais nessa direção. Esperamos que no futuro possamos economizar mais tempo e esforço na revisão de código e melhorá-lo eliminando o fator humano. Talvez no processo descubramos as deficiências da plataforma ou, pelo contrário, ficaremos mais uma vez convencidos de que se trata de uma coisa bacana e com grande potencial.
Neste artigo de revisão falamos sobre nosso conhecimento do analisador estático SonarQube. Se você tiver dúvidas, escreva nos comentários. Se você estiver interessado neste tópico, em uma nova publicação descreveremos com mais detalhes como configurar tudo corretamente e escrever o código para fazer tal verificação.
Escritor de texto:
Fonte: habr.com