Desplegando código con Phing, PHPUnit, Coder y Jenkins

www.ladrupalera.com@ladrupalera

José Antonio Rodríguez Bonilla

 

 

Índice de contenidos 

Introducción Consideraciones Configurando Github Realizando nuestra primera tarea Implementando Drupal Developer Plugin Integrando Phing Elaborando nuestro primer Test  

Referencias Web externas 

 

VP1.9  1 / 20  

 

 

Manual de uso

Introducción El objetivo de esta guía no es detallar los pasos para la instalación de las herramientas que se comentan a continuación. Más bien nos centraremos en el flujo de despliegue y revisión del código que generamos desde un entorno local hacia otro remoto, tomando como fuente de datos un repositorio de datos (en este caso Github), pasando por la revisión y análisis de dicho código mediante herramientas externas que nos ayudarán a garantizar unos mínimos de calidad antes de realizar un despliegue. Para ello, y antes de entrar en materia, daremos por supuesto que tenemos instalado Jenkins en un servidor con los siguientes Plugins. No obstante, en lo sucesivo iremos comentando en qué momento debemos instalar cada uno de los plugins:

● Drupal developer plugin ● Git client plugin ● Git plugin ● Github plugin ● Phing plugin ● XUnit plugin

Además de esto, deberemos tener instalados los siguientes servicios en nuestra máquina de integración:

● PHPUnit ● Phing ● PHP (5.4) ● Git

Consideraciones Lo que se pretende ofrecer en esta guía es una serie de pasos que garantice, mediante la fusión de ramas a través de Github (Merge), la ejecución de una serie de procesos que garantice que el código mergeado en una rama cumpla con los requisitos funcionales, además de garantizar una sintaxis adecuada, antes de un despliegue, de forma que podamos automatizar una serie de tareas que generalmente realizamos a mano. Para ello, utilizaremos como herramienta motora Jenkins, encargada de centralizar todo el proceso de revisión y garantía del código, asumiendo la responsabilidad de realizar un despliegue en caso de éxito o bien, detener dicho despliegue y avisar a los responsables de los errores cometidos. Jenkins es un software de Integración continua open source escrito en Java. Está basado en el proyecto Hudson y es, dependiendo de la visión, un fork del proyecto o simplemente un cambio de nombre. Jenkins proporciona integración continua para el desarrollo de software. Es un sistema corriendo en un servidor que es un contenedor de servlets, como Apache Tomcat. Soporta herramientas de control de versiones como CVS, Subversion, Git, Mercurial,

 

VP1.9  2 / 20  

 

 

Perforce y Clearcase y puede ejecutar proyectos basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch de Windows. El desarrollador principal es Kohsuke Kawaguchi. Y pasamos a la práctica directamente. Para ello, debemos configurar en primer lugar una serie de tareas o jobs en Jenkins de forma lineal. Es decir, si la primera tarea no cumple con los requisitos deseados, no pasaremos a la siguiente. Esto nos permite atomizar los procesos involucrados en la revisión de un despliegue:

1. Análisis de comentarios, seguridad y sintaxis a través de Coder 2. Ejecución de tests unitarios 3. Despliegue en el entorno

Estas tareas se ejecutarán de forma secuencial, de manera que si una de ellas no cumple con los requisitos deseados, el proceso se detendrá automáticamente notificando a las partes implicadas de las incidencias producidas durante el despliegue. Las condiciones previas que deberían darse antes de iniciar este proceso son las siguientes:

● Tener un entorno remoto versionado en Github apuntando a una rama, en este caso ‘Staging’

● Tener un entorno local versionado en nuestra máquina, a ser posible a través de un Fork de la rama principal de Staging, de forma que tengamos la posibilidad de solicitar integraciones en la rama principal. No obstante, este flujo es relativo y se basa en el ejemplo real citado a continuación, pero las posibilidades en cuanto a tests basados en haltonfail son prácticamente infinitas.

