Gestion de la Construccion e Integracion Continua - Giratina-Votacion/decide GitHub Wiki

Gestión de la Construcción

Para la gestión de la construcción, hemos basado el proyecto en la metodología "Git Flow", adaptando ciertos aspectos a nuestro caso concreto. En primer lugar, cada uno de los cambios que el equipo haga dentro del proyecto deberá crearse en una rama que se denominará de la forma: "Creador-Cambio", donde Votación es para que el resto de módulos puedan identificar fácilmente esa característica con nuestro módulo, "Creador" corresponde al nombre del usuario de GitHub encargado de la característica que se implementa y "Cambio" es un nombre corto que se asocia a la característica en cuestión. Una vez que estas características se implementan y se prueban con resultado positivo (tanto pruebas en local como en Travis CI (ver sección de Integración Continua), se incluyen en la rama "develop" mediante un pull request.

(Nota: La única forma que se contempla de subir un commit directamente a develop, es en el caso de que sea requerido por una urgencia de funcionamiento importante (Por ejemplo: Se ha hecho un pull request a develop aparentemente inofensivo, pero ha provocado fallos en el despliegue de la aplicación, y necesita ser arreglado inmediatamente)).

Automatización de la Construcción: Scripts

Hemos desarrollado varios scripts que permiten desplegar el sistema Decide en local de una manera muy sencilla. En concreto, encontramos dos scripts: uno que nos permite desplegar el sistema en local mediante un entorno virtual de python, y otro que nos permite hacer lo propio utilizando docker.

Automatización del despliegue mediante entorno virtual

Para este tipo de despliegue, se ha desarrollado un script denominado "inicia_decide_local.sh".

Uso del script

En primer lugar, debemos ejecutar el script mediante bash:

sudo bash inicia_decide_local.sh

Una vez ejecutado, el script comprobará si ya existe una carpeta Decide y un entorno virtual creado por una ejecución anterior del script; de ser así, pedirá permiso expreso al usuario para borrarlas y crearlas de nuevo. Una vez concedido el permiso anterior, el script sigue los siguientes pasos:

Se pregunta al usuario la rama que desea desplegar (si se responde una rama inexistente, se usará la rama master por defecto).
Creación de un entorno virtual de python3
Acceso al entorno virtual y activación del mismo
Se realiza un git clone al repositorio
Una vez clonado, se cambia a la rama elegida por el usuario en el paso 1 mediante un git checkout
Se crea una copia del archivo local_settings.py para su uso en local
Instalación de los requisitos
Creación de la base de datos de Decide
Realización de las migraciones mediante los comandos makemigrations y migrate
(OPCIONAL): Se crea un nuevo superusuario
Se ejecuta el servidor en la URL http://localhost:8000

Con esto, ya tendremos el sistema Decide siendo ejecutado en local, de manera totalmente automática.

Automatización del despliegue mediante Docker

Para este tipo de despliegue, se ha desarrollado un script denominado "inicia_decide_docker.sh".

Uso del script

En primer lugar, debemos ejecutar el script mediante bash:

sudo bash inicia_decide_docker.sh

Una vez ejecutado el script, se pedirá permiso al usuario para borrar todas las imágenes y contenedores que tiene en Docker actualmente. Esto es importante, pues de esta forma se consiguen evitar fallos que pueden aparecer por el uso continuado del script. Después, comprobará si ya existe una carpeta de Decide que proceda de una ejecución anterior; de ser así, pedirá permiso expreso al usuario para borrarla y crearla de nuevo. Una vez concedido el permiso anterior, el script sigue los siguientes pasos:

Se borran todas las imágenes y contenedores de Docker
Se pregunta al usuario la rama que desea desplegar (si se responde una rama inexistente, se usará la rama master por defecto).
Se realiza un git clone al repositorio
Una vez clonado, se cambia a la rama elegida por el usuario en el paso 1 mediante un git checkout
Se crea una copia del archivo local_settings.py para su uso en local
Se realiza el docker-compose para poner Decide a funcionar
(OPCIONAL): Se crea un nuevo superusuario
Se ejecuta el servidor en la URL http://10.5.0.1:8000

Con esto, ya tendremos el sistema Decide siendo ejecutado en Docker, de manera totalmente automática.

Gestión de la Integración Continua

Para la integración continua, como el resto de módulos de Giratina, usamos Travis CI.

¿Qué es Travis CI?

Travis CI es un servicio de integración continua que nos permite construir y probar nuestros proyectos. Es una herramienta muy util, pues además de permitirnos conocer si nuestros commits provocan fallos en la aplicación, permite acelerar los pull requests simplemente viendo si la rama que se intenta añadir es aceptada por Travis, para estar seguros de que el código que estamos metiendo en nuestra rama es estable.

¿Cómo funciona Travis CI?

Configurar Travis es muy simple, tan solo hay que seguir los siguientes pasos:

Desde la web de Travis CI, debemos asegurarnos de que nuestro repositorio está activado.
Configurar el archivo .travis.yml, que debemos crear dentro de ./decide. El siguiente código es un ejemplo de un posible .travis.yml: De este archivo, las secciones más importantes son:

Before_script: En esta sección, podemos definir cualquier cosa que queramos que ocurra antes de que el script del archivo empiece a ejecutarse. En este caso, estamos estableciendo el usuario de la base de datos y asignándole un rol.
Install: Esta sección nos permite instalar cualquier dependencia que vayamos a necesitar para la ejecución del script principal. En nuestro caso está instalando los requisitos que se localizan en el archivo "requirements.txt", y codacy-coverage, que es necesaria para ejecutar las pruebas en este ejemplo.
Script: Aquí se ejecuta las órdenes principales de travis: podemos ver que es donde se ejecutan las pruebas (En el archivo que hemos tomado como ejemplo, las mismas se ejecutan usando codacy-coverage).

Podemos ajustar muchos parámetros dentro de este .travis.yml, como por ejemplo cómo queremos recibir notificaciones acerca del estado de nuestras builds, o ajustar Travis para que despliegue automáticamente en algún servicio.

Hacemos commit de nuestro .travis.yml y lo subimos al repositorio, entonces, Travis empezará automáticamente a probar la build correspondiente. Si entramos en la web de Travis durante el proceso, podremos ver el log, y ver en tiempo real las ejecuciones del mismo. Una vez terminado el build, puede haber fallado o haber pasado las pruebas. En caso de que haya pasado las pruebas, saldrá en color verde: Y si no ha pasado: Cuando nuestra build no pasa las pruebas de Travis, podemos encontrar 3 tipos de errores:

Errored: La build ha fallado antes de llegar a la fase de Script.
Failed: La build ha fallado durante la fase de Script
Cancelled: El usuario ha cancelado la ejecución.