Crear un microservicio sobre la base de la funcionalidad del hito anterior.
Haber alcanzado el 60% de los objetivos del tema correspondiente tras haber realizado los ejercicios propuestos. Haber superado el hito anterior de la práctica.
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), 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 o *akefile 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.
Aparte de las rutas que se hayan añadido, el servicio web debe cumplir también
un requisito muy importante: debe incluir una ruta /status que devuelva
el JSON { "status": "OK" } de forma que se pueda comprobar de forma
fehaciente que se ha desplegado de forma correcta. Esto se comprobará
automáticamente en el hito siguiente.
“Como este” no significa exactamente este. Tendrás que sustituir el valor de
rutapor las rutas que haya en la aplicación y el valor por un JSON que efectivamente se devuelva en esa ruta.
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, Ruby
on Rails, Express o Django, 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.
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.
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.
Si ya se ha entregado y corregido la práctica y se quiere subir nota, se reenviará siguiendo estas instrucciones.