Queremos compartir nuestra experiencia en la implementación de la plataforma para el análisis continuo y la medición de la calidad del código SonarQube en los procesos existentes de desarrollo del sistema DPO (complemento del sistema de contabilidad de depósito y compensación "Alameda") del Depósito Nacional de Valores.
El Depósito Nacional de Valores (grupo de empresas "Bolsa de Moscú") es una de las compañías clave de la infraestructura financiera, que almacena y contabiliza valores de emisores rusos y extranjeros por un monto superior a 50 billones de rublos. El creciente volumen de operaciones realizadas por el sistema, así como la continua expansión de la funcionalidad, requieren mantener una alta calidad del código fuente de los sistemas. Una de las herramientas para alcanzar este objetivo es el analizador estático SonarQube. En este artículo describiremos la exitosa experiencia de integración fluida del analizador estático SonarQube en los procesos de desarrollo de nuestro departamento.
Resumen del departamento
Nuestra competencia incluye los siguientes módulos: pagos a clientes de NRD, flujo de documentos electrónicos (EDO), procesamiento de mensajes del depósito de comercio (registro de transacciones extrabursátiles), canales de interacción electrónica entre clientes y NRD y mucho más. En general, se trata de un gran volumen de trabajo en el aspecto técnico de la operación. Trabajamos sobre la base de solicitudes. Las solicitudes de los operadores son procesadas por analistas: recopilan los requisitos del cliente y nos presentan su visión de cómo debe implementarse en el programa. Luego, el esquema estándar: desarrollo de código - pruebas - explotación experimental - entrega de código al entorno productivo al cliente directo.
¿Por qué SonarQube?
Esta es la primera experiencia de nuestro departamento en la implementación de una plataforma para el control de calidad de código; anteriormente lo hacíamos manualmente, solo realizábamos revisiones de código. Sin embargo, el volumen creciente de trabajo requiere la automatización de este proceso. Además, en el equipo hay empleados inexpertos que no están completamente familiarizados con los procedimientos internos de desarrollo y tienden a cometer más errores. Se decidió implementar un analizador estático para el control de calidad del código. Dado que SonarQube ya había sido utilizado en algunos sistemas de NRD, no hubo mucho que elegir. Anteriormente, colegas de otros departamentos habían analizado con su ayuda el código de microservicios en el sistema 'Alameda' (sistema propio de contabilidad y compensación de NRD), en CFT (sistema de información para llevar contabilidad, balance, preparación de informes obligatorios e internos), entre otros sistemas. Para los experimentos, decidimos comenzar con la versión gratuita de SonarQube. Así que pasemos a nuestro caso.
Proceso de implementación
Tenemos:
- compilación automática del sistema en TeamCity;
- se ha configurado el proceso de subida de código a través de MergeRequest desde la rama feature a la rama master en GitLab (proceso de desarrollo según GitHub Flow);
- SonarQube, configurado para el análisis de código del sistema DPO según un cronograma.
Nuestro objetivo: implementar análisis automático de código en los procesos CI/CD del DPO.
Necesitamos configurar: el proceso de verificación automática del código mediante el analizador estático en cada MergeRequest hacia la rama principal.
Es decir, el objetivo es el siguiente: tan pronto como el desarrollador sube cambios a la rama feature, se inicia una verificación automática para detectar nuevos errores en el código. Si no hay errores, se permite aceptar los cambios; de lo contrario, será necesario corregir los errores. Ya en la etapa inicial, pudimos identificar una cierta cantidad de errores en el código. El sistema tiene configuraciones muy flexibles: se puede ajustar de tal manera que funcione según las tareas específicas de los desarrolladores, para cada sistema y estilo de programación.
Configuración de QualityGate en SonarQube
El análisis de QualityGate es algo que hemos leído en las profundidades de Internet. Inicialmente, utilizamos otro enfoque, más complicado y, de alguna manera, no del todo correcto. Primero, ejecutamos el escaneo a través de SonarQube dos veces: escaneamos la rama de características y la rama en la que íbamos a combinar la rama de características, y luego comparábamos la cantidad de errores. Este método no era estable y no siempre daba resultados precisos. Luego, descubrimos que en lugar de hacer un escaneo doble con SonarQube, se podía establecer un límite en la cantidad de errores permitidos (QualityGate) y analizar solo la rama que se está integrando y comparando.
Hasta ahora, utilizamos una verificación de código bastante primitiva. Cabe destacar que SonarQube no es compatible con algunos lenguajes de programación, incluido Delphi. Actualmente, para nuestro sistema solo analizamos código PLSql.
Funciona así:
- Para nuestro proyecto, solo analizamos código PL/SQL.
- QualityGate en SonarQube está configurado de manera que la cantidad de errores no aumenta con cada commit.
- La cantidad de errores en la primera ejecución fue de 229. Si el número de errores al hacer un commit aumenta, no se permite el merge.
- A continuación, si los errores son corregidos, se podrá reconfigurar QualityGate.
- También se pueden agregar nuevos ítems para el análisis, como la cobertura de código con pruebas, etc.
Esquema de trabajo:
En los comentarios de la ejecución del script se puede ver que la cantidad de errores en la rama de características no ha aumentado. Esto significa que todo está bien.
La botón de Merge se vuelve accesible.
En los comentarios de la ejecución del script se puede ver que la cantidad de errores en la rama de características ha superado el límite permitido. Esto significa que todo está MAL.
El botón de Merge está en rojo. Actualmente, no hay ninguna prohibición para realizar cambios en el código erróneo, pero esto queda a criterio del desarrollador responsable. En el futuro, se puede prohibir tales commits en la rama principal.
Trabajo autónomo en los errores
A continuación, es necesario verificar todos los errores detectados por el sistema, porque SonarQube analiza según sus estrictos estándares. Lo que considera un error, en realidad, puede no serlo en nuestro código. Por lo tanto, es necesario revisar y marcar si realmente es un error, o si no es necesario corregirlo en nuestras condiciones. De esta manera, reducimos la cantidad de errores. Con el tiempo, el sistema aprenderá a entender estas sutilezas.
A lo que hemos llegado
Nuestro objetivo era entender si tenía sentido traducir la verificación de código a la automatización en nuestro caso. Y los resultados cumplieron con las expectativas. SonarQube nos permite trabajar con los lenguajes que necesitamos, realiza un análisis bastante preciso y tiene el potencial de aprender de las sugerencias de los desarrolladores. En general, estamos satisfechos con nuestra primera experiencia utilizando SonarQube y planeamos seguir desarrollándonos en esta dirección. Esperamos que en el futuro podamos ahorrar más tiempo y esfuerzo en la verificación de código y mejorar su calidad, eliminando el factor humano. Es posible que en el proceso descubramos deficiencias de la plataforma o, por el contrario, reafirmemos que es una gran herramienta con un gran potencial.
En este artículo de revisión, compartimos nuestra experiencia con el analizador estático SonarQube. Si tienes preguntas, no dudes en dejarlas en los comentarios. Si te interesa el tema, en una nueva publicación describiremos más a fondo cómo configurarlo adecuadamente y escribir código para realizar dicha verificación.
Autor del texto:
Fuente: habr.com
