Como regalo de fin de año os dejamos este artículo en el que te explicamos como configurar todo nuestro proyecto Wordpress en CI (Integración continua) con Azure DevOps y SonarCloud. El CD (Despliegue continuo) lo dejamos para otro artículo cuando lo tengamos configurado y probado.

Este artículo es la continuación de este otro en el que explicamos como incluir test unitarios con tu tema de WordPress. Como la explicación de como configurar el CI es demasiado extensa, lo dividiremos en dos artículos: por un lado vamos a explicar nuestra configuración a nivel general y por otro lado, haremos un artículo específico de como ejecutar los tests y configurar la cobertura de código.

WordPress en Azure Devops - Precondiciones

Antes de empezar tenemos que explicar de qué condiciones partimos para montar el CI en nuestro proyecto. En dev&del, como herramienta de ALM y de CI/CD usamos Azure DevOps, y como herramienta de análisis de código estático SonarCloud.

Por tanto el objetivo/reto era configurar el CI de nuestro proyecto WordPress bajo estas dos herramientas. Hemos de decir, que nos queda una tercera pata que sería configurar Snyk, pero esto ya lo dejamos para el nuevo año 😊.

WordPress en Azure Devops - ¿Qué vamos a configurar en nuestro sistema CI?

Dentro de nuestro ecosistema de integración continua vamos a configurar ciertas tareas, pero nada extraordinario: Code review, análisis de código con Sonar, configuración de sonarLint, Ejecución de tests y cobertura de código.

Si habéis leído alguno de estos artículos: PhPUnit con tu tema de WordPress, Aplicando Code Review en Dev&Del, Clean Code. Cleaning the code, Cleaning the code: Nomenclatura o la importancia de llamarse Ernesto o Cleaning the Code: Introducción al testing, ya habréis visto que es un pilar para nosotros mantener la máxima calidad de código y transferir conocimiento entre los desarrolladores es el uso de code review. Por tanto el primero punto es configurar las revisiones de código en el proyecto.

El siguiente paso es enlazar nuestro proyecto con SonarCloud y el último y más complicado conseguir que la pipeline de integración continua ejecute los tests unitarios, genere el informe de cobertura y lo publique en Sonar.

Configuración de code review

La configuración de code review con Azure DevOps es realmente sencillo, únicamente tienes que seguir estos pasos:

A partir de aquí el equipo puede configurar ciertas reglas. En nuestro caso, hemos decidido:

Además, hemos configurado los usuarios predeterminados que se añaden como revisores para que no tengamos que añadirlos manualmente en cada PR.

Enlazar vuestro proyecto con Sonar

Este punto tampoco tiene mucho misterio y es bastante rápido tenerlo listo.

Nosotros lo primero que hemos hecho es configurar el sonar cloud con nuestro Azure DevOps de forma que tenemos ya de entrada todos nuestros proyectos disponibles.

Los pasos a seguir te los indica el propio SonarCloud, por lo que no merece la pena incluirlos en este artículo, ya que es probable que queden obsoletos bajo cualquier cambio ya sea de Azure DevOps o de Sonar, y no tienen más misterio que leer cuidadosamente las instrucciones que te indican (en el primer intento, al menos yo, siempre me salto alguno). De todas formas para facilitar como tiene que quedar la pipeline en Azure DevOps os muestro un ejemplo:

# PHP
# Test and package your PHP project.
# Add steps that run tests, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/php

trigger:
  - develop

pool:
  vmImage: ubuntu-latest

variables:
  phpVersion: 7.4

steps:

  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: "devanddel_sonar"
      organization: "devanddel"
      scannerMode: "CLI"
      configMode: "file"
      projectKey: "sonar.projectkey"
      projectName: "sonar.projectName"
      extraProperties: |
        sonar.projectKey=Devanddel_devanddel-web-wp
        sonar.projectName=devanddel-web-wp

  - task: SonarCloudAnalyze@1

  - task: SonarCloudPublish@1
    inputs:
      pollingTimeoutSec: "300"

Para acabar de configurar correctamente el CI asociado a las PRs es necesario indicarle a Azure DevOps que tiene que validar las pull request usando esta pipeline, es decir, que cuando se lance una PR ejecute esta pipeline y se valide el nuevo código con Sonar importando los comentarios de calidad de código que Sonar genere.

Para ello lo que tenemos que hacer es ir a las políticas de rama (Branch policies) de nuestra rama principal de desarrollo (en nuestro caso develop) y añadir la pipeline que acabamos de generar en Build validation

Configuración de sonarLint

En estos momentos ya estamos, tras cada PR revisando nuestro código con una herramienta como Sonar, y esto es perfecto porque nos vamos a forzar a que la calidad de nuestro código suba un punto. Pero si tenemos que esperar a acabar nuestras features, subir nuestro código al repositorio y hacer una pull request para saber si estamos metiendo la pata con algo es bastante lento. Lo ideal es poder hacer estas mismas comprobaciones, o al menos la mayor parte de ellas, en el momento en el que estamos desarrollando.

Para que el propio IDE (VSCode en nuestro caso) nos muestre las advertencias podemos usar SonarLint, un linter de Sonar configurable en tu IDE que te va analizando el código según lo escribes.

Debemos tener en cuenta que dentro de SonarCloud podemos crear nuestras propias reglas basándonos en unas estándar, ya sea cambiar el tamaño máximo permitido de línea, usar uno de los diferentes estándares que existe dentro de un lenguaje, o aplicar una regla concreta de nuestro cliente. El problema es que si hacemos esto a priori nuestro lint local no tendrá estas reglas y no es la mejor idea tener un documento con todas reglas que cada programador se tenga que configurar. Con SonarLint lo que podemos hacer es sincronizar nuestro proyecto local con nuestro proyecto SonarCloud y «mágicamente» se sincronizarán las reglas de sonarCloud con nuestro sonarLint en local.

Para ello tendrás que configurar tu sonarLint local con los datos del Cloud. En nuestro caso usando VSCode, tenemos que hacer dos configuraciones:

La configuración de la conexión la hacemos dentro de las configuraciones de la extensión SonarLint a nivel de User:

modo de conexión para SonarCloud:

Y ahí configuramos la conexión a nuestro SonarCloud

"sonarlint.connectedMode.connections.sonarcloud": [
  
    {
      "connectionId": "devanddel",
      "organizationKey": "devanddel"
    }
  ],

Te pedirá la configuración de un token de seguridad.

Para configurar el proyecto, dentro del fichero settings.json (en la carpeta .vscode) tendrás que configurar la conexión configurada a nivel de usuario y el identificador del proyecto:

"sonarlint.connectedMode.project": {
    "connectionId": "devanddel",
    "projectKey": "Devanddel_devanddel-web-wp"
  }

Ejecución de tests y cobertura de código

Como adelantamos al principio del artículo, esta parte la dejamos para el siguiente artículo del blog.

Esperamos que esta forma de configurar WordPress en Azure Devops os vaya tan bien como a nosotros.

¡Hasta la próxima!