En el ejemplo que tratamos a continuación, el servidor Jenkins ha sido instalado en la misma máquina donde integraremos el código a través de Github. No obstante, podría estar perfectamente en una máquina remota y realizar un despliegue a través de SSH en un servidor remoto. Si este fuera el caso, un error muy frecuente a tener en cuenta es el acceso mediante el par de claves pública/privada del usuario Jenkins que ejecuta las peticiones en el servidor remoto de despliegue, por lo que sería aconsejable realizar previamente una conexión desde la consola del servidor Jenkins a la máquina remota con el usuario jenkins (que instala el servidor por defecto) para comprobar que el acceso se realiza sin problemas de autenticación. Además de esto, también es importante revisar los accesos mediante SSH al repositorio Github donde tengamos alojado nuestro código de integración para asegurarnos que el usuario jenkins puede acceder al mismo y realizar escrituras.

Configurando Github Sabiendo esto, vamos a establecer el primer paso la llamada automática al trigger o disparador de Jenkins en Github cuando se produce un Merge en una rama determinada. Para ello, en nuestro repositorio principal (o de integración) deberemos acceder a la configuración del repositorio mediante la pestaña ‘Settings’:

 

VP1.9  3 / 20  

 

 

Después, debemos acceder a la pestaña ‘Webhooks & Services’:

En esta ventana, debemos acceder el servicio ‘Jenkins (Github Plugin)’:

Para configurar el servicio, nos solicitará un URL de acceso que utilizará para avisar a Jenkins mediante una petición POST de que ha habido un merge en una rama. Para conocer esta URL, debemos acceder a la configuración de Jenkins ‘Administrar Jenkins’, y acceder a la ‘Configuración del sistema’. Si hemos instalado el Github Plugin correctamente, podremos ver la URL que debemos poner en su sección correspondiente:

NOTA: Para ver la ruta habrá que hacer click en el icono de interrogación que aparece a la derecha. Una vez introducida esta URL en Github, éste nos permite realizar un test a través de un botón de acción. No obstante, el ‘status’ de esta petición no se actualiza hasta que se realiza una petición real a través de un Merge (al menos en los ejemplos realizados durante la redacción de este documento), por lo que no debemos preocuparnos demasiado por este asunto de momento.

 

VP1.9  4 / 20  

 

 

Realizando nuestra primera tarea Una vez hemos concluido la configuración de nuestro repositorio en Github y hemos finalizado la instalación y configuración de Jenkins, vamos a pasar a configurar nuestra primera tarea. Para ello, hacemos click en el primer item del bloque de la izquierda de nuestro Jenkins ‘Nueva tarea’:

Una vez hacemos click en este item, crearemos un nuevo proyecto de estilo libre, y pondremos un nombre de prueba para la tarea:

Una vez hacemos click en OK, pasamos a la siguiente pantalla, de la cual resaltamos los aspectos más importantes a nivel de configuración:

 

VP1.9  5 / 20  

 

 

Hemos destacado 3 opciones, aunque podemos realizar diferentes pruebas con el resto de configuraciones:

● Github project: marcando este item, introduciremos la URL de nuestro repositorio. ● Dentro de ‘Configurar el origen del código fuente’, deberemos marcar la opción Git, y

aquí tendremos que introducir la URL del proyecto. En este caso, no introduciremos la URL del repositorio, sino aquella utilizada para poder hacer un checkout del mismo. Esto se puede hacer de dos maneras:

○ Mediante SSH: si lo hacemos así, tendremos que asegurarnos que el usuario Jenkins de nuestra máquina tiene acceso al repositorio que queremos configurar. Esto lo configuraremos en nuestro repositorio en Github otorgando permisos a través de la clave pública del usuario.

○ Mediante HTTPS: con esta alternativa, Jenkins nos permitirá introducir las credenciales del usuario con acceso al repositorio. De esta forma, dicho usuario también tendría que tener acceso a este repositorio.

