Desplegando código con Jenkins, Phing, Coder y PHPUnit (Parte II)

27/04/2016
Desplegando código con Jenkins, Phing, Coder y PHPUnit (Parte II)

En un artículo anterior ya vimos como configurar Jenkins para realizar un deployment en un entorno remoto. En este capítulo trataremos la implementación del Plugin 'Drupal Developer' para la validación de nuestro coding standar.

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:

coder.png

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:

Administrar Jenkins  Jenkins .png

 

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 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’:

Prueba Coder Config  Jenkins .png

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:

Prueba Coder Config  Jenkins 2 .png

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:

Panel de control  Jenkins .png

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:

error jenkins.png

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):

checkstyle.png

Una vez hacemos click, nos aparecerán por fin las métricas de nuestros resultados:

Jenkins.png

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

Y esto es todo por ahora. En el próximo post nos adentraremos en el mundo de los tests unitarios a través de PHP Unit y su integracíon con Phing.