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 de la misma.
Haber alcanzado el 60% de los objetivos del tema introductorio tras haber realizado los ejercicios propuestos.
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 master, porque los tests son la especificación
de los requisitos. 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, 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.
Aunque más adelante habrá que hacer tests de todo el código que se vaya a desplegar, en este hito es suficiente con que se cree una biblioteca o clase, que será la base del servicio que se vaya a escribir, y que se hagan pasar los tests para la misma, sin necesidad de escribir un programa principal o servicio que los use (lo que habrá que hacer en hitos posteriores). Los tests son de funciones y unitarios, y como tales lo pasan las funciones. De hecho, en TDD (desarrollo basado en test) se escriben los tests antes que las funciones; continuando con la gestión del proyecto iniciada en el hito anterior, las especificaciones y las funcionalidades tendrán que estar en un issue y este en un hito.
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, una web gratuita de integración continua tal como Travis, Shippable o Circle. Habrá que darse de alta en ese sistema.
-
Automatizar la ejecución de los tests usando las herramientas de construcción o de gestión de tareas del lenguaje que se esté usando; por ejemplo, incluir un objetivo
make testdentro de unMakefile. Normalmente, estas tareas u órdenes son estándar para cada lenguaje y generalmente también Travis (o el sistema que elijáis) las ejecutará automáticamente salvo que le digas lo contrario. En algunos casos, como Python, las herramientas de construcción comopipsolo necesitarán un ficherorequirements.txtque instale las dependencias, si las hubiera; sin embargo, en otros lenguajes el fichero de tareas correspondiente permitirá especificar dependencias, versión del lenguaje, instrucción específica que se va a usar para hacer test y también metadatos adicionales como licencia o autor. -
Finalmente, tras darse de alta, configurar el sistema de integración continua de forma que lance los tests automáticamente. Se puede usar Travis-CI, Circle-CI, Jenkins, Shippable, 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 Travis será el obligatorio que se detectará automáticamente; si se va a usar otro sistema, consultar con los profesores). 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.
Esta fase de integración continua es esencial para el posterior despliegue en un PaaS o IaaS sobre el que se probarán técnicas de despliegue continuo.
Se tendrá que haber actualizado el repositorio que se usara en los hitos anteriores y añadir al fichero de este hito el nombre del proyecto, el autor y un enlace al mismo y hacer un pull request.
A partir de este hito, el README.md tiene que incluir, al principio,
una descripción real de la clase que se vaya a testear, como
instalarla y testearla y qué uso va a tener dentro del servicio (o
servicios) web que se van a desplegar más adelante. En un proyecto el
README.md debe estar escrito para la persona que llegue, y no para que
se corrija. Si hay documentación adicional, tendrá que enlazarse desde
este README.md. También tendrá que incluir, a partir de esta versión, el
badge de Travis que indica si se han pasado los tests correctamente
o no.
Si se va usar otro sistema de integración continua, avisar al profesor para que añada lo necesario a los tests.
En la documentación de este hito, que se enlazará como el resto en el README.md
del proyecto, se explicará por qué se ha elegido
las bibliotecas y programas de test y
de integración continua; por lo escrito en el párrafo anterior, se
aconseja que se haga como páginas de GitHub
en alguna de las formas que este lo permite o, en cualquier caso,
externo al README.md (y siempre enlazado desde el mismo), que deberá ser lo más conciso posible para el
visitante casual (sin dejar de incluir enlaces claros para que quien
corrija el hito pueda encontrarlos fácilmente).
Se recuerda que es prerrequisito haber llevado a cabo el 60% de los objetivos del tema correspondiente de la asignatura y del resto de las sesiones hasta el momento de la entrega. En caso contrario no se evaluará este hito del proyecto. Como es habitual, se recuerda al alumno que no se trata simplemente de marcar las cosas que se tienen que hacer para este hito, sino que al proyecto en esta etapa refleje que se ha entendido correctamente el concepto de un proyecto integrado de forma continua.
Si se cumplen los requisitos, la puntuación será:
- 3 puntos: Configuración correcta de herramientas de construcción y prueba y correcta justificación de las mismas.
- 4 puntos: Integración continua funcionando y correcta justificación de la misma. Para conseguir los 4 puntos, habrá que configurar algún sistema adicional aparte de Travis.
- 3 puntos: Tests significativos y/o avance del proyecto en sí más allá de lo básico.
Si la integración continua no funciona la práctica estará suspensa en cualquier caso, aunque se hayan configurado correctamente las herramientas de construcción.
Se podrá bajar la calificación si
- Se ha abierto más de una vez el PR de entrega.
- Si en el PR aparecen merge commits de actualización del repositorio del estudiante.
- Si se entregan los objetivos y el hito en el mismo PR.
Se recuerda también que este es un hito de un proyecto, y como tal los tests para este hito incluyen los de todos los anteriores; el proyecto tendrá que seguir desarrollándose de acuerdo a lo indicado en el hito anterior y tener como mínimo la estructura que se creó en el hito 0.
En este último caso no hay por qué alterar nada, aunque sí si se decide, a mitad de la asignatura, cambiar de proyecto. Los tests se pasan para todos los hitos, así que habrá que tenerlo en cuenta.