Podemos ver información de estas URL dentro de nuestro propio repositorio en Github tal y como se muestra en la imagen a continuación:

En este aspecto, es importante resaltar un punto. Una vez hemos introducido las credenciales o bien el acceso SSH en nuestro Jenkins, al pulsar el botón tabulador Jenkins internamente comprobará el acceso al repositorio. Si existe algún problema con las credenciales, en este momento dará un aviso notificando del error de acceso. Si este es el caso, sería necesario comprobar que la comunicación entre nuestro usuario Jenkins y el repositorio en Github se está produciendo (en el caso del acceso por SSH), o bien comprobar que las credenciales introducidas (HTTPS) son correctas para el acceso a dicho repositorio.

 

VP1.9  6 / 20  

 

 

Una vez hemos asegurado que las credenciales son correctas, debemos especificar la rama sobre la que queremos trabajar; en este caso hemos optado por la rama por defecto (master). El siguiente punto, ‘’Build when a change is pushed to Github” es que el que nos dará la clave para automatizar la tarea que necesitemos. Esta opción indica a Jenkins que debe ejecutar esta tarea cuando alguien realiza un push o un merge en la rama master que hemos configurado, por lo tanto esta opción es vital para poner en marcha nuestro proceso de despliegue automático. Ahora, solo nos quedaría configurar la acción a realizar cuando se detecte un push en nuestra rama master. En nuestro caso, debido a que nuestro servidor Jenkins está instalado en el mismo servidor que nuestro entorno de integración, bastaría con añadir un nuevo paso y ejecutar un comando a través de la shell:

En este caso, el comando básicamente cambia la ubicación del sistema al DOCUMENT ROOT de nuestro servidor apache y realiza un PULL desde la rama master con el usuario developer. Si tuviésemos nuestro entorno de integración en una máquina remota, bastaría con realizar esta misma acción a través de SSH. Con esta tarea ya tenemos nuestro primer despliegue automático a través de Jenkins.

Implementando Drupal Developer Plugin Una vez que hemos visto cómo realizar un despliegue directo a través de Jenkins en un entorno, vamos a añadir una nueva “capa de dificultad”. En este caso vamos a aplicar una validación de código a través del plugin ‘Drupal Developer Plugin’, un módulo de Jenkins que implementa una serie de validaciones de coding estandar y genera las métricas necesarias para evaluar la calidad del código. Este ejemplo sólo sería válido si estamos trabajando sobre un gestor de contenido basado en Drupal y queremos ser respetuosos con los estándares de código. Para ello, antes de crear una nueva tarea, vamos a añadir una nueva configuración a la tarea que hemos creado anteriormente para que ésta solo se lleve a cabo siempre y cuando la validación a través del plugin de Jenkins haya sido satisfactoria. En la configuración de nuestra tarea de despliegue, marcamos la siguiente opción:

 

VP1.9  7 / 20  

 

 

Además, vamos a desactivar la opción que activamos anteriormente ‘’Build when a change is pushed to Github” para evitar que esta tarea se ejecute automáticamente, y solo lo haga cuando la tarea que vamos a crear ahora haya cumplido todos los requisitos que necesitamos. En un ejemplo real, realmente esta configuración habría que hacerla después de haber creado la tarea de prueba con el plugin ‘Drupal Developer Plugin’, de lo contrario Jenkins no reconocería la prueba que hemos introducido en este ejemplo, pero la ponemos aquí para darle continuidad a nuestro trabajo. Básicamente estamos especificando que solo se realice un despliegue en nuestro entorno de integración siempre y cuando la tarea ‘Prueba Coder’ se haya ejecutado con éxito. El siguiente paso sería, en primer lugar, instalar los plugins necesarios para Jenkins. Para ello, desde la administración de Jenkins, accedemos a la sección de administración de Plugins:

Una vez aquí, debemos buscar e instalar los siguientes plugins:

