layout: index
Crear un microservicio sobre la base de la funcionalidad del hito anterior y cumpliendo los requisitos de las historias de usuario.
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.
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.
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.
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 pondrá 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 esinstalldeps.
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.
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.
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.
Si ya se ha entregado y corregido la práctica y se quiere subir nota, se reenviará siguiendo estas instrucciones.