Ir al contenido principal

Integración Continua con Drone

Hace poco que hemos empezado a usar Drone como plataforma de integración continua. A continuación veremos que es la integración continua, historia y usos.

La integración continua es la práctica que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para detectar fallos cuanto antes, entendiendo integración como compilación (de ser necesaria) y ejecución de pruebas del proyecto. Esta integración suele activarse desde el control de versiones del proyecto, como por ejemplo git. La idea es que cada vez que se realiza un evento (un push, un pull request, …) se ejecuta la integración. Lo bueno es que se puede escoger qué se ejecuta en cada evento. Por ejemplo, los tests unitarios suelen ser bastante ligeros, y aún siendo varios cientos, tardan pocos segundos en ejecutarse. Por lo tanto, tiene sentido que se ejecuten con cada push. Pero, por ejemplo, replicar una infraestructura es más costoso, aún con tecnologías como docker. Por lo tanto, tendría sentido ejecutar pruebas de integración con docker solo en los merge request.

Se entenderá todo mejor con un ejemplo. Antes de eso, explicaré brevemente como lo hemos instalado. Como ya sabrá quien haya venido a alguna asamblea, en La Brecha Digital tenemos un proyecto, que es ansibilizar y dockerizar el un servidor con todos los componentes que queremos. Uno de estos es drone. Por lo tanto, si se quiere instalar, se puede usar el rol deploy-docker, que es un rol que hemos desarrollado para desplegar contenedores docker que se puedan gestionar como servicios de systemd. Las lineas exactas se pueden consultar en nuestro playbook.

Suponiendo que tenemos drone ya instalado y integrado con algún servidor git (en nuestro caso gitea, aunque hay más opciones), veamos como empezar a usarlo. Un detalle que hace que drone mole más que otros engendros gigantes, deformes y javosos como Jenkins, es que tiene una cli funcional muy simple de usar. Una vez logueado en tu servidor drone, hay una sección que se llama Token. En esta saldrá algo como esto:

export DRONE_SERVER=https://drone.cslabrecha.org
export DRONE_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.aa29iwidHlwZSI6InVzZXIifQ.XtTbzRLeZngWiXAd_TzOyfYEKAQ8OF_9xJzYeH4J3q8
drone info

Solo hay que copiarlo y ejecutarlo en la shell y ya se puede usar la cli. Para activar un repositorio, solo hay que ejecutar:

drone repo add La_Brecha_Digital/brechadigital-web

Y ya. Al añadirlo como repositorio, automáticamente configura el repositorio git, por lo que todos los eventos push del repositorio activaran el pipeline de drone, una vez este exista. Para ver un ejemplo real, vamos a examinar el repositorio para crear la imagen de docker de nikola que hemos hecho. El repositorio consta de tres ficheros, un README, un Dockerfile y un .drone.yml. El fichero .drone.yml es el que contiene el pipeline del repositorio. A fecha de hoy, contiene esto:

pipeline:
  # Build the image when on pull request
  build:
    image: docker
    commands:
      - docker build -t testing/nikola .
      - docker rmi testing/nikola
      - docker system prune -f
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    when:
      event: pull_request
  # Publish the image to the registry
  build-push:
    image: plugins/docker
    repo: r.cslabrecha.org/nikola
    registry: r.cslabrecha.org
    tags: latest
    secrets: [docker_username, docker_password]
    when:
      branch: master
      event: push
branches: master

Se puede apreciar que hay dos partes, por así decirlo. Uno seria build y el otro build-push. Los nombres son bastante descriptivos, uno construye la imagen y el otro construye la imagen y la pushea al registry. La diferencia principal son los when. Estos parámetros son los que deciden cuando se ejecuta un build. En el primer caso, se ejecuta solamente cuando el evento recibido es un pull request. En el caso del segundo, cuando es un push a master, es decir, cuando el pull request se ha mergeado correctamente.

Cuando se activa un pipeline en un evento, se añade un botón al lado del commit. Cuando está en progreso, tiene una redonda amarilla. Cuando termina correctamente e incorrectamente, respectivamente, se ve así:

img

img

Es importante fijarse en esto cuando se siguen políticas estrictas de calidad, por que de momento gitea no permite bloquear el pull request (o peticion de mergeo) hasta que la integración contínua no termine correctamente.

Quien tenga curiosidad, puede echar un ojo al que tenemos montado. Este build en concreto es uno de construcción de la página web. Se pueden ver los stages abajo a la izquierda (clone, builder), y a la derecha se ve el log de las órdenes que ejecutan el stage. También se puede ver más información relevante, como cuando se ejecutó el build, el commit que ejecutó, el estado, …

Y con esto se puede empezar a usar drone. Aviso que la documentación disponible deja bastante que desear. Parece que apunta mucho al rollo enterprise, pero hay que tener en cuenta que el proyecto es relativamente joven, con suerte mejorará. Cualquier duda, se puede comentar en la sala de xmpp que se puede consultar en la sección de contacto.