● Checkstyle Plug-in: este plugin es necesario para generar las métricas a través de Jenkins y poder evaluar los resultados de los archivos generados.

● Drupal Developer: este plugin realiza una serie de análisis sobre nuestro código fuente para evaluar su calidad, parámetros de seguridad, etc.

No vamos a centrarnos aquí en los pormenores de la instalación, ya que existe documentación en la web oficial de Jenkins sobre estos plugins que describen bastante bien su funcionamiento e instalación. Pasamos pues directamente a crear una nueva con las mismas características que la anterior (Proyecto libre), poniendo el nombre que consideremos oportuno, y pasamos a describir la configuración de la tarea. Para el origen de datos (Github) y la URL del

 

VP1.9  8 / 20  

 

 

repositorio, la configuración sería exactamente la misma, por lo que vamos a obviar de nuevo la explicación de estos parámetros. Como en la anterior tarea desmarcamos finalmente la opción ‘Build when a change is pushed to GitHub’, vamos a marcarla en esta nueva tarea, de forma que sea ésta la que se ejecute en primer lugar, y en caso de éxito pase a la tarea de despliegue como ya configuramos anteriormente. En este caso, tendríamos que añadir un nuevo paso denominado ‘Review code on Drupal’:

En esta prueba, vamos a marcar todos los tests para asegurar la integridad del código en todos sus niveles. Los parámetros a configurar son los siguientes (es necesario pulsar el botón ‘Avanzado’ para ver todas las opciones):

● Drupal root directory: DOCUMENT ROOT de nuestro gestor de contenidos ● Logs directory: directorio en el que el plugin generará los archivos XML con los

resultados de los tests ● Exclude these modules/themes: es importante configurar bien este apartado, ya que

para obtener unos resultados que luego nos sirvan realmente de interés, ignoraremos todos aquellos directorios que no nos vayan a reportar información de interés para nuestro propósito. En nuestro caso, hemos ignorado todas las carpetas de módulos exceptuando la carpeta ‘custom’ o ‘main’ dentro de ‘sites/all/’, ya que es en esta ubicación donde almacenaremos nuestros módulos personalizados, es decir, aquellos que realmente nos interesa evaluar.

Una vez realizado este paso, debemos añadir una acción para poder evaluar los resultados de los tests generados por el plugin. Para ello, hacemos click en ‘Añadir paso’ y agregamos la opción ‘Public Checkstyle analysis results’ con los siguientes parámetros:

 

VP1.9  9 / 20  

 

 

Pasamos a describir los parámetros más significativos:

● Checkstyle results: es la carpeta donde el plugin Drupal Developer genera los archivos XML de los resultados de los tests realizados (hemos configurado esta carpeta en el paso anterior). De esta forma, el plugin Checkstyle analizará todos los archivos XML ubicados en este directorio para generar las métricas necesarias.

● Health priorities: desde aquí podemos priorizar las tareas que nos interesa analizar en función de su prioridad

● Status thresholds (Totals): desde aquí podemos configurar el plugin para que su resultado sea exitoso o fallido en función del número de incidencias detectadas y su prioridad. Es aquí donde podemos refinar nuestra herramienta hasta encontrar la flexibilidad/rigidez adecuada para el desarrollo de nuestro proyecto.

Una vez hemos guardado nuestra nueva tarea, es hora de ejecutarla a través de la pantalla principal de Jenkins:

Es importante resaltar que, en el caso de que una tarea haya detectado alguna incidencia, siempre nos resultará muy útil la información que Jenkins almacena para intentar detectar el problema:

 

VP1.9  10 / 20  

 

 

Suponiendo que nuestra tarea ha tenido éxito, bien considerando que ha pasado todos los estándares de calidad necesarios, o bien asumiendo que se ha detectado alguna inconsistencia en el código que ha impedido la ejecución de la siguiente tarea, si hacemos click en el desplegable que aparece junto al nombre de nuestra tarea veremos una serie de opciones, entre las que tenemos que elegir ‘Checkstyle Warnings’ (esta opción sólo aparecerá si se ha configurado debidamente el plugin Checkstyle y se han generado los reportes necesarios, en caso contrario sería conveniente revisar los logs para detectar los problemas ocurridos):

 

