modejota / vendorvert Goto Github PK

Al cambiar los controladores en #42 para que se adecue más a la nube (#20) cambia la estructura de datos y algunos IDs. Modificar tests lo mínimo para seguir probando funcionalidad.

Se necesita también crear la base de datos de prueba al iniciar los test y "destruirla" al acabarlos.

Colección de tests rapidos para hacer con POSTMAN en la demostración de clase de que la app funciona. Obviamente, en 5 minutos no me da a hacer un analisis exhaustivo de todas las peticiones.

Tras empezar a abordar #20 y cambiar las clases de datos a esquemas de Mongoose, hay que cambiar los controladores para que hagan llamadas a la base de datos en lugar de una tabla hash local

Se descubre que la actualización del contenedor no se realiza al mergear una rama en main. Se intenta arreglar este comportamiento.

Para mantener un registro de los logs de la aplicación se necesitan añadir contenedores. Se usará pila ELK. Tiene que ver con #40 y #41

Como gestor, quiero poder disponer de una estimación de la liquidez del negocio, en función de ingresos percibidos y a percibir, así como de gastos realizados y a realizar. De esta manera, se asegurará el tener un cierto margen de maniobra a la hora de realizar ciertas transacciones, como pagar a proveedores o hacer frente a los impuestos.

Al pasar los logs directamente por el transporter de pino a ELK no necesito ni configuracion de ficheros ni nada por el estilo, y tampoco los test relativos a eso.

