Travis

La primera herramienta que se ha utilizado para la integración continua ha sido Travis. Esta es una herramienta que ya se había usado anteriormente aunque no con el lenguaje Golang. Se ha decidido que en Travis se ejecute el contenedor que hemos creado para poder lanzar los test. En este caso, estamos trabajando con la útlima versión del lenguaje, la 1.15.6. Otras versiones se comprobarán en otros sistemas de CI.

Para poder realizar la integración continua en Travis se ha creado el archivo .travis.yml. Para ello, hemos usado los siguientes enlaces de ejemplo:

• Raku-aulas: archivo de CI en el ejemplo visto en clase. Para conocer cómo trabajar con Docker y Travis.
• Minimal and Generic images.
• Travis Lifecicle.

Como hemos dicho, vamos a usar el contenedor que hemos creado. Por ello, no necesitamos indicar ningún lenguaje en específico ya que tenemos todo lo que necesitamos en el contenedor. Por eso usamos lenguage:minimal. Otra opción sería language:generic pero contiene más servicios y lenguajes que no necesitamos. Notamos que minimal no tienen definidos comandos install y script por defecto. En el apartado services indicamos que queremos usar Docker. Aunque no es necesario ya que se haría al ejecutarlo, hemos definido en el comando install la descarga del contenedor. Finalmente, en script ejecutamos el contenedor montado el directorio actual en la carpeta donde se ha definido que se lancen los tests.

Alternativas

Una vez seleccionado Travis como primera herramienta de integración continua, vemos diferentes sistemas de CI alternativos:

• Alternatives to Travis.
• What is Travis CI and what are its top alternatives?

Algunas que nos han llamado la atención son Gitlab (aunque solo tiene 400 minutos al mes de manera gratuita), CircleCI (con 2 500 créditos a la semana para la cuenta gratis), Jenkins y AppVeyor (ambos totalmente gratuitos). De este modo, se ha decidido probar con Appveyor. La única restricción para la cuenta gratuita es que solamente se puede ejecutar un job a la vez pero en nuestro caso no es ningún impedimento. Los principales enlaces consultados han sido:

• AppVeyor Build Pipeline.

• [Testing with Go

  AppVeyor](https://www.appveyor.com/docs/lang/go/).

• Versiones de Go.

El archivo que se ha escrito es appveyor.yml. Hemos observado que la sintaxis es similar a la de Travis. Lo primero que hacemos es indicar que vamos a utilizar una máquina Ubuntu y que no vamos a hacer build, solo vamos a ejecutar los tests. En la parte stack indicamos las versiones del lenguaje que vamos a testear. En este enlace podemos ver las diferentes versiones disponibles en el sistema. Como estamos usando GoModules para la gestión de dependencias, tenemos que usar una versión de Go mayor que la 1.11. Sin embargo, la biblioteca de aserciones da soporte como mínimo a la versión 1.13. Por ello, se indican las versiones major 1.13 y 1.14. No probamos la última versión ya que esta se testea en Travis. Finalmente, en la parte install nos descargamos el gestor de tareas y en test_script ejecutamos los tests mediante la orden task test especificada en el archivo de tareas Taskfile.yml.

Avances

En esta ocasión lo que se ha hecho ha sido un refactoring del código ya existente según los issues [#70][i70], [#71][i71] y [#72][i72], correspondientes a cada una de las estructuras map que teníamos predefinidas. Hasta ahora, las clases que controlaban la lógica dependían de la estructura de almacenamiento escogida y rompíamos el principio de inversión de dependencias. .Así lo que se ha hecho es crear las interfaces IValSaver, IResSaver e IPreSaver que definen el comportamiento que deben tener las clases que se dediquen exclusivamente al almacenamiento de datos. Siguiendo estas interfaces se han creado las clases ValoracionMap, ReseniasMap y PreguntasMap que implementan las interfaces y usan una tabla hash para almacenar los datos. Ahora las clases ValoracionRepositorio, ReseniasRepositorio y PreguntasRespositorio reciben un objeto de las interfaces correspondientes que es el que utilizan.

Se han creado los archivos de tests correspondientes a estas nuevas clases: valmapsaver_test.go, resmapsaver_test.go y premapsaver_tes.go. Los ya existentes (valoracion_tes.go, resenias_test.go y preguntas_test.go) se han modificado falseando el comportamiento de las interfaces creadas con los mocks situados en la carpeta mocks. Se ha usado Testify que ya veníamos usando para las aserciones y que tiene soporte para trabajar con mocks. Los mismos se han creado con la herramienta Mockery que crea los archivos de la nueva clase directamente a partir de la definición de la interfaz. Para este proceso se ha consultado este enlace.