Integración continua en Golang

Este artículo ha sido escrito por Adrián Pérez y publicado originalmente en el blog de Friends of Go

Para este artículo vamos a utilizar la API, GopherApi, que es de software libre y cualquier persona puede realizar PRs (Pull Request) sobre ella, con lo cuál necesitamos un sistema que nos verifique que los PRs cumplen con unos estándares puestos por nosotros para asegurarnos que al integrarlos en la rama master no se produzca ningún error.

¿Qué es la Integración continua(CI)?

La integración continua o continuos integration es una práctica de desarrollo, propuesta inicialmente por Martin Fowler que consiste en realizar integraciones automáticas de un proyecto lo más a menudo posible, para así poder detectar fallos lo antes posible. Entendemos por integración la compilación y ejecución de pruebas de todo el proyecto.

En este artículo trataremos la primera parte de la integración continua que será la comprobación de que todos los PRs (Pull Request) que reciba nuestro proyecto sean verificados por un proceso que nosotros realizaremos, asegurándonos tras una revisión manual de los cambios que dicho código no tiene afectaciones colaterales.

Os presentamos Circle CI

Hasta hoy en día, la herramienta que se utilizaba por predilección de los developers que tienen código open source en github era TravisCI, pero tras ser comprado por Idera y despedir a gran parte de la plantilla, la comunidad no se siente cómoda utilizando dicha herramienta, por eso muchos han migrado a Circle CI herramienta la cual os explicaremos hoy. En próximos artículos os explicaremos como migrar a CircleCI desde TravisCI

Lo primero de todo será configurar nuestro proyecto en la página de CircleCi no entraremos en detalle de este apartado, porque la propia página es lo suficientemente intuitiva para realizar el proceso sin ayuda, igualmente si tenéis problemas recordar, que nos lo podéis dejar en los comentarios o vía twitter @FriendsofGoTech

Configurando nuestro proyecto

Primeramente deberemos crear un nuevo directorio llamado .circleci y dentro añadiremos el fichero config.yml, nos quedará la siguiente ruta .circleci/config.yml

Si habéis seguido los pasos desde la propia web, tendréis un fichero de ejemplo similar al siguiente:

Vamos a analizar este fichero por partes.

Obviando el tag de version, nos encontramos con el tag jobs, los jobs son esas tareas que se encargará de ejecutar nuestro proceso, serán ejecutadas en un container de docker con la imagen que nosotros especifiquemos y con los scripts que queramos realizar.

Por defecto viene preparado para sólo ejecutar un job, con una imagen por defecto de Go que es la 1.9.

Aquí tendremos que decidir con que versiones de Go es compatible nuestro proyecto, nosotros como sabemos que hemos hecho GopherAPI en la versión 1.11.4, tendremos que asegurarnos de que nuestro proyecto sea compatible con esta versión y las venideras, veamos como queda nuestro fichero:

Lo que hemos hecho en el siguiente ejemplo ha sido, crear dos jobs distintos build-go1.11.4 y build-go_latest (a los jobs podemos llamarlos como queramos, pero siempre es recomendable ponerle un nombre identificativo). Cada job ejecuta el mismo código pero sobre diferentes versiones de go.

Por último nos encontramos con un nuevo bloque workflows

Aquí simplemente hemos configurado, un proceso de trabajo, para que ejecute nuestros dos jobs de manera paralela es decir que lance los dos procesos a la vez, y de esta forma el tiempo sea inferior a si tenemos que esperar a que acabe uno para que empiece el otro.

Una vez tenemos nuestro fichero configurado, ya podremos hacer nuestro push a github y comprobar desde la página de CircleCI que todo ha ido bien, además como ya pasaba con TravisCI tendremos un badge que podremos poner en nuestro repositorio, que informará a todos los consumidores de nuestro proyecto de si el código que tenemos pasa aquellas pruebas que hemos propuesto en el fichero de configuración (normalmente los tests y compilación)

Tenéis el ejemplo práctico en el repositorio de Github en la release v0.2.1.