Skip to content

Latest commit

 

History

History
36 lines (20 loc) · 5.54 KB

heroku.md

File metadata and controls

36 lines (20 loc) · 5.54 KB

Despliegue del microservicio en Heroku

Descripción y justificación de las herramientas usadas para desplegar la aplicación en el PaaS.

He usado Heroku para el despliegue del microservicio por varias razones. Las principales han sido por ser gratuito y tener una CLI bastante simple y fácil de manejar. Además de lo anterior, permite añadirle addons, como por ejemplo una base de datos postgre (la que he usado yo) y conectarlo con plataformas de logging (como por ejemplo logDNA).

La aplicación la he desplegado usando el fichero heroku.yml el cual me permite el despliegue de un contenedor (así aprovecho el que creé en el hito anterior Dockerfile.web) y además he añadido una base de datos postgre a la dyno sin tener que añadirla a mano. El despliegue se ha hecho siguiendo estas instrucciones.

Para las pruebas locales del microservicio he usado heroku local para evitar despliegues que no funcionen y me hagan perder el tiempo.

Gracias a las órdenes de heroku pg, he podido provisionar la base de datos postgre usando heroku pg:push LOCAL_DATABASE DATABASE_URL --app APP tal y como se indica en la documentación oficial.

Descripción correcta de la configuración para despliegue automático, desde el repositorio o desde el sistema de integración continua.

Para el despliegue automático en Heroku, he implementado el workflow Heroku CD, el cual se ejecuta después de los tests si estos se pasan correctamente.

Buenas prácticas del diseño de la API.

Para el correcto diseño de la API me he basado en la documentación de NestJS para asegurar las buenas prácticas en el diseño de la misma.

  • Las rutas de Usuario se encuentran en usuario.controller.ts (tests del controller aquí). El controller hace uso de usuario.service.ts, que se encarga del almacenamiento de los datos (los tests del service se encuentran aquí, he hecho un mock para el pool de postgre). Esto se corresponde con la HU0 y la HU1.
  • Las rutas de Partido se encuentran en partido.controller.ts (tests del controller aquí). El controller hace uso de partido.service.ts, que se encarga del almacenamiento de los datos (los tests del service se encuentran aquí, he hecho un mock para el pool de postgre). Esto se corresponde con la HU2 y la HU3.

Además de lo anterior, he actualizado los tests de integración para Usuario (se encuentran aquí) y he añadido los de Partido (se encuentran aquí). Además he añadido lo siguiente:

  • Un script SQL para crear las tablas de la BD, tanto para producción, como para desarrollo.
  • He añadido un docker-compose.yml para poder hacer staging en un futuro.

También se ha trabajado en la HU6 y en la HU7. Me faltaría por finalizar con la HU4, me pondré con ella con la mayor brevedad posible, ya que tengo que tenerlo listo para la presentación.

Uso de bases de datos y logs dentro del PaaS.

He usado PostgreSQL debido a que uso datos estructuras y es más indicada para producción que MySQL debido a su mayor conrrencia. La base de datos ha sido provisionada tal y como indiqué antes, tengo que añadir que lo hice con una BD limpia, con las tablas recién creadas. Además puedo acceder a ella desde mi PC con la orden heroku pg:psql. El módulo de la BD se encuentra aquí. La clase PgService es singleton, solo se crea una instancia, por tanto solo existe un Pool para toda la aplicación y además es inyectada en todas las clases que la usa.

Para el sistema de logs, debido a que el de Heroku los guarda durante muy poco tiempo, he conectado mediante la CLI (usando esta guia) con logDNA. He usado esa plataforma debido a los beneficios que me aporta en la misma el pack de estudiante de GitHub.