Implementando Integración y Despliegue Continuo a lo encontre.co

Después de las pruebas de guerrilla aplicadas a los usuarios para la verificación de la funcionalidad general de la aplicación, se empieza a diseñar la tubería de integración y despliegue continuo que permitirá realizar las pruebas y notificar sobre el estado de la misma, permitiendo o no el despliegue automático de la aplicación en el servidor de producción.

Con el objetivo de observar el crecimiento del aplicativo con estas mejoras y correcciones, se ha decidido incluir el archivo “CHANGELOG.md”, donde se documentarán todos los cambios notables de esta aplicación, basados en Mantenga un CHANGELOG y aplicando Versionamiento semántico.

La selección de las herramientas a implementar en la tubería han sido seleccionadas de la guía de otros grupos de trabajo, las cuales son:

  • Git y GitHub
  • Travis CI

El diseño del pipeline para la integración y despliegue continuo de la aplicación “loencontre.co” es el siguiente:

Figura. Pipeline “loencontre.co”

Configuración de Travis CI

Figura.Estado de Travis CI: construido correctamente

En cuanto a la configuración de Travis CI, se destaca:

Travis-CI y Laravel

Travis-CI es una herramienta online que permite sincronización con un repositorio(en este caso GitHub), y configurar la ejecución automática de pruebas unitarias, con el fin de verificar cada vez que se hace un cambio en el código, o se agrega una funcionalidad, que dicho cambio no afecte negativamente otra funcionalidad o funcionalidades escritas por otro programador.

Para configurar Travis-CI, el primer paso es crear un archivo con el nombre “.travis.yml”, cuya estructura básica se muestra a continuación.

Figura. Configuración básica del archivo .travis.yml

Como se observa en la figura, el archivo .travis.yml hace uso de etiquetas que el editor Sublime Text reconoce y les da un color rosa. Se debe tener en cuenta que la etiqueta script, contendrá los comandos que se deben ejecutar para correr las pruebas.

La configuración mostrada, le dice a Travis que el lenguaje de programación en que vamos a ejecutar las pruebas es php, en seguida le dice las versiones del lenguaje en que se debe ejecutar, y al final, que ejecute PHPUnit, el FrameWork para pruebas unitarias.

Con esta configuración básica podríamos ejecutar las pruebas de aplicaciones escritas en php nativo, por lo que no es suficiente para ejecutar las pruebas unitarias del backend de la aplicación que se está desarrollado que está escrita sobre el framework Laravel, que a su vez está escrito en php.

Para ejecutar las pruebas unitarias de una aplicación escrita sobre laravel, se deben seguir los siguientes pasos:

  • Cuando se crea un proyecto en Laravel, automáticamente se ejecuta el comando “artisan key:generate”, para crear una llave que será usada por la aplicación. Cuando Travis clona el proyecto, dicha llave pierde su validez y es por esto que se debe generar nuevamente ejecutando el mismo comando.
  • Se debe crear una base de datos cuyo nombre coincida con el especificado en el archivo .env, que corresponde al archivo de configuración de la aplicación. Es importante tener en cuenta que el nombre de usuario y contraseña, especificados en el mismo archivo deben existir en el gestor de bases de datos usado y tener privilegios suficientes sobre la base de datos perteneciente a la aplicación.
  • Se deben ingresar datos a la base de datos si algunas de las pruebas lo requieren.

Lo anterior se debe realizar antes de ejecutar phpunit, o lo que es lo mismo, antes de ejecutar el contenido de la etiqueta script del archivo .travis.yml. Para esto, Travis cuenta con una etiqueta denominada before_script, que como su nombre lo indica, se ejecuta su contenido antes de ejecutar el de la etiqueta script.

Lo anterior representado en el archivo .travis.yml queda de la siguiente manera:

Figura. Contenido de la etiqueta before_script

En el caso de la aplicación en construcción, la base de datos se llama goodfirm_entregas, y se insertan datos y crean tablas por medio del archivo llamado goodfirm_entregas.sql.

Una vez configurado el entorno para que la aplicación pueda ser ejecutada por el framework de pruebas, se debe ejecutar este último, que es lo mismo que ejecutar el contenido de la etiqueta script.

Figura. Contenido de la etiqueta before_script

Como se muestra en la figura anterior, se debe especificar tanto la ruta del ejecutable del framework, como la ruta de cada archivo que contenga pruebas y deba ser ejecutado.

De esta manera conseguimos configurar Travis-IC para ejecutar pruebas unitarias en un proyecto de software escrito sobre Laravel.

Figura. Resultado de ejecutar PHPUnit desde Travis-IC

Travis-IC y la integración de código

El paso siguiente después de ejecutar las pruebas, es integrar el código, la idea principal es verificar si el resultado de las pruebas es satisfactorio, y si es así, el código se integre correctamente al repositorio, en la una rama especificada; pero si el resultado de la ejecución de las pruebas no es satisfactorio, no se permita la integración. Teniendo en cuenta que Travis-IC se ejecuta una vez que el repositorio recibe el cambio, no es posible impedir la integración, pero lo que sí es posible es revertir el cambio hecho retornando a la versión(commit) inmediatamente anterior.

Para esto, Travis-IC cuenta con dos etiquetas denominadas after_success, y after_faliure, que como sus nombres lo indican, su contenido se ejecuta después de obtener un resultado satisfactorio al correr las pruebas, y después de obtener un resultado no satisfactorio respectivamente. Una característica de Travis que es importante para tener presente, es la capacidad de configurar ramas presentes en el repositorio, en las que se debe ejecutar las pruebas, de esta manera se puede como en el caso presenta, monitorear únicamente la rama principal o master, y la rama de desarrollo principal llamada por el equipo development.

Con lo anterior el contenido de la etiqueta after_success, deberá contener instrucciones para integrar el código presente en development con el presente en la rama master. Esto se muestra en la siguiente figura:

Figura. Contenido de after_success en travis.yml

Travis CI y autenticación en Git

Una vez que se verifica que pasaba las pruebas se clonaba el repositiorio de loencontre.co y para poder realizar el merge con la rama master desde la rama development es necesario tener los permisos para realizar el commit de Integración, para esto se usó las variables de entorno:

Figura Configuración de usuario

Finalmente para la realización del push una vez realizado el commit correcto, fue necesario aplicar el siguiente comando para la migración del repositorio:

Figura. Comando de migración remoto de repositorio

Conexión al servidor de despliegue

Para realizar el despliegue al servidor de producción se realizo el uso de conexión vía ssh con el mismo. Para poder ejecutar esta conexión ssh fue necesario agregar en el archivo travis.yml el paquete “sshpass”

Figura. Importando paquete “sshpass” para conexión vía ssh

Y como se observa anteriormente en el contenido de after_succes, se tiene el siguiente comando:

Figura. Comando encargado de ejecutar el despliegue

En cual referencia el usuario, la password y la ip del servidor de despliegue. Y finalmente el archivo configurado deploy.sh

Notificaciones

Se ha decido usar el correo electrónico de cada integrante del grupo para la recepción de notificaciones del estado de las pruebas realizadas en Travis CI, dicha configuración la encontramos en la siguiente figura:

Figura. Configuración Travic CI para las notificaciones

De esta manera damos por terminada la primera aproximación a una tubería de Integración y Despliegue Continuo por parte del grupo de trabajo SHELLSYSTEM.

Show your support

Clapping shows how much you appreciated loencontre.co’s story.