Sexto hito: Diseño y test de un microservicio

Descripción

Crear un microservicio sobre la base de la funcionalidad del hito anterior y cumpliendo los requisitos de las historias de usuario.

Prerrequisitos

Haber alcanzado el 60% de los objetivos del tema correspondiente tras haber realizado los ejercicios propuestos (hasta el bloque 4 de ese tema). Haber superado el hito anterior de la práctica.

Explicación

Sobre la base de la clase o funcionalidad hecha en la práctica anterior, en este hito lo esencial es diseñar una API consistente en una serie de rutas (en el caso de un API REST) o tareas (en el caso de un microservicio basado en eventos) y testearlo exhaustivamente usando una biblioteca específica que te provea el microservicio o bien una biblioteca genérica, y crear la infraestructura necesaria para comenzar a ejecutarlo.

En cuanto a este último, se debe de usar el mismo fichero de construcción que se haya usado en el hito anterior, añadiendo una tarea start, que suele ser estándar para arrancar. Esto también permite, por ejemplo, usar uno de los sistemas de integración continua que se hayan creado para hacer una ejecución de prueba, en vez de ejecutar los tests. En general, todas las tareas que se ejecuten desde el sistema de integración continua deberán lanzar órdenes de esta herramienta que ejecute tareas.

Si se ha optado en al hito anterior por crear un prototipo para este, habrá que usar las mismas rutas (salvo por la parte que corresponda al servicio), y justificarlo en la documentación.

El objetivo secundario es poner en práctica las principales técnicas usadas hoy en día para despliegue de aplicaciones web u otro tipo de aplicaciones, basadas principalmente en interfaces REST con clientes basados en JS y, sobre todo, en marcos de aplicaciones tales como Dancer2, Sinatra, Nest.js o Sanic, dejando de lado servidores web específicos y de propósito general como Apache o nginx (que se pueden usar, en todo caso, en el primer caso para aplicaciones que incluyan múltiples lenguajes o marcos y en segundo, sobre todo, para contenido estático). Un tercer objetivo secundario es aprender a usar en producción GitHub y otras herramientas de desarrollo colaborativo y liberar el resultado del proyecto.

Como ya el proyecto ha llegado a un estado en el cual se puede desplegar como un servicio web, habrá que documentar cómo las rutas se ajustan a las historias de usuario que se hayan planteado desde el principio. No hace falta que en este punto todos los tests e historias estén implementadas, pero sí las suficientes para que se puedan llevar a cabo estos tests de integración.

Se recuerda que en este caso, la integración de la que se habla es la de otras bibliotecas que dependan de la clase o clases que sean la base del servicio web, y el propio servicio web. No es necesario ningún otro tipo de servicio, y especialmente desaconsejamos, en esta fase, integrar almacenes de datos de cualquier tipo.

Información adicional

Del curso 0 se puede consultar el material sobre tests de integración, y en el caso de que se empiecen a añadir accesos a datos, el tema de inversión de dependencias.

Entrega de la práctica

Subir los fuentes a GitHub y hacer un pull request al documento que describa las prácticas y que se anunciará en la web de la asignatura.

Para la evaluación habrá que añadir una clave make al fichero iv.yaml. En esa clave se podrá el comando (o secuencia de comandos) que se usan para el gestor de tareas. En el caso de make será, efectivamente, make, en otros casos será una o igual dos cosas (como poetry run). Para los tests, se descargará el repositorio y se ejecutará ese comando con tres targets en secuencia de esta forma:

make build
make install
make test

Se supone que todas las dependencias necesarias estarán ya instaladas en el contenedor. En el primer caso se compilará o transpilará (en caso necesario) los fuentes (que se habrán montado desde el exterior); install los instalará en el lugar habitual para el lenguaje de programación que se trate para que estén accesibles para los tests, que se ejecutarán a continuación.

Esto es, en general, lo que suele hacer el target install. En este caso las dependencias estarán instaladas en la imagen Docker, pero en general el target que se suele usar para instalar las dependencias es installdeps.

En ninguno de ellos tendrá que dar error. También se comprobará (aunque ya se hace en el hito anterior) que pasen los tests en Travis que se usará para ejecutar los tests de integración.

Valoración

La valoración se distribuirá en las siguientes rúbricas:

  1. 2 puntos: Justificación técnica del framework elegido para el microservicio con documentación sobre cómo se usa en la práctica.
  2. 2 puntos: Diseño en general del API, las rutas (o tareas), tipos devueltos por las peticiones y estados devueltos por las mismas, tests y documentación de todo, justificando como se ajustan a las historias de usuario, de forma que reflejen correctamente un diseño por capas que desacopla la lógica de negocio del API.
  3. 2 puntos: uso de buenas prácticas: configuración distribuida, logs, uso de middleware.
  4. 2 puntos: tests correctos y de acuerdo con las historias de usuario.
  5. 2 puntos: concedidos por originalidad de la aplicación, grado de terminación, utilidad para la asignatura, cantidad de trabajo invertido, el hecho que se haya avanzado el proyecto, creación de una imagen Docker para desplegarlo, configuración correcta del gestor de tareas.

Si la aplicación no funciona o hay plagio o trabajo en común, la práctica estará suspensa.

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 1.

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.

Se recuerda la política de plagios en esta asignatura: si una parte del código y la funcionalidad está copiada o de un tutorial o de otro estudiante, la práctica estará suspensa y en caso de reincidencia se podrá suspender la asignatura en la convocatoria ordinaria. La forma de asegurarse de que no es así es simplemente seguir las historias de usuario que se hayan creado desde el principio, incluyendo la hoja de ruta que se indicó en el hito 1.

Se aconseja al estudiante que es esencial concentrarse en los conceptos principales del hito (indicados arriba) y en entender los diferentes mecanismos del lenguaje para llevarlos a cabo. Se aconseja no buscar tutoriales, sino usar directamente la documentación y la referencia. En caso de que efectivamente se detecte código copiado directamente de tutoriales o de otros compañeros la práctica podrá estar suspensa.

Reenvío

Si ya se ha entregado y corregido la práctica y se quiere subir nota, se reenviará siguiendo estas instrucciones.