El principal objetivo de este hito del proyecto es añadir integración continua al mismo. Los tres subobjetivos son aprender cómo describir la versión del lenguaje de programación que se usa en el proyecto y la infraestructura que necesita para funcionar, así como la elección de un sistema y sitio para integración continua y configuración del mismo.
Haber superado los tests en el objetivo anterior, contenedores.
En sistemas de desarrollo ágil quien desarrolle tiene que asegurar que el código pasa todos los tests antes de ser desplegado o simplemente incorporado a la rama principal, porque los tests son la especificación de los requisitos expresados en la historia de usuario. Para ello se escriben una serie de tests que se ejecutan automáticamente al añadir o modificar código o cuando se solicite un pull request. Estos tests tienen el fin obvio de asegurar la calidad del mismo (via implementación de las pruebas para que se cumplan las historias de usuario), pero también en un entorno de desarrollo colaborativo permiten integrar código fácilmente asegurándose de que no se rompa nada. Si no está testeado, está roto, es el lema del desarrollador. Al ser la plasmación de las especificaciones, en cada incorporación de código la ejecución automática de los tests asegura que el código sigue cumpliendo las especificaciones. En este hito lo que haremos será configurar nuestro repositorio para que se pasen los tests, posiblemente en diferentes ambientes, automáticamente.
Preparar un proyecto para integración continua implica varias cosas:
-
Buscar un sistema online de prueba del código que sea estándar y flexible, es decir, las propias GitHub Actions de GitHub o un servicio gratuito (o freemium) de integración continua tal como Circle CI o Semaphore CI. Habrá que darse de alta en ese sistema, o en el caso de GitHub Actions, simplemente incluir una acción en el directorio correspondiente.
-
Finalmente, tras darse de alta, configurar el sistema de integración continua de forma que lance los tests automáticamente. Se puede Circle-CI o en general cualquier sistema que se pueda conectar a GitHub, es decir, que se active automáticamente al hacer un push a tu repositorio en GitHub (aunque Circle-CI será el obligatorio que se detectará automáticamente). También se pueden usar varios, GitHub envía automáticamente un mensaje a todos los sistemas configurados cuando se hace push, siempre que estén configurados.
-
Para que sean detectados correctamente por GitHub (y por los tests de la asignatura), habrá que configurar el sistema para que use el checks API.
Esta fase de integración continua es esencial para el posterior despliegue en la nube sobre el que se probarán técnicas de despliegue continuo (será el último objetivo de la asignatura).
Aviso: este es un caso en el que tanto el mismo GitHub como CoPilot pueden generar automáticamente el fichero de workflow completo, y sistemáticamente lo hacen mal. Aunque la asignatura está diseñada para que si se envía algo que no cumpla todas las condiciones se explique al estudiante qué problemas hay a través del PR, se ahorrará bastante trabajo tanto al estudiante como a los otros estudiantes que revisen el PR como al profesor si se hace a mano siguiendo el manual o algún tutorial, entendiéndose así mejor las diferentes partes del workflow y por supuesto la retroalimentación en el PR y cómo construir otros más complejos.
Como en los casos anteriores, hay que copiar, pegar y llevar a cabo en tu propio PR.
* [ ] ¿Se han establecido criterios *a priori* para elegir el sistema de
integración continua más conveniente y se han calificado los sistemas que
cumplan esos requisitos según esos criterios?
* [ ] ¿Se han examinado varios sistemas de integración continua?
* [ ] ¿Se han configurado varios sistemas de integración continua?
* [ ] ¿Se ha configurado correctamente el *Checks API* en los sistemas en los que
sea necesario para que aparezca correctamente en GitHub (y se pueda comprobar
desde los tests)?
* [ ] ¿Uno de los sistemas configurados permite comprobar cuales son las versiones
dellenguaje con las que funciona correctamente nuestra aplicación?
* [ ] ¿Se escogen de forma adecuada las versiones del lenguaje que se testean,
tanto en el sistema de CI como en el contenedor Docker?
* [ ] ¿Se han justificado correctamente las versiones del lenguaje que se están
testeando y se ha comprobado que no se comprueban varias veces lo mismo (la
misma versión en CI y en el contenedor Docker en otro sistema CI?
Se tendrá que haber actualizado el repositorio que se usara en los hitos anteriores y añadir al fichero de este objetivo el nombre del proyecto, el autor y un enlace al mismo y hacer un pull request. El PR tendrá que estar en un milestone/PMV, y por supuesto este tendrá que incluir como parte lo que se haya creado en este objetivo.
Habrá que añadir una nueva clave CI a iv.yml indicando el path del fichero
donde se ha configurado alguno de los sistemas de integración continua.
- Integración continua funcionando y correcta justificación de la misma.
- Uso correcto del gestor de tareas en todos los casos anteriores.
- Aprovechamiento del contenedor de Docker generado en el hito anterior en alguno de los sistemas de CI, especialmente si hay un cambio o adaptación del mismo.
El alcanzar este objetivo avanzará, en principio, 5% de la puntuación de este apartado.