Integración continua para verificar modelos de Simulink
Por David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch y Jemima Pulipati, MathWorks
Si está utilizando la versión R2022a o posterior y tiene una licencia de Simulink Check™, puede optimizar la integración de CI con el paquete de soporte de CI/CD Automation for Simulink Check. Con el paquete de soporte, puede definir un modelo del proceso para su equipo de trabajo y configurar el sistema de CI para ejecutarlo automáticamente como una cadena de tareas de CI. El paquete incluye soporte para varias plataformas de CI, lo que permite generar automáticamente tareas específicas de un proyecto y proceso, sin necesidad de actualizaciones manuales.
Características principales
- Tareas integradas: Automatice tareas comunes en su flujo de trabajo de desarrollo y verificación basado en modelos mediante tareas integradas para verificar estándares de modelado con Model Advisor, ejecutar pruebas con Simulink Test™ y generar código con Embedded Coder®. En lugar de administrar varios scripts para actividades de desarrollo y verificación, puede reconfigurar y utilizar estas tareas integradas para lograr una ejecución fluida y resultados de tareas organizados.
- Compilaciones incrementales: Identifique el impacto de un cambio en un proyecto y vuelva a ejecutar automáticamente solo las tareas afectadas para optimizar la eficiencia de la compilación. La app Process Advisor y su sistema de compilación vuelve a ejecutar las tareas con resultados desactualizados y omite automáticamente las tareas que están actualizadas.
- Generación automática de cadenas de tareas: Utilice el archivo de plantilla del paquete de soporte para generar cadenas de tareas automáticamente, de modo que no necesite actualizar manualmente los archivos de configuración de CI/CD cuando realice cambios en un proyecto o proceso. Puede personalizar fácilmente la configuración del generador de cadenas de tareas para separar tareas en diferentes trabajos, ejecutar tareas de modelo en paralelo y cambiar otros comportamientos de la cadena de tareas.
Para obtener más información, consulte Integración continua e Integrar con Jenkins.
Este artículo está dividido en dos parte. La parte 1 analiza cómo aprovechar GitLab® para control de versiones y Jenkins® para la integración continua (IC). La parte 2 analiza la integración continua para verificar modelos de Simulink con GitLab, tanto para el control de versiones como para la integración continua.
La integración continua (CI) está ganando popularidad y se está convirtiendo en una parte integral del diseño basado en modelos. Pero ¿qué es CI? ¿Cuáles son sus beneficios y qué problemas puede resolver? ¿Cómo se puede utilizar Simulink® en el ecosistema de CI? ¿Cómo puede aprovechar la CI al máximo en proyectos?
Si está familiarizado con el diseño basado en modelos pero tiene poca experiencia en CI, tal vez se haga estas preguntas. Este artículo técnico explora un flujo de trabajo de CI común aplicado al diseño basado en modelos. Analiza un ejemplo del flujo de trabajo utilizando Jenkins, GitLab y Simulink Test.
El proyecto utilizado en este ejemplo se encuentra disponible para su descarga.
¿Qué es CI?
CI es una práctica recomendada de metodología ágil en la que los desarrolladores envían y fusionan periódicamente cambios en el código fuente en un repositorio central. Estos “conjuntos de cambios” se crean, califican y publican automáticamente. La figura 1 ilustra este flujo de trabajo de CI básico junto con el flujo de trabajo de desarrollo.
En la parte de desarrollo del flujo de trabajo, los modelos y las pruebas se desarrollan, verifican, fusionan, revisan y envían a un sistema de control de versiones en el equipo del desarrollador. Luego, el sistema de control de versiones activa la CI automatizada del flujo de trabajo. Las partes clave del flujo de trabajo de CI son:
Compilar: El código fuente y los modelos se convierten en archivos objeto y ejecutables.
Probar: Las pruebas se realizan como punto de control de calidad.
Empaquetar: Los ejecutables, la documentación, los artefactos y otros componentes entregables se agrupan para su entrega a usuarios finales.
Desplegar: Los paquetes se despliegan en el entorno de producción.
El conjunto de estos cuatro pasos se denomina "cadena de tareas" de CI. El proceso suele automatizarse y tardar entre minutos y días en completarse, según el sistema. Cabe señalar que a lo largo de estos pasos se crean numerosos artefactos, como listas de materiales, resultados de pruebas e informes.
Los flujos de trabajo de CI a menudo se combinan con flujos de trabajo de desarrolladores relacionados con los sistemas de control de versiones. En estos flujos de trabajo, los desarrolladores a menudo mantienen cambios en repositorios locales y utilizan una cadena de tareas de CI local para calificar sus cambios antes de desplegarlos.
Beneficios de la CI
Los equipos que han implementado CI suelen encontrar esto beneficios:
- Repetibilidad. La cadena de tareas de CI proporciona un proceso automatizado uniforme y repetible para compilar, probar, empaquetar y desplegar código. La automatización repetible permite a los desarrolladores centrarse en actividades necesarias y ahorrar tiempo en un proyecto. También es un aspecto importante de la reducción de riesgos y a menudo es un requisito para la certificación.
- Garantía de calidad. Las pruebas manuales son efectivas, pero a menudo se basan en instantáneas de días anteriores y carecen de repetibilidad. Con CI, los cambios siempre se prueban con la base de código más reciente.
- Tiempo de desarrollo reducido. Los procesos repetibles con garantía de calidad incorporada permiten una entrega más rápida de productos de alta calidad. El despliegue automatizado implica que el código siempre está listo para producción.
- Colaboración mejorada. Con CI, los desarrolladores tienen un proceso definido para gestionar conjuntos de cambios y fusionar código en la línea de producción. Los procesos consistentes hacen posible la gestión de grandes equipos de trabajo y reducen el costo de contratar nuevos desarrolladores.
- Código listo para auditoría. El flujo de trabajo de CI proporciona un registro de auditoría extenso. Por cada cambio que se realiza a través de la cadena de tareas de CI, es posible identificar quién realizó el cambio, quién lo revisó, el tipo de cambio, las dependencias, las pruebas y sus resultados, y varios informes y artefactos generados sobre la marcha.
¿Cómo se integra el diseño basado en modelos con CI?
Por diseño, el flujo de trabajo y las herramientas de CI admiten varios lenguajes y dominios. Esto significa que el desafío radica en enseñar a herramientas, sistemas y procesos de CI a comunicarse con el diseño basado en modelos; es decir, hacer que Simulink y las herramientas relacionadas sean la lengua franca del flujo de trabajo de CI.
Esto se puede lograr integrando tres componentes clave del diseño basado en modelos en el flujo de trabajo de CI: verificación, generación de código y pruebas (Figura 2). El diseño basado en modelos pone énfasis en la verificación temprana, que se corresponde con la cadena de tareas de CI con una fase de verificación antes de la fase de compilación. La generación de código tiene lugar en la fase de compilación. En la fase de prueba se realizan pruebas dinámicas mediante simulación y análisis estático del código generado.
Esta es una descripción general de cómo enseñar al flujo de trabajo de CI a comunicase con el diseño basado en modelos:
Desarrollar. MATLAB®, Simulink, codificadores y toolboxes se utilizan para actividades de desarrollo. MATLAB Projects se utiliza para organizar el trabajo, colaborar e interactuar con sistemas de control de versiones.
Probar. Simulink Check se utiliza para realizar controles de calidad del modelo antes de la simulación y la generación de código. Simulink Test se utiliza para desarrollar, gestionar y ejecutar pruebas basadas en simulación. Simulink Coverage™ se utiliza para medir la cobertura y evaluar la eficacia de las pruebas. Los controles de calidad, los resultados de las pruebas y las métricas de cobertura se utilizan como un punto de control de calidad para que los desarrolladores califiquen su trabajo.
Fusionar. La funcionalidad de comparar archivos y carpetas de MATLAB se utiliza para comparar y fusionar archivos de MATLAB. Model Comparison Tool se utiliza para comparar y fusionar modelos de Simulink.
Revisar. La revisión es el paso final del proceso de calidad antes de que los cambios se envíen al sistema de control de versiones. Aquí se revisan los cambios en los scripts de MATLAB y los modelos de Simulink. Los resultados de las pruebas de precalificación también se revisan como un punto de control de calidad final antes del envío de código.
Enviar. MATLAB Projects proporciona una interfaz a los sistemas de control de versiones.
Verificar. Simulink Check, la misma herramienta utilizada para la verificación local, se utiliza para la verificación automatizada dentro del sistema CI.
Compilar. MATLAB Coder™, Simulink Coder™ y Embedded Coder se utilizan para generar código para pruebas de software-in-the-loop (SIL).
Probar. Simulink Test, la misma herramienta utilizada para las pruebas locales, se utiliza para las pruebas automatizadas dentro del sistema CI.
Empaquetar y desplegar. El empaquetado es el proceso de agrupar los ejecutables, la documentación, los artefactos y otros componentes entregables para su entrega a usuarios finales. El despliegue es el lanzamiento de software empaquetado. En los flujos de trabajo de diseño basado en modelos, estas fases varían ampliamente entre organizaciones y grupos, y a menudo implican la agrupación de diferentes compilaciones y artefactos de certificación en un producto listo para ser entregado a otros equipos.
Las herramientas y prácticas de desarrollo modernas permiten a los desarrolladores crear sistemas más robustos y probar la funcionalidad de forma temprana y frecuente. Cuando un sistema de CI se integra en el flujo de trabajo, se automatizan las pruebas en nivel de unidad y en nivel de sistema. Esto significa que el desarrollador puede centrarse en desarrollar nuevas funciones, no en verificar que las funciones se hayan integrado correctamente.
El siguiente caso práctico describe un flujo de trabajo que incorpora CI y diseño basado en modelos.
Caso práctico: Modelo de Simulink verificado, compilado y probado dentro de un sistema de CI
Este ejemplo utiliza el diseño basado en modelos con CI para realizar pruebas basadas en requisitos en un sistema de seguimiento de carril de automóviles (Figura 3).
La cadena de tareas (Figura 4) se ejecuta con cada compilación de Jenkins.
Figura 4. Cadena de tareas para un ejemplo de seguimiento de carril.
Las fases de la cadena de tareas son las siguientes:
- Verificar el cumplimiento de normas: Un script unitario de MATLAB ejecuta una simple comprobación de Model Advisor. Los criterios de evaluación garantizan que el modelo no tenga líneas no conectadas.
- Compilar el modelo: Un archivo de prueba unitaria de MATLAB compila código de SIL de producción para el modelo. Los criterios de evaluación se superan si la compilación se realiza correctamente sin advertencias.
- Ejecutar casos de prueba: Un conjunto de pruebas en Simulink Test utiliza varios escenarios de conducción para probar el controlador de seguimiento de carril. Se utilizan tres criterios de evaluación para verificar el funcionamiento satisfactorio del controlador:
- Evasión de colisiones: El vehículo ego no choca con el vehículo líder en ningún momento durante el escenario de conducción.
- Mantenimiento de la distancia de seguridad: La diferencia de tiempo entre el vehículo ego y el vehículo líder es superior a 1,5 segundos. La diferencia de tiempo entre los dos vehículos se define como la relación entre la distancia calculada y la velocidad del vehículo ego.
- Seguimiento de carril: La desviación lateral respecto de la línea central del carril es de 0,2 metros.
- Empaquetar artefactos: Cada una de las etapas anteriores genera artefactos, como un informe de Model Advisor, un ejecutable y un conjunto de resultados de pruebas que se pueden archivar para uso o referencia futuros.
Pasos del flujo de trabajo
El flujo de trabajo consta de los siguientes pasos (Figura 5):
- Activar una compilación en Jenkins y comprobar que las etapas de verificación y compilación se superan con éxito.
- Detectar un fallo en el caso de prueba en Jenkins.
- Reproducir el problema en MATLAB Desktop.
- Solucionar el problema en el modelo reduciendo los criterios de evaluación.
- Realizar pruebas locales para garantizar que el caso de prueba se supera con éxito.
- Fusionar y revisar los cambios en la rama de prueba.
- Confirmar el cambio en Git™ y desencadenar una compilación en Jenkins.
- Verificar, compilar y probar en Jenkins.
En la parte superior izquierda se observa el fallo del primer paso de la cadena de CI. Además, el fallo de la prueba CI, la reproducción local, la reducción de criterios y la finalización del flujo de trabajo de CI con éxito.
Detalles del flujo de trabajo
- Primero, se activa una compilación en Jenkins seleccionando Build Now. Las comprobaciones de Simulink Check y la generación de código se superan con éxito.
![Menú desplegable del panel de Jenkins. Se ha seleccionado Build Now.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1314375792.adapt.full.medium.jpg/1739442251313.jpg)
- Luego, se detecta un fallo en el caso de prueba en la segunda fase de verificación. El caso de prueba
LFACC_Curve_CutInOut_TooClose
en el conjunto de pruebasELaneFollowingTestScenarios
no cumple con los criterios de evaluación.
![Imagen de un resumen de fallos.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1274891353.adapt.full.medium.jpg/1739442251334.jpg)
- Para comprender la causa del fallo, se reproduce localmente usando Simulink Test. Se abre el archivo de prueba
LaneFollowingTestScenarios.mldatx
y se ejecuta el caso de pruebaLFACC_Curve_CutInOut_TooClose
. Los criterios de evaluación de distancia de seguridad fallan. Se requiere más flexibilidad para establecer la diferencia de tiempo entre el vehículo líder y el vehículo ego.
![Ventana de Simulink Test con los criterios de evaluación superados.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_421698181.adapt.full.medium.jpg/1739442251348.jpg)
- Con una comprensión del problema, ahora se puede encontrar una solución. Abra el modelo
LaneFollowingTestBenchExample.slx
y vaya al bloque Collision Detection/Test Assessments Test Sequence. La primera evaluación confirma que la diferencia de tiempo entre el vehículo ego y el vehículo líder no debe caer por debajo de 1,5 segundos durante más de 2 segundos seguidos.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 1.5s for more than 2s at a time. verify(duration(time_gap < 1.5, sec) < 2); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
Esta evaluación es demasiado restrictiva para la maniobra de conducción que se está probando. Para este ejemplo, se reducen los criterios de evaluación para garantizar que la diferencia de tiempo no caiga por debajo de 0,8 segundos durante más de 5 segundos a la vez.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 0.8s for more than 5s at a time. verify(duration(time_gap < 0.8, sec) < 5); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
- El problema está solucionado en la simulación. Para confirmarlo, se prueba localmente, guardando el modelo y volviendo a ejecutar la prueba en el administrador de pruebas. Observe que los nuevos criterios de evaluación ahora se superan con éxito.
![Ventana de Simulink Test con los criterios de evaluación superados.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_915256185.adapt.full.medium.jpg/1739442251370.jpg)
- El problema se ha solucionado y verificado localmente. Con Model Comparison Tool, se revisan los cambios antes de enviarlos al control de versiones.
![Comparación de cambios anteriores y nuevos dentro de Model Comparison Tool.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2114472669.adapt.full.medium.jpg/1739442251388.jpg)
También se puede usar la función Publish de Model Comparison Tool para revisar el código.
![Comparación de cambios anteriores y nuevos con la función Publish de Model Comparison Tool.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_1389600109.adapt.full.medium.jpg/1739442251409.jpg)
- Una vez corregido el error, se envían los cambios a GitLab con MATLAB Projects y un mensaje de confirmación para indicar el cambio en los criterios de evaluación.
Luego aparece la última confirmación en GitLab.
GitLab activa automáticamente una compilación en Jenkins. El panel Jenkins de proyecto muestra el estado y progreso de la compilación.
![Panel del proyecto de Jenkins que muestra el estado y progreso con una barra de progreso.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1160520298.adapt.full.medium.jpg/1739442251447.jpg)
- Una vez ejecutada la compilación de Jenkins, se comprueba que las fases de la cadena de tareas verificar, compilar y probar ahora se superan con éxito.
A continuación, se inicia una solicitud para fusionar los cambios de la rama de prueba con la rama principal. En GitLab, en Repository, se selecciona Branches y se hace clic en Merge request en la última comprobación de la rama de prueba.
Se rellena un campo y se envía la solicitud de fusión.
Los responsables de la rama aceptan la solicitud de fusión haciendo clic en el botón Merge. Todos los cambios ahora se capturan en la rama principal.
![Mensaje de solicitud de fusión exitosa.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2099516143.adapt.full.medium.jpg/1739442251486.jpg)
Herramientas, recursos y requisitos usados en el ejemplo
Las siguientes secciones describen los recursos y herramientas que le ayudarán a iniciar proyectos, y cómo configurarlos.
Configuración de sistemas
Jenkins es el sistema de CI y GitLab el sistema de control de versiones. MATLAB, Jenkins y GitLab deben configurarse para trabajar juntos. Los siguientes tutoriales le ayudarán con la configuración.
Los tutoriales son específicos de GitLab y Jenkins, pero los conceptos pueden aplicarse a otros sistemas de control de versiones y CI.
Herramientas necesarias
Para este ejemplo se requieren las siguientes herramientas:
- Jenkins versión de instalación 2.7.3 o posterior. Jenkins se utiliza para la integración continua.
- Complemento de MATLAB para Jenkins versión 1.0.3 o posterior. MATLAB, Simulink y Simulink Test aprovechan este complemento para comunicarse con Jenkins. Obtenga más información en GitHub.
- Complementos adicionales necesarios:
- Cuenta de GitLab. GitLab se utiliza para el control de código fuente y está disponible como un servicio en la nube. MATLAB Projects incluye una interfaz Git para comunicarse con GitLab.
Consideraciones sobre la licencia para CI
Si planea realizar CI en muchos hosts o en la nube, comuníquese con continuous-integration@mathworks.com para solicitar ayuda. Nota: Los productos transformacionales MATLAB y Simulink Coder requieren una licencia de acceso de cliente (CAL).
Apéndice: Configuración de MATLAB, GitLab y Jenkins
Paso 1. Configurar MATLAB Projects para utilizar el control de código fuente
El primer paso del ejemplo es configurar el proyecto para usar el control de código fuente con GitLab.
- Cree un nuevo directorio llamado
MBDExampleWithGitAndJenkins
, cargue el ejemplo y abra MATLABProject MBDExampleWithGitAndJenkins.prj
. - En GitLab, cree un nuevo proyecto que será el repositorio remoto. Asígnele el nombre
MBDExampleWithGitAndJenkins
y registre la URL donde está alojado. - En MATLAB, convierta el proyecto para utilizar control de código fuente. En la pestaña Project, haga clic en Use Source Control.
![Pestaña Proyect en MATLAB, con el botón Use Source Control button seleccionado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1426591191.adapt.full.medium.jpg/1739442251510.jpg)
Haga clic en Add Project to Source Control.
![Ventana emergente Source Control Information. La integración está configurada como None y la ubicación del repositorio no es aplicable (N/A). Indica que no se detectó ningún sistema de control de fuente en la raíz del proyecto y tiene un botón para agregar el proyecto al control de fuente.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1616796560.adapt.full.medium.jpg/1739442251528.jpg)
- Haga clic en Convert.
![Ventana emergente Add to Source Control. Se selecciona la herramienta de control de fuente Git y se proporciona la raíz del proyecto. Se usa el botón Convert.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_711112368.adapt.full.medium.jpg/1739442251546.jpg)
- Cuando haya terminado, haga clic en Open Project.
![Imagen que muestra los archivos que se agregan al control de origen. Los archivos han pasado todas las comprobaciones y aparece un botón Open Project. Aparece un menú de Git con varios botones y logística.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1843929107.adapt.full.medium.jpg/1739442251571.jpg)
El proyecto se encuentra en el control del código fuente local de Git.
Paso 2. Confirmar cambios y enviar el repositorio local a GitLab
- En la pestaña Project, haga clic en Remote.
![Pestaña MATLAB Project con Remote resaltado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1131172368.adapt.full.medium.jpg/1739442251594.jpg)
- Especifique la URL del origen remoto en GitLab.
![Ventana emergente Set Remote. Contiene un campo para especificar una URL para el origen remoto. La URL proporcionada está borrosa y el botón Validate junto con un botón OK están en la parte inferior.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1715246667.adapt.full.medium.jpg/1739442251613.jpg)
Haga clic en Validate para garantizar que la conexión al repositorio remoto sea exitosa y haga clic en OK. El proyecto ahora está configurado para enviar y recibir cambios con GitLab.
- Haga clic en Commit para realizar una confirmación inicial.
![Pestaña MATLAB Project con el botón Commit resaltado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_176678025.adapt.full.medium.jpg/1739442251637.jpg)
![Ventana de comentarios con el mensaje de confirmación.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2080776722.adapt.full.medium.jpg/1739442251649.jpg)
- Haga clic en Push para enviar todos los cambios del repositorio local al repositorio remoto de GitLab.
![Pestaña MATLAB Project con el botón Push seleccionado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1335693290.adapt.full.medium.jpg/1739442251667.jpg)
- Actualice el panel de GitLab y observe el contenido del proyecto de MATLAB.
Paso 3. Crear una rama de prueba
En este paso, se crea una rama de prueba para probar y verificar los cambios antes de fusionarlos con la rama principal.
- Haga clic en Branches.
![Pestaña MATLAB Project con el botón Branches seleccionado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1687868341.adapt.full.medium.jpg/1739442251706.jpg)
- Amplíe la sección Branch and Tag Creation, asigne el nombre “Test” a la rama y haga clic en Create.
- Observe Test en Branch Browser. En la rama Test, haga clic en Switch y luego en Close.
- En MATLAB, seleccione Push para enviar estos cambios a GitLab y observar la rama de prueba en GitLab.
Paso 4. Configurar Jenkins para llamar a MATLAB
- Instale dos complementos necesarios:
- GitLab plugin: Este complemento permite a GitLab activar compilaciones de Jenkins y mostrar resultados en la interfaz de GitLab.
- MATLAB plugin: Este complemento integra MATLAB con Jenkins y proporciona la interfaz de Jenkins para llamar a MATLAB y Simulink.
- Seleccione New Item y cree un nuevo proyecto FreeStyle denominado
MBDExampleUsingGitAndJenkins
. - En Source Code Management, habilite Git, apunte Jenkins al repositorio GitLab e ingrese a la rama Test para compilar. Nota: Requiere nombre de usuario o contraseña y token de API de GitLab.
- Configure el activador de compilación para ejecutar una compilación cuando se realiza una solicitud de inserción a la rama de prueba en GitLab. En la sección Build Triggers, seleccione Advanced > secret token. GitLab utiliza este token para solicitar una compilación y autenticarse con Jenkins. Tome nota del token secreto y el webhook de GitLab.
- Configure el entorno de compilación. Seleccione Use MATLAB version e ingrese la raíz de MATLAB.
- Configure el paso de compilación.
Haga clic en Add build step y seleccione Run MATLAB Command. Introduzca el comando openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecModelAdvisor
para abrir el proyecto y ejecutar comprobaciones de Model Advisor.
Haga clic en Add build step y seleccione Run MATLAB Command de nuevo. Introduzca el comando: openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild.
Haga clic en Add build step y seleccione Run MATLAB Tests. Seleccione TAP test results y Cobertura code coverage para completar la configuración de la compilación.
Esta acción analiza los resultados de la prueba TAP y los hace visibles cuando TAP Extended Test Results está seleccionado. La salida contiene una descripción general de los casos de prueba ejecutados, el resumen de resultados y los registros de la consola de MATLAB.
![Menú desplegable en el tablero con “TAP Extended Test Results” resaltado.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_361369158.adapt.full.medium.jpg/1739442252043.jpg)
El complemento TAP también recopila los resultados de las últimas ejecuciones de pruebas y despliega un diagrama de estado, como se muestra a continuación. Puede acceder a cualquier compilación anterior haciendo clic en el diagrama.
![Gráfico de los resultados de la prueba TAP que muestra el número de compilación de Jenkins en el eje x y el número de pruebas TAP en el eje y. Las pruebas están codificadas por colores como no superadas, superadas, omitidas o pendientes. A medida que aumenta el número de compilación, aumenta el número de pruebas superadas.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1468401417.adapt.full.medium.jpg/1739442252081.jpg)
Paso 6. Publicar informes HTML
Haga clic en Add post-build action > Publish HTML reports. Ingrese la ruta raíz relativa donde se publicará el informe HTML y el nombre del archivo de la página de índice que se encuentra en la ruta.
Agregue tantas entradas como informes HTML desee publicar. En este escenario, hay dos informes web: Model Advisor Summary y Code Generation Report. Estos son informes estándar creados con funciones integradas de MATLAB. Puede agregar informes HTML personalizados.
Encontrará un enlace de informe correspondiente a la última compilación por cada informe HTML en la página principal de trabajo de Jenkins. Si activa la casilla de verificación “Always link to last build” en Publishing options el complemento publicará informes de la última compilación independientemente del estado de la compilación. Si esta casilla no está activada, el complemento solo se vinculará a la última compilación “exitosa”.
Paso 7. Configurar GitLab para activar una compilación en Jenkins
Configure GitLab para activar una compilación automática en Jenkins cuando se produzca un nuevo envío a la rama principal. Para ello, vaya a Settings > Webhooks. Utilice la URL del webhook y el token secreto proporcionado por Jenkins en la configuración de Build Trigger y seleccione Push events.
Nota: Utilice un nombre de dominio completo en la sección URL en lugar de localhost para que GitLab pueda encontrar la instalación de Jenkins.
![Ventana emergente de Webhooks con el campo de URL completo, el campo Secret Token sin completar y “Push Events" marcado en “Trigger” con un campo para completar el activador.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1428097271.adapt.full.medium.jpg/1739442252180.jpg)
En el menú desplegable Test, seleccione Push Events para probar la integración. GitLab mostrará un mensaje que Hook se ha ejecutado exitosamente y Jenkins iniciará una compilación.
![Ventana emergente Project Hooks con los detalles del webhook habilitados.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_2045155438.adapt.full.medium.jpg/1739442252200.jpg)
Paso 8. Configurar la autenticación Jenkins-GitLab
Para publicar un estado de compilación de Jenkins automáticamente en GitLab, debe configurar la autenticación entre Jenkins y GitLab.
- Cree un token de acceso personal en GitLab y seleccione el Scope API.
![Ventana emergente Personal Access Tokens con campos para agregar nombre, fecha de vencimiento y alcance del token GitLabToJenkins. En “Scopes”, está marcada la opción “api”, que otorga acceso completo de lectura/escritura a la API.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_1313549631.adapt.full.medium.jpg/1739442252219.jpg)
- Copie el token y cree una conexión a GitLab en Jenkins Configure System.
Nota: Las conexiones se pueden reutilizar en múltiples trabajos de Jenkins y se pueden configurar globalmente si el usuario tiene al menos derechos para “mantener”.
Paso 9. Integrar Jenkins en la cadena de tareas de GitLab
Para integrar Jenkins en la cadena de tareas de GitLab, debe configurar la conexión de GitLab en Jenkins y publicar el estado del trabajo en GitLab.
- Seleccione GitLab Connection en la sección General del trabajo de Jenkins.
- Agregue una acción posterior a la compilación para publicar el estado de la compilación en GitLab.
Nota: Esta acción no tiene parámetros y utilizará la conexión GitLab existente para publicar el estado de la compilación en GitLab y crear trazabilidad bidireccional para cada solicitud de confirmación y fusión.
![Captura de pantalla de la acción posterior a la compilación agregada: Publish build status to GitLab. Y un botón para opciones avanzadas.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_702713251.adapt.full.medium.jpg/1739442252276.jpg)
Paso 10. Visualizar métricas de pruebas basadas en requisitos (R2020b)
Las métricas de prueba basadas en requisitos permiten evaluar el estado y la calidad de las actividades de pruebas basadas en requisitos. Los resultados de las métricas se pueden visualizar en Model Testing Dashboard.
- Cree un archivo llamado
collectModelTestingResults.m
basado en la función que se muestra a continuación. Esta función inicializará la infraestructura del motor de métricas y recopilará todas las métricas del modelo disponibles.
function collectModelTestingResults() % metric capability added in R2020a if exist('metric') metricIDs = [... "ConditionCoverageBreakdown" "CoverageDataService"... "DecisionCoverageBreakdown" "ExecutionCoverageBreakdown"... "MCDCCoverageBreakdown" "OverallConditionCoverage"... "OverallDecisionCoverage" "OverallExecutionCoverage"... "OverallMCDCCoverage" "RequirementWithTestCase"... "RequirementWithTestCaseDistribution" "RequirementWithTestCasePercentage"... "RequirementsPerTestCase" "RequirementsPerTestCaseDistribution"... "TestCaseStatus" "TestCaseStatusDistribution"... "TestCaseStatusPercentage" "TestCaseTag"... "TestCaseTagDistribution" "TestCaseType"... "TestCaseTypeDistribution" "TestCaseWithRequirement"... "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... ]; % collect all metrics for initial reconcile E = metric.Engine(); execute(E, metricIDs); end end
- Añada este archivo al proyecto y la ruta.
- Configure Jenkins para recopilar resultados de métricas llamando a
new collectModelTestingResults function
dos veces. La primera llamada inicializa la integración de métricas con Simulink Test Manager. La segunda recopila los resultados de las métricas utilizando los resultados exportados de Simulink Test Manager.- Haga clic en Add build step y seleccione Run MATLAB Command de nuevo. Introduzca el comando:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Coloque este paso de compilación antes del paso de compilación Run MATLAB Tests. - Haga clic en Add build step y seleccione Run MATLAB Command de nuevo. Ingrese el comando nuevamente:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Coloque este paso de compilación después del paso de compilación Run MATLAB Tests.
- Haga clic en Add build step y seleccione Run MATLAB Command de nuevo. Introduzca el comando:
- Marque Simulink Test Manager results en el paso de compilación Run MATLAB Tests
![Ventana emergente del paso de compilación. El campo Simulink Test Manager está completo con la ruta del archivo.](https://la.mathworks.com/company/technical-articles/continuous-integration-for-verification-of-simulink-models/_jcr_content/mainParsys/image_0_copy_copy_co_897862517.adapt.full.medium.jpg/1739442252355.jpg)
- Archive los resultados de las métricas en el directorio derivado. También debe archivar los resultados exportados del administrador de pruebas, ya que permitirán una navegación completa de los resultados de las métricas cuando se carguen nuevamente en MATLAB.
Haga clic en Add post-build action y seleccione Archive the artifacts. Introduzca la ruta derived/**,matlabTestArtifacts/*.mldatx
para archivar todos los archivos guardados en ese directorio.
Nota: Para ver estos resultados en MATLAB en un equipo diferente al de prueba:
- Descargue los artefactos archivados (directorio derivado y archivos MLDATX de resultados de pruebas).
- Extraiga y copie en una copia local la misma versión del proyecto que se utilizó para ejecutar el trabajo de CI.
- Abra el proyecto en MATLAB e inicie Model Testing Dashboard.
Los resultados generados por CI aparecerán en el panel.
Jenkins® es una marca registrada de LF Charities Inc.
Publicado en 2024