VP1.9  11 / 20  

 

 

Una vez hacemos click, nos apareceŕan por fin las métricas de nuestros resultados:

Podemos resaltar tres secciones interesantes:

● Files: aquí podremos ver un listado general de todos los archivos con problemas detectados, junto al número de incidencias por archivo.

● Warnings: desglose de cada uno de las incidencias detectadas, junto a su prioridad. Además, si hacemos click en alguno de estos errores, el plugin nos presenta el interior del archivo remarcando el error detectado.

● Details: aquí podemos ver una descripción ampliada de los errores detectados

Integrando Phing Para entrar en contexto, Phing es un port de Apache Ant destinado a la ejecución de tareas, como puede ser la creación de carpetas, actualizaciones sobre un repositoiro, elaborar tests de PHP Unit, etc. todo ello configurado en un archivo XML que después será ejecutado por Jenkins. De esta forma, podemos generar un archivo XML con una serie de tests personalizados que luego se integrarán en el flujo de despliegue de Jenkins. En nuestro ejemplo, vamos a elaborar un test personalizado que ejecutaremos con PHP Unit, para luego poder evaluar los resultados obtenidos del test y poder visualizar el resultado de esta información con el ‘xUnit Plugin’ de Jenkins. Bien, de antes ponernos a instalar plugins de Jenkins, es necesario instalar Phing en el servidor de integración continua. La mejor manera de instalar Phing es a través de PEAR y del canal PEAR de Phing, así pues hay que entrar en la terminal e introducir los siguientes comandos:

pear channel-discover pear.phing.info pear install --alldeps phing/phing

pear channel-discover pear.phing.info

 

VP1.9  12 / 20  

 

 

Para asegurarnos que la instalación se ha realizado correctamente, podemos ejecutar el siguiente comando en la consola del sistema:

phing -v

Lo siguiente que tendremos que hacer será crear un fichero en la raíz de nuestro proyecto con el nombre build.xml y ahí escribir las tareas o targets. Si ejecutamos ‘phing’ en la consola del sistema, éste intentará localizar el archivo build.xml en el directorio donde hayamos ejecutado el comando. Si no encuentra este archivo, Phing te devuelve un error indicando que no ha encontrado el archivo. Lo bueno de las tareas automatizadas es que no son independientes unas de otras, sino que desde una tarea puedes hacer una llamada a otra o incluso pueden existir tareas que dependan de otras para que puedan ser ejecutadas. No es el objetivo de este manual describir con más detalle la estructura del archivo XML ni su relación de dependencias, aunque existe documentación bastante bien detallada sobre su configuración. El siguiente paso, antes de entrar en el detalle de nuestro archivo XML, será instalar PHPUnit, que es el framework que utilizaremos en este ejemplo para la ejecución de tests unitarios sobre nuestro código. Antes de poder instanciar sus clases y programar la creación de un test, es necesario instalar dicho framework en el sistema. Para ello, podemos descargarlo de su repositorio oficial y ubicarlo dentro de nuestro sistema:

wget https://phar.phpunit.de/phpunit.phar chmod +x phpunit.phar sudo mv phpunit.phar /usr/local/bin/phpunit phpunit --version

Si todo ha ido bien, el sistema nos reportará la versión de PHP Unit instalada. En nuestro ejemplo, usaremos PHPUnit 4.8.24 junto a la versión 5.4.45 de PHP. Damos por hecho que estamos ejecutando estos tests en una máquina con esta versión de PHP o superior instalada.

