Nos gustaría compartir nuestra experiencia en la implementación de una plataforma para el análisis y la medición continua de la calidad del código SonarQube en los procesos existentes para desarrollar el sistema DPO (una adición al sistema de contabilidad de compensación y depositario de Alameda) del Depositario Nacional de Liquidaciones.
El Depósito Nacional de Liquidaciones (Grupo de Empresas de la Bolsa de Moscú) es una de las principales empresas de infraestructura financiera que almacena y registra valores de emisores rusos y extranjeros por valor de más de 50 billones de rublos. El creciente volumen de operaciones que realiza el sistema, así como el continuo aumento de funcionalidades, requieren mantener la alta calidad del código fuente de los sistemas. Una de las herramientas para lograr este objetivo es el analizador estático SonarQube. En este artículo, describimos la experiencia exitosa de implementar sin problemas el analizador estático SonarQube en los procesos de desarrollo existentes de nuestro departamento.
Brevemente sobre el departamento.
Nuestra competencia incluye los siguientes módulos: pagos a clientes de NSD, gestión de documentos electrónicos (EDF), procesamiento de mensajes del registro comercial (registro de transacciones fuera de bolsa), canales de interacción electrónica entre clientes y NSD, y mucho más. En general, una gran cantidad de trabajo en el aspecto técnico de las operaciones. Trabajamos en base a aplicaciones. Las solicitudes de los cajeros son procesadas por analistas: recopilan los requisitos del cliente y nos presentan su visión de cómo deberían encajar en el programa. Además, el esquema estándar: desarrollo del código - prueba - operación de prueba - entrega del código al circuito 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 del código; anteriormente lo hacíamos manualmente, solo revisión del código. Pero el creciente volumen de trabajo requiere la automatización de este proceso. Además, en el equipo también hay empleados sin experiencia que no están del todo familiarizados con las normas de desarrollo interno y tienden a cometer más errores. Para controlar la calidad del código se decidió implementar un analizador estático. Como SonarQube ya se ha utilizado en algunos sistemas NSD, no pasó mucho tiempo para elegir. Anteriormente, colegas de otras divisiones lo utilizaron para analizar el código de microservicios en el sistema Alameda (el propio sistema de contabilidad de depósito y compensación de NSD), en el CFT (sistema de información para contabilidad, balance, preparación de informes obligatorios e internos), en alguna otra sistemas. Para experimentar, decidimos comenzar con la versión gratuita de SonarQube. Pasemos entonces a nuestro caso.
Proceso de implementación
Aquí está nuestro país:
- montaje automático del sistema en TeamCity;
- configurar el proceso de carga de código a través de MergeRequest desde una rama de funciones a la rama maestra en GitLab (proceso de desarrollo según GitHub Flow);
- SonarQube configurado para analizar el código del sistema DPO según lo previsto.
Nuestro objetivo: implementar análisis automático de código en procesos CI/CD de AVE.
Necesidad de personalizar: el proceso de verificar automáticamente el código mediante un analizador estático con cada MergeRequest en la rama principal.
Aquellos. la imagen de destino es la siguiente: tan pronto como el desarrollador carga cambios en la rama de características, comienza una verificación automática de nuevos errores en el código. Si no hay errores, entonces se permite aceptar los cambios; de lo contrario, los errores deberán corregirse. Ya en la etapa inicial pudimos identificar una cierta cantidad de errores en el código. El sistema tiene configuraciones muy flexibles: se puede configurar de tal manera que funcione para tareas específicas de los desarrolladores, para cada sistema y estilo de programación.
Configurando QualityGate en SonarQube
El análisis QualityGate es algo que leemos en las entrañas de Internet. Inicialmente utilizamos un enfoque diferente, más complejo y, en algunos aspectos, no del todo correcto. Primero, ejecutamos el escaneo a través de SonarQube dos veces: escaneamos la rama de características y la rama donde íbamos a fusionar la rama de características, y luego comparamos la cantidad de errores. Este método no era estable y no siempre daba el resultado correcto. Y luego aprendimos que en lugar de ejecutar SonarQube dos veces, puedes establecer un límite en la cantidad de errores cometidos (QualityGate) y analizar solo la rama que subes y comparar.
Por ahora, todavía utilizamos una verificación de código bastante primitiva. Cabe señalar que SonarQube no es compatible con algunos lenguajes de programación, incluido Delphi. Por el momento, para nuestro sistema, analizamos sólo código PLSql.
Funciona así:
- Analizamos sólo código PL/SQL para nuestro proyecto.
- QualityGate está configurado en SonarQube para que el número de errores no aumente con el commit.
- La cantidad de errores en la primera ejecución fue 229. Si hay más errores durante la confirmación, no se permite la fusión.
- Además, sujeto a la corrección de errores, será posible reconfigurar QualityGate.
- También puede agregar nuevos elementos para análisis, por ejemplo, cobertura de código con pruebas, etc.
Esquema de trabajo:
En los comentarios del script, puede ver que la cantidad de errores en la rama de funciones no ha aumentado. Entonces todo está bien.
El botón Fusionar pasa a estar disponible.
En los comentarios del script, puede ver que la cantidad de errores en la rama de características ha superado lo permitido. Entonces todo es MAL.
El botón Fusionar es rojo. Por el momento, no existe ninguna prohibición de cargar cambios en código erróneo, pero esto se hace a discreción del desarrollador responsable. En el futuro, puede evitar que se realicen dichas confirmaciones en la rama principal.
Autogestión de errores
A continuación, es necesario comprobar todos los errores detectados por el sistema, porque SonarQube analiza según sus estrictos estándares. Lo que él considera un error puede no serlo en realidad en nuestro código. Por lo tanto, debe verificar y observar si esto es realmente un error o si no es necesario editarlo en nuestras condiciones. Así reducimos el número de errores. Con el tiempo, el sistema aprenderá a comprender estos matices.
A qué hemos llegado
Nuestro objetivo era comprender si en nuestro caso es conveniente transferir la verificación del código a la automatización. Y el resultado estuvo a la altura de las expectativas. SonarQube nos permite trabajar con los lenguajes que necesitamos, realiza análisis bastante competentes y tiene el potencial de aprender de los consejos de los desarrolladores. En general, estamos satisfechos con nuestra primera experiencia con SonarQube y planeamos seguir desarrollándonos en esta dirección. Esperamos que en el futuro podamos ahorrar más tiempo y esfuerzo en la revisión del código y mejorarlo eliminando el factor humano. Quizás en el proceso descubramos las deficiencias de la plataforma o, por el contrario, nos aseguremos una vez más de que se trata de algo interesante y con un gran potencial.
En este artículo de descripción general, hablamos sobre nuestro conocimiento del analizador estático SonarQube. Si tiene preguntas, escriba en los comentarios. Si está interesado en este tema, en la nueva publicación describiremos con más detalle cómo configurar todo correctamente y escribir código para realizar dicha verificación.
Autor del texto:
Fuente: habr.com