Crear un microservicio sobre la base de la funcionalidad del hito anterior y cumpliendo los requisitos de las historias de usuario.
Haber pasado los tests del hito anterior.
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) 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 las tareas que se indican más adelante en la entrega. 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.
En general, el significado de estas tareas es el siguiente:
build genera los ficheros que se vayan a desplegar a partir de
los fuentes y, en general, llevan a cabo todas las tareas
necesarias para el mismo. No todos los lenguajes o frameworks lo
usan o necesitan, pero es conveniente saber que esta fase casi
siempre ocurre, y no sólo en los lenguajes que compilan a un
ejecutable.install a diferencia de lo que ocurre con npm (y una de las
razones por las que npm no es un ejecutor de tareas adecuado),
install toma los ficheros generados anteriormente y los pasa al
lugar donde el intérprete suele localizar las bibliotecas, de forma
que a continuación, los tests o los ejecutables sean capaces de
encontrarlo. Por ejemplo, Go copia los ficheros compilados a un
directorio específico, Perl y Raku también, y C o C++ lo copiarán,
por ejemplo, a /usr/lib/ o /usr/local/lib. No todos los
lenguajes lo necesitan, sin embargo, pero en general sí será
necesario.test se comportará igual que se ha comportado desde el hito 2.El objetivo secundario es poner en práctica las principales técnicas
usadas hoy en día para diseño 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.
En este hito es cuando el MVP del backend del proyecto es cuando empieza a tomar forma. En este momento, todos los HUs que se vayan a poner en práctica tienen que tener la estructura correcta indicada en el hito 1. Es esencial también que el API esté separado de la lógica de negocio, y que incluya únicamente aquellas peticiones que se prevé que efectivamente se vayan a hacer desde un cliente; en caso contrario, simplemente no se deben de exponer mediante un API.
Conviene también que en este punto la aplicación tenga una lógica de negocio real más allá de almacenar y recuperar información. Toda la lógica de negocio, al menos que se vaya a implementar, debería estar prácticamente completa.
En este punto, el código que se haya entregado tiene que estar en el siguiente estado:
La entrega se hará, como siempre, con un pull request, al documento correspondiente a este hito.
Para la evaluación habrá que añadir una clave make al fichero
cc.yaml. En esa clave se podrá el comando (o secuencia de comandos)
que se usan para el gestor de tareas, que en cualquier caso será una
cadena. 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, por ejemplo:
make build
make install
make test
En ninguno de ellos tendrá que dar error. También se comprobará que pasen los tests en Travis, que se usará para ejecutar los tests de integración (o cualquier otro, si se desea).
La valoración se distribuirá en las siguientes rúbricas:
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 (de la asignatura).
Si ya se ha entregado y suspendido esta práctica, se podrá reenviar siguiendo estas instrucciones.