Elaborando nuestro primer Test Aunque no es objeto de este manual indagar en el uso de PHP Unit para la elaboración de tests unitarios, diremos que PHPUnit se creó con idea de que cuanto antes se detecten los errores en el código antes podrán ser corregidos. Este conocido framework para PHP nos permite crear y ejecutar juegos de tests unitarios de manera sencilla. Como todos los frameworks de pruebas unitarias, PHPUnit utiliza assertions para verificar que el comportamiento de una unidad de código es el esperado. El objetivo de las pruebas unitarias es aislar cada parte del programa y demostrar que las partes de forma individual son correctas. Una prueba unitaria proporciona un contrato escrito que la pieza de código debe satisfacer. Como resultado, las pruebas unitarias encuentran problemas en las fases

 

VP1.9  13 / 20  

 

 

iniciales del desarrollo de software. La idea detras de un assert es crear un objeto, ejecutar algunas funciones y después comprobar su estado interno. Lo mejor es utilizar un ejemplo para ilustrarlo:

class TddTests extends PHPUnit_Framework_TestCase { public function test_tdd_help() { $this->assertEquals(1,1); } }

Como observamos en el código, básicamente lo que hemos hecho es crear una clase TddTests heredada de la clase PHPUnit_Framework_TestCase. Es aquí dentro donde podremos elaborar la programación de los tests. Existen infinidad de asserts proporcionados por PHPUnit para la elaboración y ejecución de diferentes tipos de tests unitarios, aunque en nuestro ejemplo utilizaremos un caso sencillo mediante el assert assertEquals. Este assert compara dos cadenas de texto pasadas por argumento, y nos devolverá un resultado TRUE/FALSE en función de si estas dos cadenas son iguales (TRUE) o diferentes (FALSE). Nuestra función test_tdd_help que invoca al assert devolverá en cualquier caso un resultado positivo, ya que los dos argumentos comparativos que le pasamos a nuestro assert son iguales, no obstante, este ejemplo nos permite hacernos una idea del funcionamiento básico de un assert con PHPUnit y el poder que obtenemos con la ejecución de este tipo de tests. Antes de entrar en la configuración del test unitario a través de Phing, vamos a asegurarnos que nuestro test está bien programado y podemos ejecutarlo sin problemas a través de la consola. De esta forma, si posteriormente nos encontramos con algún problema de configuración, podremos aislar los problemas más fácilmente y detectar con más facilidad el punto de fallo. Para ello, vamos a crear un archivo llamado TddTests.php ubicado, desde el DOCUMENT ROOT de nuestra instalación de Drupal, en sites/all/modules/main/tdd con el siguiente contenido. Aunque la ubicación o los nombres de los archivos pueden cambiar en función de nuestras necesidades, hemos establecido esta ubicación únicamente para ilustrar el ejemplo:

<?php define('DRUPAL_ROOT', '/var/www'); require_once DRUPAL_ROOT . '/includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); class TddTests extends PHPUnit_Framework_TestCase { public function test_tdd_help() { $this->assertEquals(1,1);

 

VP1.9  14 / 20  

 

 

} } ?>

Las tres primeras líneas cargan el bootstrap de Drupal en caso de que tuviéramos que hacer uso de su API. Aunque en este ejemplo no es estrictamente necesario, lo referenciamos por si el lector quiere ampliar el código de este ejemplo apoyándose en la API de nuestro CMS. El resto contiene la clase que hemos comentado anteriormente, integrando el assert assertEquals que, en todo caso, nos devolverá un resultado positivo. Ubicándonos de nuevo en el DOCUMENT ROOT de nuestro portal, ejecutamos en consola el siguiente comando:

phpunit sites/all/modules/main/tdd/TddTests.php

Si todo ha ido bien, el framework nos devolverá la siguiente respuesta por pantalla:

PHPUnit 4.8.24 by Sebastian Bergmann and contributors. . Time: 392 ms, Memory: 42.75Mb OK (1 test, 1 assertion)

