Queremos compartir a nosa experiencia na implementación dunha plataforma de análise e medición continua da calidade do código SonarQube nos procesos existentes para o desenvolvemento do sistema DPO (un engadido ao sistema de depósito e contabilidade de compensación da Alameda) do Depósito Nacional de Liquidacións.
O National Settlement Depository (Moscow Exchange Group of Companies) é unha das principais empresas de infraestrutura financeira que almacena e rexistra títulos de emisores rusos e estranxeiros por valor de máis de 50 billóns de rublos. O crecente volume de operacións que realiza o sistema, así como o continuo aumento da funcionalidade, esixen manter a alta calidade do código fonte dos sistemas. Unha das ferramentas para acadar este obxectivo é o analizador estático SonarQube. Neste artigo, describimos a experiencia exitosa de implementar sen problemas o analizador estático SonarQube nos procesos de desenvolvemento existentes do noso departamento.
Brevemente sobre o departamento
A nosa competencia inclúe os seguintes módulos: pagos a clientes de NSD, xestión electrónica de documentos (EDF), procesamento de mensaxes de repositorio comercial (rexistro de transaccións fóra de bolsa), canles de interacción electrónica entre clientes e NSD, e moito máis. En xeral, unha gran capa de traballo no lado técnico das operacións. Traballamos en base a aplicacións. As solicitudes dos caixeiros son procesadas polos analistas: recollen os requisitos dos clientes e preséntannos a súa visión de como debería encaixar no programa. Ademais, o esquema estándar: desenvolvemento de código - proba - operación de proba - entrega do código ao circuíto produtivo ao cliente directo.
Por que SonarQube?
Esta é a primeira experiencia do noso departamento na implementación dunha plataforma para o control da calidade do código; anteriormente facíao manualmente, só a revisión do código. Pero o crecente volume de traballo require a automatización deste proceso. Ademais, tamén hai empregados sen experiencia no equipo que non están totalmente familiarizados coa normativa de desenvolvemento interno e tenden a cometer máis erros. Para controlar a calidade do código, decidiuse implementar un analizador estático. Dado que SonarQube xa se utilizou nalgúns sistemas NSD, non tardou moito en escoller. Con anterioridade, compañeiros doutras divisións utilizárono para analizar o código dos microservizos do sistema Alameda (sistema de depósito e contabilidade de compensación propia da NSD), no CFT (sistema de información de contabilidade, balance, elaboración de informes obrigatorios e internos), noutros sistemas. Para experimentar, decidimos comezar coa versión gratuíta de SonarQube. Entón, pasemos ao noso caso.
Proceso de implantación
Temos:
- montaxe automática do sistema en TeamCity;
- configurar o proceso de carga de código mediante MergeRequest desde unha rama de funcións ata a rama mestra en GitLab (proceso de desenvolvemento segundo GitHub Flow);
- SonarQube configurado para analizar o código do sistema DPO a tempo.
O noso obxectivo: implementar a análise automática de código nos procesos CI/CD de AVE.
É necesario personalizar: o proceso de verificación automática do código mediante un analizador estático con cada MergeRequest á rama principal.
Eses. a imaxe de destino é a seguinte: en canto o programador carga cambios na rama de funcións, comeza unha comprobación automática de novos erros no código. Se non hai erros, permítese aceptar os cambios, se non, os erros deberán ser corrixidos. Xa na fase inicial, puidemos identificar un certo número de erros no código. O sistema ten unha configuración moi flexible: pódese configurar de forma que funcione para tarefas específicas dos desenvolvedores, para cada sistema e estilo de programación.
Configurando QualityGate en SonarQube
A análise de QualityGate é algo que lemos nas entrañas de Internet. Inicialmente, utilizamos un enfoque diferente, máis complexo e dalgún xeito non do todo correcto. En primeiro lugar, realizamos a exploración a través de SonarQube dúas veces: analizamos a rama de funcións e a rama onde iamos fusionar a rama de funcións, e despois comparamos o número de erros. Este método non foi estable e non sempre deu o resultado correcto. E entón decatámonos de que en lugar de executar SonarQube dúas veces, podes establecer un límite no número de erros cometidos (QualityGate) e analizar só a rama que cargas e comparas.
Polo momento, aínda usamos unha comprobación de código bastante primitiva. Hai que ter en conta que SonarQube non é compatible con algunhas linguaxes de programación, incluíndo Delphi. Polo momento, para o noso sistema, só analizamos código PLSql.
Funciona así:
- Analizamos só código PL/SQL para o noso proxecto.
- QualityGate está configurado en SonarQube para que o número de erros non aumente coa confirmación.
- O número de erros na primeira execución foi 229. Se hai máis erros durante a commit, non se permite a combinación.
- Ademais, suxeito á corrección de erros, será posible reconfigurar QualityGate.
- Tamén pode engadir novos elementos para a análise, por exemplo, a cobertura de código con probas, etc.
Esquema de traballo:
Nos comentarios do script, podes ver que o número de erros na rama de funcións non aumentou. Entón, todo está ben.
O botón Combinar está dispoñible.
Nos comentarios do script, podes ver que o número de erros na rama de funcións pasou a ser máis do permitido. Así que todo é MAL.
O botón Combinar é vermello. Polo momento, non hai ningunha prohibición de cargar cambios en código erróneo, pero isto faise a criterio do desenvolvedor responsable. No futuro, pode evitar que estes compromisos se realicen na rama principal.
Autogestionar os erros
A continuación, cómpre comprobar todos os erros detectados polo sistema, porque SonarQube analiza segundo os seus estritos estándares. O que considera un erro pode non ser realmente un no noso código. Polo tanto, cómpre comprobar e observar se isto é realmente un erro ou se non hai que editar nas nosas condicións. Así, reducimos o número de erros. Co tempo, o sistema aprenderá a comprender estes matices.
A que chegamos
O noso obxectivo era entender se é conveniente no noso caso transferir a verificación do código á automatización. E o resultado estivo á altura das expectativas. SonarQube permítenos traballar cos idiomas que necesitamos, fai análises bastante competentes e ten o potencial de aprender dos consellos para desenvolvedores. En xeral, estamos satisfeitos coa nosa primeira experiencia con SonarQube e pensamos seguir desenvolvendo nesta dirección. Agardamos que no futuro poidamos aforrar máis tempo e esforzo na revisión do código e melloralo eliminando o factor humano. Quizais no proceso descubriremos as carencias da plataforma ou, pola contra, asegurarémonos unha vez máis de que se trata dunha cousa chula e con moito potencial.
Neste artigo xeral, falamos do noso coñecemento co analizador estático SonarQube. Se tes preguntas, escribe nos comentarios. Se estás interesado neste tema, na nova publicación describiremos con máis detalle como configurar todo correctamente e escribir código para facer tal comprobación.
Autor do texto:
Fonte: www.habr.com