Necesitamos disponer de una clase para representar al objeto valor principal del problema, los productos que se venden en la tienda. Se referencia de manera indirecta en las 5 historias de usuario creadas por el momento (#2 #3 #4 #5 #6 )
Por el momento, necesitaremos que los productos tengan un ID único, un nombre, marca, tipo y PVP. (Puede que en el futuro deban añadirse más atributos

Se necesita de una manera de representar los distintos tipos de productos que se venden en el negocio, para facilitar posteriores agrupaciones en función de los mismos. Cada negocio puede requerir de un conjunto distinto, y es posible que deba extenderse con el tiempo. Se relaciona con #8

Escribir toda la documentación del hito 6.

• Estructura del clúster.
• Modificaciones a la aplicación.
• Configuraciones extra.
• Demostrar que todo funciona,
  y puede que algo más.

Como gestor, quiero poder predecir la afluencia de clientes al local en determinadas fechas y franjas horarias. Especialmente orientado a campañas de alto volumen de ventas, como San Valentín, Navidades o Reyes Magos, en las que es probable que deba ampliarse el número de dependientes o incluso el horario de apertura.

Se recomienda la creación de una clase específica para gestionar los posibles errores que puedan producirse al gestionar el inventario, de manera que a posteriori sea más sencillo debugear el programa.

Se necesita de una manera de representar los distintos productos presentes en una factura. Necesitamos disponer de los datos de cada producto, la cantidad vendida y la fecha en que se realiza la transacción.
Se deben añadir métodos CRUD básicos.
Más adelante, también deberá contener una referencia al usuario/compañía asociado a la factura.

Como buenos desarrolladores que siguen las buenas prácticas, necesitamos crear tests unitarios que comprueben el correcto funcionamiento del código desarrollado hasta el momento.
Antes, necesitaremos elegir un gestor de tareas, framework de tests y biblioteca de aserciones (todo debidamente justificado)

Como gestor, quiero disponer de un sistema que me recomiende cómo vender un producto en función de su precio, su stock y su demanda; o público potencial al que dirigir su venta, entre otros factores. Especialmente orientado a productos nuevos cuyo nicho de mercado no esté claramente definido, o a productos que se encuentren en una fase de descenso importante de ventas (de manera que se corre el riesgo de almacenarlos indefinidamente sin darles salida).

Como gestor, quiero poder predecir, con un mínimo de 30 días de antelación (aunque idealmente sería configurable), los productos de los que debo disponer en el almacén para suplir la demanda de los clientes en próximas campañas.

Parece que al añadir al final del hito anterior el disparador manual en las Github Action esto hace que no se ejecuten cuando hay otro trigger, como el push, a pesar de que en la documentación no dice nada de incompatibilidades. Investigar e intentar resolver.

Se necesita de un sistema que permita gestionar diversas variables de configuración del programa. Por lo pronto nos servirá con que sea a nivel local, pero en un futuro no muy lejano deberá servir para entornos distribuidos, por lo que conviene dejarlo medianamente preparado.

Una vez elegido el framework que se vaya a utilizar, añadir los ficheros necesarios por dicho framework y comenzar a escribir la API REST para acceder a los diferentes recursos de la aplicación

Se debe disponer de un sistema que nos permita reconstruir y subir automáticamente el contenedor a Dockerhub cuando este sufra alguna modificación (Dockerfile o ficheros de dependencias de Node). Idealmente, mediante Github Actions, y cuando se mergea un PR en la rama principal.

Se necesita de una clase encargada de abstraer el funcionamiento interno, de modo que se crea el almacén en el sistema y se procesan las ventas (facturas) con la serie de cambios que provocarán en el sistema.
Se estudia si incluir en esta también el almacenamiento de los datos de los clientes.

También se necesita de una clase que represente los errores/excepciones que se puedan generar en este gestor

Justificar porqué se han elegido los servicios de CI que se han elegido.
Explicar cómo se configuran y demostrar que los tests se ejecutan correctamente.

Comenzar a escribir Docker-compose, de manera que hagamos uso del contenedor de la app por un lado y de la base de datos de mongo por otro. Posteriormente, tendremos que añadir el contenedor de logs a parte.

El actual desarrollo de la aplicación se centra en una aplicación más orientada hacia al escritorio, y que aún no cuenta con base de datos.
Replantear el desarrollo para facilitar la inclusión de una base de datos, la futura creación de API y el despliegue en la nube mediante varios contenedores.

Se recomienda la creación de una clase específica para gestionar los posibles errores que puedan producirse al construir productos, de manera que a posteriori sea más sencillo debugear el programa.

Decidir (y documentar) que herramienta de logging se va a utilizar. Posteriormente, incluirla en la aplicación; lo suyo sería que se registrasen las peticiones a la API y/o su resultado.

En el marco del hito 3, debe crearse un contenedor Docker en el que ejecutar los tests del código. Debe valorarse imagen base a utilizar y deben seguirse buenas prácticas para optimizar el proceso. También, debe explicarse como instalar Docker en WSL2.

Buscar distintos frameworks sobre los que construir la API REST, evaluar diferencias, ventajas y desventajas de cada uno de ellos y seleccionar uno para el proyecto

Redactar la documentación pertinente respecto de la elección del framework de tests, así como la biblioteca de aserciones; instalación y configuración necesaria; etc.

Se necesita una manera de representar el almacén de productos del negocio que permita una consulta de los mismos de la manera más rápida posible. Se guardará la información de cada producto junto a su cantidad, siendo la clave para acceder al producto su propio identificador único (código de barras)

Se debe disponer de los métodos CRUD básicos (añadir producto, eliminar producto, obtener producto-cantidad y modificar cantidad de producto). En el futuro es posible que se requiera la creación de métodos adicionales

Aunque es fundamental para la resolución del problema en su conjunto, se relaciona especialmente con la HU1 [#2]

Instalar dependencias para poder conectar la aplicación desarrollada con una base de datos Mongo (en principio da igual si está en un contenedor o no)

Como gestor, quiero disponer de un informe de los productos más vendidos en función del tipo de cliente. De esta manera, se podrá realizar una campaña de marketing dirigida a cierto tipo de clientes, con el fin de fidelizarlos y aumentar la rentabilidad del negocio.

Definir sistemas de integración continua. Para superar el hito solo se requiere Github Actions (GHA).
En mi caso, utilizaré dos sistemas.

• Github Actions para testear a partir del código fuente para varias versiones de Node.js, puesto que los créditos son bastante mayores que en otras plataformas.
• CircleCI para testear a partir del contenedor Docker, lo cual también se puede hacer con GHA, pero así aprovecho para conocer una herramienta más. (Escribir documentación de porqué este servicio y no otro)

Mientras se realiza el diseño e implementación de la API REST, escribir los tests que comprueben su correcto funcionamiento. En el marco del hito 5 aún no necesitamos levantar servidor, se puede "hacer inject" de la petición; en el marco del hito 6 ya veremos.