En este caso, nos indica que se ha ejecutado un test con un assert, sin ningún error encontrado. Vamos a realizar ahora una modificación en nuestro archivo PHP cambiando el valor de uno de los dos argumentos, de forma que el assert nos devuelva un resultado negativo. Volvemos a ejecutar nuestro comando por consola y ahora el resultado es:

PHPUnit 4.8.24 by Sebastian Bergmann and contributors. Time: 392 ms, Memory: 42.75Mb There was 1 failure: 1) TddTests::test_tdd_help Failed asserting that 0 matches expected 1. /var/www/sites/all/modules/main/tdd/TddTests.php:10 FAILURES! Tests: 1, Assertions: 1, Failures: 1.

 

VP1.9  15 / 20  

 

 

Como vemos en el ejemplo, en esta ocasión, además de informarnos de la ejecución completa del test, nos indica que ha detectado un error, y sabiendo esto, únicamente nos queda recuperar la información resultante del test para poder tratarla con alguna herramienta (¿os imagináis cual?) y poder interactuar con el flujo de despliegue en función de los resultados de los tests. Volvemos pues al punto de partida con Phing. Ahora que ya sabemos para qué sirve PHP Unit, y hemos comprobado su funcionamiento a través de un sencillo ejemplo a través de un comando por consola, estamos preparados para integrar esta funcionalidad a nuestra herramienta de integración continua, estableciendo su configuración con el apoyo de Phing. Vamos pues a crear nuestro primer archivo build.xml en el raíz de nuestro plataforma, o bien ubicarlo en algún directorio que sea accesible con posterioridad con Jenkins. El contenido del archivo es el siguiente:

<?xml version="1.0"?> <project name="MyApplication" default="build"> <property name="package" value="MyApplication" override="true" /> <target name="clean"> <delete dir="../reports"/> </target> <target name="prepare"> <mkdir dir="../reports/logs"/> </target> <target name="phpunit">

<phpunit printsummary="true" haltonfailure="true" pharlocation="/usr/local/bin/phpunit"> <formatter todir="../reports/logs" type="xml"/> <batchtest> <fileset dir="../"> <include name="src/sites/all/modules/main/tdd/TddTests.php"/> </fileset> </batchtest> <formatter type="xml" todir="../reports" outfile="logfile.xml"/> </phpunit> <phpunitreport infile="../reports/logfile.xml" styledir="/usr/share/php/data/phing/etc" format="frames" todir="../reports"/> </target> <target name="build" depends="clean,prepare,phpunit"/> </project>

Como hemos comentado anteriormente, no es objetivo de este manual entrar en profundidad a explicar la creación y configuración de este archivo, no obstante, pasaremos a comentar algunas etiquetas que resultan interesantes para entender su funcionamiento:

● delete dir y mkdir: le indicamos la ubicación de nuestro directorio de reportes para que lo borre antes y lo vuelva a crear de comenzar la ejecución de nuestros tests

● phpunit: le indicamos la ruta de nuestro ejecutable PHP Unit

 

VP1.9  16 / 20  

 

 

● formatter todir: indicamos donde deberán almacenarse nuestros reportes, y en qué formato

Posteriormente indicamos la ruta de nuestro test, además de especificar el nombre de nuestro archivo ‘logfile.xml’ con los resultados de nuestros tests. Como ya hicimos anteriormente con PHPUnit, es hora de probar de forma aislada la composición de nuestro archivo build.xml y comprobar que funciona correctamente antes de integrarlo directamente en Jenkins, de esta forma nos aseguraremos que la estructura de nuestro archivo XML es correcta, y como ya hemos asegurado antes que nuestro test unitario funcionaba correctamente, ahora vamos a subir un nuevo peldaño incluyendo dicha ejecución a través de Phing. Bastaría con ejecutar por consola el siguiente comando en el mismo directorio que hemos creado nuestro archivo build.xml:

phing

Si nuestro archivo build.xml se encuentra en una ubicación diferente, podemos establecer la ruta del archivo con el parámetro -f. Si todo ha ido correctamente, el resultado por consola debería ser similar al siguiente:

