Primeros pasos con Travis CI

De Wiki de EGC
Saltar a: navegación, buscar

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.

Para empezar con Travis CI

  1. Haz un fork del repositorio de GitHub: https://github.com/resinas/hello-java
  2. Usando tu cuenta de GitHub entra en https://travis-ci.org y acepta la confirmación de permisos de GitHub.
  3. 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 Enable.png.
  4. Añade un fichero .travis.yml a tu repositorio para indicar a Travis CI lo que tiene que hacer. Travis CI ya tiene una configuración por defecto para proyectos Java por lo que el .travis.yml puede ser tan sencillo como:
    language: java
    
  5. Haz commit y push del .travis.yml para iniciar una build de Travis CI
  6. Comprueba en la página de estado de la construcción si tu build ha pasado o falla.
  7. Haz una modificación en el código del proyecto para que falle una prueba. Haz commit y push del código y observa cómo la construcción falla.

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 script no es cero.

phase

El conjunto de pasos secuenciales de un job. Por ejemplo, la fase install viene antes de la fase script, que viene antes de la fase opcional deploy. Las fases de Travis CI son las siguientes:

  1. OPTIONAL Install apt addons
  2. OPTIONAL Install cache components
  3. before_install: instalar paquetes del SO necesarios para la construcción del proyecto
  4. install: instalar las dependencias (librerías) que sean necesarias para la construcción del proyecto
  5. before_script
  6. script: ejecutar el script de construcción del proyecto.
  7. OPTIONAL before_cache: para limpiar la caché
  8. after_success or after_failure: 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.
  9. OPTIONAL before_deploy
  10. OPTIONAL deploy: desplegar la aplicación a una plataforma integrada con Travis CI como Heroku o Engine Yard.
  11. OPTIONAL after_deploy
  12. after_script

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 before_install, install o before_script falló. En este caso el job termina inmediatamente.
  • failed: un comando en la fase script 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.