Configurar entornos de desarrollo y pruebas

[pavel-kalmykov]

Descripción

En el estado actual de desarrollo, para la parte del servidor, estamos teniendo una serie de carencias o problemas de configuración que actualmente tenemos que resolver a mano:

• Cuando arranca el servidor, debemos de asegurarnos manualmente de que el contenedor de la base de datos está en funcionamiento.
• También debemos de asegurarnos por nosotros mismos que todas las migraciones han sido ejecutadas.
• Existen dos ficheros de configuración: configuration.json, situado en la raíz del proyecto, y config.json, situado en el paquete webservice, el cual indica el puerto a utilizar y el nombre de los certificados para el SSL.

Por otra parte, cuando ejecutamos alguna suite de tests, el fichero de configuración que lee es el mismo que cuando ejecutamos el programa de forma corriente. Esto hace que se use la misma base de datos y, al terminar los tests, esta queda vacía.

Necesitamos implementar una serie de funcionalidades que resuelvan estos problemas y podamos tener una configuración más automatizada y que además la ejecución de los tests se realice sobre otra base de datos diferente a la de desarrollo.

Condiciones de satisfacción

• [x] El fichero config.json situado en el paquete mantecabox se fusionará con el de configuration.json para que sea este último quien administre todos los ajustes del servidor. Al igual que se hace con el primer archivo, en el nuevo -que será la mezcla de ambos- también tendrá parámetros por defecto si el JSON parseado no consigue encontrarlos.
• [x] Tendremos que refactorizar el código para que las configuraciones puedan ser inyectables en los servicios y controladores utilizando un patrón de factoría.
• [x] Cuando se vaya a leer la configuración, en el caso de que la variable de entorno MANTECABOX_CONFIG_FILE no esté definida, se comprobará si estamos en un entorno de desarrollo o si bien es de testeo, en cuyos casos los nombre de los ficheros a leer serán configuration.json y configuration.test.json, respectivamente. Este segundo fichero tendrá una configuración de base de datos y puerto diferente al normal para que los tests puedan ser ejecutados incluso con el servidor en ejecución. La base de datos de testeo deberá de existir (se deberá crear -comprobando si ya existe o no- mediante una migración) y deberemos de estar seguros de que, al igual de que en el entorno de desarrollo, todas las migraciones han sido ejecutadas.
• [x] Antes de intentar acceder a la capa de datos, sea desde donde sea, deberemos de asegurarnos de que el contenedor de docker de la base de datos esté en funcionamiento. Se mostrará un log sobre el resultado del arranque de Docker (o si este ya estuviera arrancado). Si no se consiguiera arrancar, el programa terminaría con un error indicando que no se pudo iniciar el mismo.
• [x] Después de asegurarnos de que el contenedor esté funcionando, también ejecutaremos todas las migraciones existentes para asegurarnos de que el esquema está completamente actualizado mostrando un log de la versión actual (la última migración) de la base de datos. Si no lo estuviera, terminaría con un error indicando que no se pudieron realizar todas las migraciones.

Referencias

• Factory Method Pattern en Go.
• Cómo comprobar mediante flags si estamos o no en un entorno de testing.
• Funciones init en go.

[pavel-kalmykov]

El nuevo JSON de configuración deberá de tener el siguiente aspecto:

{
  "aes_key": "6368616e676520746869732070617373",
  "database": {
    "engine": "postgres",
    "port": 5432,
    "user": "sds",
    "password": "sds",
    "name": "sds"
  },
  "server": {
    "ip": "localhost",
    "port": 10443,
    "cert": "cert.pem",
    "key": "key.pem"
  },
  "mail": {
    "host": "smtp.gmail.com",
    "port": 587,
    "username": "mantecabox@gmail.com",
    "password": "ElChiringuito"
  }
}

En https://mholt.github.io/json-to-go/ puedes convertir dicho JSON en una estructura de Go. Es posible que el JSON cambie con el tiempo.

[pavel-kalmykov]

Desarrollando en configuracion-entornos.

[pavel-kalmykov]

Se ha creado un script en bash que automáticamente arranca la imagen docker (si el contenedor estaba siendo ejecutado, antes lo para y lo elimina).