Ver el código de «Travis CI para integración continua»

El funcionamiento básico de Travis CI es clonar el repositorio de GitHub a un nuevo entorno virtual y llevar a cabo una serie de tareas para construir y probar tu código. Si alguna de estas tareas falla, el build se considera ''broken''. Si no falla ninguna tarea, el build se considera ''passed'' y Travis CI puede desplegar tu código a un servidor web, por ejemplo. A continuación vamos a ver lo que hay que hacer para habilitar el sistema de integración continua y describiremos algunos conceptos básicos de Travis CI.

= Conceptos básicos =

En Travis CI hay 4 palabras que tienen un significado específico (obtenido de https://docs.travis-ci.com/user/for-beginners):

== job == 
Un proceso automatizado que clona tu repositorio en un entorno virtual y realiza una serie de ''phases'' como compilar el código, ejecutar tests, etc. Un job falla si el código que devuelve la fase <code>script</code> no es cero.

== phase == 
El conjunto de pasos secuenciales de un job. Por ejemplo, la fase <code>install</code> viene antes de la fase <code>script</code>, que viene antes de la fase opcional <code>deploy</code>. Las fases de Travis CI son las siguientes:
# OPTIONAL <code>Install apt addons</code>
# OPTIONAL <code>Install cache components</code>
# <code>before_install</code>: instalar paquetes del SO necesarios para la construcción del proyecto
# <code>install</code>: instalar las dependencias (librerías) que sean necesarias para la construcción del proyecto
# <code>before_script</code>
# <code>script</code>: ejecutar el script de construcción del proyecto. 
# OPTIONAL <code>before_cache</code>: para limpiar la caché
# <code>after_success</code> or <code>after_failure</code>: after_success se ejecutará si la construcción se realiza correctamente como generar la documentación. after_failure se ejecutará en caso de que la construcción falle.
# OPTIONAL <code>before_deploy</code>
# OPTIONAL <code>deploy</code>: desplegar la aplicación a una plataforma integrada con Travis CI como Heroku o Engine Yard.
# OPTIONAL <code>after_deploy</code>
# <code>after_script</code>

== build ==
Un grupo de jobs. Por ejemplo, un build puede tener dos jobs, cada uno prueba un proyecto con una versión distinta de Java. Un build termina cuando todos sus jobs terminan. Una build se considera broken si uno o más de sus jobs termina con un estado que no es ''passed''. Esto puede ocurrir por una de estas tres razones:
* ''errored'': un comando en la fase <code>before_install</code>, <code>install</code> o <code>before_script</code> falló. En este caso el job termina inmediatamente.
* ''failed'': un comando en la fase <code>script</code> falló. El job se ejecuta hasta que se termina
* ''canceled'': un usuario cancela el job antes de que complete.

En https://docs.travis-ci.com/user/common-build-problems/ se recogen una relación de problemas comunes en la construcción de un proyecto y cómo resolverlo.

== stage == 
Un grupo de jobs que se ejecutan en paralelo.

== Infraestructura ==
Travis CI ofrece tres tipos de infraestructuras diferentes:
* Basada en contenedores, que es la opción por defecto. Es un Linux Ubuntu ejecutándose en un contenedor. Se ejecuta más rápido que la basada en máquinas virtuales, pero no soporte el uso de sudo, setuid o setgid.
* Basada en máquinas virtuales. Es un Linux Ubuntu ejecutándose en una máquina virtual completa. Es un poco más lenta que la basada en contenedores para iniciarse, pero tiene más recursos y soporta sudo, setuid y setgid.
* OS X. Para probar software que necesite el entorno OS X para funcionar.


= El fichero <code>.travis.yml</code> =

Como ya hemos comentado, toda la información sobre cómo realizar cada job se especifica en un fichero <code>.travis.yml</code> que debe estar en el raíz del repositorio en cuestión. En su forma más básica, este fichero debe especificar el lenguaje utilizado en el proyecto para que cargue las librerías adecuadas en el entorno de ejecución y lo que se debe hacer en cada una de las fases descritas anteriormente. No es necesario especificar acciones en todas las fases. 

De este modo, como nuestro proyecto Decide está en python, el fichero <code>.travis.yml</code> podría quedar de la siguiente forma:

<syntaxhighlight lang="yaml">
language: python 
python: 
- "3.6"
env: 
- DJANGO=2.0 DB=postgres
before_install: 
- cd decide
install: 
- pip install -r ../requirements.txt
script: 
- python manage.py test

...
</syntaxhighlight>

En este caso, estamos especificando que queremos utilizar la versión 3.6 de Python; indicamos un par de variables de entorno que son necesarias para el funcionamiento de la aplicación, y ejecutamos los comandos necesarios para:
* Moverse al path adecuado antes de la fase install (<code>cd decide</code>)
* Instalar las dependencias que necesita el proyecto para funcionar en la fase install (<code>pip install -r ../requirements.txt</code>)
* Lanzar las pruebas en la fase script (<code>python manage.py test</code>)


= Soporte a base de datos =

Es frecuente que una aplicación requiera de bases de datos u otros servicios externos para poder probarse. Travis CI tiene soporte de serie para las bases de datos más habituales como MySQL, PostgreSQL, MongoDB o ElasticSearch. La lista completa se puede encontrar en https://docs.travis-ci.com/user/database-setup/ así como la forma de configurar cada una de ellas que, de nuevo, se realiza a través de <code>.travis.yml</code>. Por ejemplo, para configurar postgresql hay que añadir a <code>.travis.yml</code> lo siguiente:

<source lang="yaml">
...
services:
  - postgresql

before_script:
 - psql -c "create user decide with password 'decide'" 
 - psql -c "create database decide owner decide"
 - python manage.py migrate
</source>

La primera instrucción le dice a Travis CI que instale postgresql pues lo vamos a utilizar y la segunda instrucción le indica que cree un usuario, la base de datos y las tablas de la base de datos (<code>python manage.py migrate</code>) justo antes de la fase de script. Estos pasos (crear usuario, base de datos y tablas) también podrían ir ubicados en una fase anterior como <code>before_install</code> y son específicos de cada aplicación en cuestión. El resto de bases de datos se configuran de una forma bastante similar. 

También se puede definir información adicional de configuración. Por ejemplo:

<source lang="yaml">
...
services:
  - postgresql
addons:
  postgresql: "9.6"
global:
  - PGPORT=5432

before_script:
 - psql -c "create user decide with password 'decide'" 
 - psql -c "create database decide owner decide"
 - python manage.py migrate
</source>

En este caso, la segunda instrucción le indica cuál es la versión de postgresql que se va a utilizar; la tercera especifica la configuración sobre el puerto donde va a estar escuchando. Las restantes son iguales al caso anterior.

= Configuración de la aplicación =

La configuración del entorno donde se van a ejecutar las pruebas y la base de datos es sólo la mitad del recorrido. Una vez configurado, es necesario indicar a nuestra aplicación cuál es la base de datos que vamos a utilizar y el resto de opciones de configuración. Para ello, siguiendo el esquema propuesto en , vamos a crear un fichero con la configuración para travis y luego vamos a copiarlo al principio de la fase <code>before_script</code>.

El fichero de configuración para travis sería el siguiente:

local_settings.travis.py
----------------------------------
<syntaxhighlight lang="Python">
ALLOWED_HOSTS = ["*"]

# Modules in use, commented modules that you won't use
MODULES = [
    'authentication',
    'base',
    'booth',
    'census',
    'mixnet',
    'postproc',
    'store',
    'visualizer',
    'voting',
]

APIS = {
    'authentication': 'http://localhost:8000',
    'base': 'http://localhost:8000',
    'booth': 'http://localhost:8000',
    'census': 'http://localhost:8000',
    'mixnet': 'http://localhost:8000',
    'postproc': 'http://localhost:8000',
    'store': 'http://localhost:8000',
    'visualizer': 'http://localhost:8000',
    'voting': 'http://localhost:8000',
}

BASEURL = 'http://localhost:8000'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'postgres',
        'USER': 'postgres',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

# number of bits for the key, all auths should use the same number of bits
KEYBITS = 256
</syntaxhighlight>

y lo copiamos con el nombre adecuado modificando el fichero <code>.travis.yml</code> tal como sigue:

<source lang="yaml">
...

before_script:
 - cp local_settings.travis.py local_settings.py
 - ...
</source>


= Ejercicio =
== Para empezar con Travis CI ==
# Usando tu cuenta de GitHub entra en https://travis-ci.org y acepta la confirmación de permisos de GitHub.
# Una vez que estés logueado en Travis CI y se hayan sincronizado tus repositorios de GitHub, ve a tu perfil y activa el repositorio que quieras construir [[Archivo:Enable.png]].
# Añade un fichero <code>.travis.yml</code> según lo descrito en el texto a tu repositorio de Decide para indicar a Travis CI lo que tiene que hacer. 
# Haz commit y push del <code>.travis.yml</code> para iniciar una build de Travis CI
# Comprueba en la [https://travis-ci.org/auth página de estado de la construcción] si tu build ha pasado o falla.