Buildfile: /var/www/build.xml MyApplication > clean: [delete] Deleting directory /var/www/reports MyApplication > prepare: [mkdir] Created dir: /var/www/reports/logs MyApplication > phpunit:

[phpunit] Total tests run: 1, Failures: 0, Errors: 0, Incomplete: 0, Skipped: 0, Time elapsed: 0.00471 s MyApplication > build: BUILD FINISHED Total time: 0.1681 seconds

Bien. Llegados a este punto, creo que estamos suficientemente preparados para pasar la ejecución de nuestro test a través de Jenkins, nuestra herramienta de integración continua. Para ello, previamente hay que instalar los módulos ‘Phing Plugin’ para poder ejecutar nuestras tareas a través del archivo build.xml y ‘xUnit Plugin’, que nos permitirá la visualización de las métricas generadas por Phing. No vamos a entrar en más detalles sobre la instalación de Plugins en Jenkins porque ya lo hemos comentado anteriormente. Así que

 

VP1.9  17 / 20  

 

 

pasamos a crear directamente nuestra tarea, siguiendo los pasos anteriormente con el mismo origen de datos, la misma URL de nuestro repositorio, etc. Nos centraremos en la tarea específica que habrá que crear para ejecutar un script de Phing. Para ello, añadiremos un nuevo paso denominado ‘Invoke Phing Targets’. Este paso debería aparecer automáticamente si hemos instalado correctamente nuestros plugins:

El único aspecto aquí a remarcar es el campo ‘Phing Build File’. Simplemente tenemos que indicar la ruta donde hemos creado nuestro archivo build.xml partiendo de nuestro DOCUMENT ROOT. Otro aspecto muy importante a tener en cuenta aquí, y que suele ser la causa de muchos problemas, es el origen de los datos. Esto quiere decir que para que Jenkins pueda leer correctamente nuestro archivo build.xml, éste debe estar versionado en nuestro repositorio, ya que, recordamos, éste es el origen de datos de nuestra tarea en Jenkins, por lo tanto cualquier cambio que hayamos realizado en nuestro archivo build.xml debe estar correctamente actualizado en nuestro repositorio para que Jenkins pueda ejecutarlo. El siguiente paso consiste, dentro de la misma tarea, en añadir una nueva acción ‘Publish xUnit test result report’. Al igual que en el paso anterior, esta acción solo estará presente si hemos instalado correctamente nuestros plugins. Pasamos a describir la configuración de esta acción:

 

VP1.9  18 / 20  

 

 

De esta acción vamos a comentar dos aspectos importantes:

● Ruta de los reportes: es importante recordar que esta ruta debe coincidir con la ruta que hemos configurado en nuestro archivo build.xml de Phing, que es el encargado de generar dichos reportes.

● Failed Tests: aunque es bastante obvio, me limitaré a comentar que aquí podemos configurar la flexibilidad de nuestros avisos, de forma que podamos configurarlo de tal modo que la tarea pueda resultar exitosa o fallida en función del número de tests que se hayan ejecutado con éxito, etc.

Como comentamos en puntos anteriores, esta tarea puede ser configurada para que sea ejecutada antes o después de otras tareas en nuestro proceso de despliegue, aunque una vez conocida la práctica, creo que en este punto tenemos el conocimiento suficiente como para decidir en qué momento necesitamos ejecutar este test.

Web externas ● Jenkins:https://jenkins.io/ ● Phing: https://www.phing.info/ ● PHP Unit: https://phpunit.de/ ● Github: https://github.com/ ● xUnit Plugin: https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin ● Phing Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Phing+Plugin ● Git Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin ● Drupal Developer Plugin:

 

VP1.9  19 / 20  

 

 

https://wiki.jenkins-ci.org/display/JENKINS/Drupal+Developer+Plugin ● Checkstyle Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Checkstyle+Plugin

 

VP1.9  20 / 20  

www.ladrupalera.com@ladrupalera