En pasados artículos hemos estado interactuando con nuestra API, GopherApi, ya hemos desarrollado diferentes endpoints y además hemos incluido los test del mismo.
Nuestra API además 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:
# Golang CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-go/ for more details
version: 2
jobs:
build:
docker:
# specify the version
- image: circleci/golang:1.9
# Specify service dependencies here if necessary
# CircleCI maintains a library of pre-built images
# documented at https://circleci.com/docs/2.0/circleci-images/
# - image: circleci/postgres:9.4
#### TEMPLATE_NOTE: go expects specific checkout path representing url
#### expecting it in the form of
#### /go/src/github.com/circleci/go-tool
#### /go/src/bitbucket.org/circleci/go-tool
working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}}
steps:
- checkout
# specify any bash command here prefixed with `run: `
- run: go get -v -t -d ./...
- run: go test -v ./...
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:
version: 2
jobs:
build-go1.11.4:
docker:
- image: circleci/golang:1.11.4
working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}}
steps:
- checkout
- run: go test -v -race ./...
- run: go build -race cmd/{{REPO_NAME}} .
build-go_latest:
docker:
- image: circleci/golang:latest
working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}}
steps:
- checkout
- run: go test -v -race ./...
- run: go build -race cmd/{{REPO_NAME}} .
workflows:
version: 2
build_and_test:
jobs:
- build-go1.11.4
- build-go_latest
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
...
workflows:
version: 2
build_and_test:
jobs:
- build-go1.11.4
- build-go_latest
...
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)
Como siempre, tenéis el ejemplo práctico en nuestro repo de Github en la release v0.2.1.
En futuros artículos continuaremos explotando CircleCI hasta que deployemos nuestra aplicación y lleguemos a un modelo de entrega continua o continuos delivery (CD).
adrianpgl
aperezg