Cuarto Hito: Integración continua

Descripción

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.

Evidentemente, objetivo secundario es saber administrar los créditos limitados de sistemas en la nube (en este caso, de integración continua) y tomar las medidas necesarias para que cundan lo más posible.

Prerrequisitos

Pasar los tests de todos los hitos hasta este mismo.

Explicación

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. 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 llevar a cabo las siguientes tareas:

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.

Entrega de la práctica

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.

Se recuerda que el fichero README.md del proyecto es la referencia para quien lea el mismo del estado en el que está, qué pasos va a seguir, y qué hay que hacer para instalarlo y usarlo. El material evaluable en la asignatura en las diferentes rúbricas deberá estar discretamente al final del mismo (antes de la licencia del proyecto, que siempre hay que incluir en el README) para facilitar su corrección.

Se comprobará que el fichero de Travis, .travis.yml, está en el directorio principal, y que se hayan pasado los tests de Travis a través de un test específico.

Esta comprobación falla a veces; si los tests de Travis están en verde y falla este test no hay que preocuparse. Ayuda que se ponga el badge de Travis (y cualquier otro) para que la comprobación visual sea lo más fácil posible.

Valoración

Si se cumplen los requisitos, la puntuación será:

  1. 4 puntos: Integración continua funcionando y correcta justificación de la misma (del sistema elegido, por ejemplo).
  2. 2 puntos: configuración de algún sistema de integración continua adicional (justificado de la misma forma).
  3. 2 punto: uso correcto del gestor de tareas y otras buenas prácticas en todos los casos anteriores (por ejemplo, si por un error has perdido el crédito de Travis se bajará un punto).
  4. 2 puntos: 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.

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.

Este hito contribuirá un máximo de un punto a la nota final.