varrrro / pay-up Goto Github PK

Se debe actualizar la documentación del proyecto, tanto en el archivo README.md como en la página web del mismo, para reflejar la arquitectura y el diseño que se ha decidido para el sistema.

Escribir una presentación del proyecto en el archivo README.md.

Se debe añadir la documentación relativa al despliegue de máquinas virtuales y su provisionamiento.

Usando la funcionalidad Pages de GitHub y Jekyll, construir una web que sirva para presentar el proyecto y la documentación necesaria.

Para la entrega del hito 4, se debe añadir al proyecto el fichero YAML que define la evaluación de las prestaciones, ademñas de actualizar la documentación.

Para ejecutar el microservicio de grupos gmicro, debemos usar una herramienta como systemd o supervisord con la que lanzar y controlar el proceso. Este proceso debe ejecutarse dentro de un contenedor docker.

Tanto los microservicios como sus respectivas bases de datos y el gateway se deben poder desplegar de manera sencilla y coordinada. Para ello, podemos usar una herramienta como Docker Compose, por ejemplo.

El sistema se debe desplegar en una serie de máquinas virtuales creadas en algún proveedor cloud.

Para hacer más accesible la documentación del proyecto y de los distintos hitos, añadir un enlace a la página web en el archivo README.md.

• Debo poder eliminar un grupo.
• Cuando elimine un grupo, todos los datos almacenados sobre el mismo deberán ser eliminados.

Se debe eliminar la referencia a Graylog del README y cambiarla por alguna tecnología libre para la gestión de logs. Además, reescribir algunos párrafos para explicar mejor las partes.

Se debe incorporar una cola de mensajes para el microservicio de gastos/pagos, ya que es importante que estos se procesen en orden.

Se debe mejorar el porcentaje de cobertura de los tests a un nivel más aceptable, como puede ser el 80%.

En Heroku, los contenedores no se ejecutan como root, es por esto que falla la ejecución del proceso con supervisord. Hay que quitar el usuario que se crea actualmente en el Dockerfile.

• Debo poder añadir un pago de un integrante de un grupo a otro.
• Cuando añada un pago nuevo, se deben recalcular los balances de las personas implicadas.

• Debo poder eliminar el último gasto añadido al grupo.
• Cuando elimine un gasto del grupo, se debe recalcular el balance de las personas implicadas.

Con la nueva descripción del proyecto, el diagrama contiene algunos errores que se deben solventar.

Mejorar los logs producidos por las distintas partes de la aplicación.

• Debo poder añadir una persona nueva a un grupo existente.
• Debo poder añadir un conjunto de personas nuevas a un conjunto existente.
• Cuando añada un nuevo integrante/s a un grupo, su balance inicial debe ser cero.

• Debo poder crear un grupo vacío.
• Debo poder crear un grupo a partir de un conjunto de personas.
• Cuando cree un grupo a partir de un conjunto de personas, su balance inicial debe ser cero.

Hasta ahora, representábamos los UUIDs como strings en nuestro modelo de datos. Esto provoca una enorme cantidad de trabajo inútil extra ya que hay que estar comprobando que los strings sean válidos.

Se va a cambiar el modelo de datos de tmicro para utilizar UUIDs, por lo que habrá que cambiar también la manera de trabajar en los managers y handlers.

Aprovechando este cambio, también se van a eliminar las funciones New() que permitían construir estos objetos debido a que no se utilizan.

Se debe crear un fichero .travis.yml que permita la ejecución de la herramienta de integración continua. El fichero debe incluir la instalación de dependencias y la ejecución de los tests, así como el envío de los datos de cobertura a la herramienta codecov.

Para realizar el despliegue final de la aplicación en algún proveedor cloud (Azure, GCP, ...), se va a configurar la creación automática de máquinas virtuales en dicho proveedor usando una herramienta como Terraform.

Además, se configurará también este despliegue automático en la máquina local con motivos de prueba usando Vagrant.

Faltan algunos detalles de la implementación del proyecto, como son el protocolo de comunicación o el almacén de pares clave-valor.

Para aportar documentación a este primer hito, escribir un nuevo post en la web sobre la configuración de Git llevada a cabo.

Usando Ansible, se van a crear playbooks para el provisionamiento de las máquinas virtuales donde se ejecutarán las distintas partes del sistema. El ciclo de vida de estas partes (ejecución y finalización) en las máquinas también se tendrá que poder realizar usando Ansible.

En vez de implementar funciones separadas para la adición/eliminación de uno o varios usuarios, usar una única función a la que se llame en un bucle.

• Debo poder añadir un gasto realizado por un integrante de un grupo para el resto.
• Debo poder añadir un gasto realizado por algunos integrantes de un grupo para el resto.
• Debo poder añadir un gasto realizado por un integrante de un grupo para algunos de los demás.
• Debo poder añadir un gasto realizado por algunos integrantes de un grupo para algunos de los demás.
• Cuando añada un gasto nuevo, se debe recalcular el balance de las personas implicadas.

Actualmente, se copian tambien los ficheros de test a la imagen, lo cual no es necesario.

• Debo poder eliminar el último pago añadido a un grupo.
• Cuando elimine un pago de un grupo, se deben recalcular los balances de las personas implicadas.

Las respuestas que devuelve el microservicio de grupos no tienen la cabecera Content-Type fijada a application/json. Debemos hacer que todas las respuestas devuelvan esta cabecera y añadir una comprobación para ella a nuestros tests.

Hasta ahora, representábamos los UUIDs como strings en nuestro modelo de datos. Esto provoca una enorme cantidad de trabajo inútil extra ya que hay que estar comprobando que los strings sean válidos.

Se va a cambiar el modelo de datos de gmicro para utilizar UUIDs, por lo que habrá que cambiar también la manera de trabajar en los managers y handlers.

Aprovechando este cambio, también se van a eliminar las funciones New() que permitían construir estos objetos debido a que no se utilizan.

El contenedor del microservicio de gestión de grupos, gmicro, debe desplegarse a Heroku.

Se debe modificar el archivo README.md para incluir la justificación sobre las elecciones de las herramientas de test y construcción, así como la documentación del fichero .travis.yml. También se deben añadir los badges de Travis y Codecov.

La documentación existente en el README.md será movida a un post de la web.

Para gestionar las peticiones a los dos microservicios desde un único punto de acceso, escribiremos un API gateway que se ejecutará en un contenedor individual.

• Debo poder eliminar una persona de un grupo.
• Debo poder eliminar un conjunto de personas de un grupo.
• No debo poder eliminar una persona con un balance distinto de cero.

Mover el contenido actual del READM.md a posts de la web del proyecto y redactar el nuevo contenido sobre la creación del servicio, la imagen Docker y el despliegue a Heroku.