Análisis estático de código en Pull Requests con Pronto
En la mayoría de los lenguajes de programación existen herramientas de análisis estático de código en las que se evalúa la calidad del mismo y se comprueba que se siguen una serie de reglas básicas de estilo.
Esto es importante ya que un proyecto en el que trabajan varios desarrolladores y desarrolladoras será mas fácil de leer, entender y de trabajar con él si todos los implicados generan el código siguiendo unas pautas comunes.
En Ruby, por ejemplo, contamos con Rubocop como referente a seguir en cuanto a reglas de estilo del lenguaje. Estas reglas han sido creadas y son revisadas por la comunidad del lenguaje.
Rubocop se puede instalar en nuestro entorno de desarrollo y usarlo en nuestro día a día para comprobar que el código que estamos escribiendo sigue los estándares establecidos por la comunidad, sin embargo este procedimiento puede no ser todo lo efectivo que debería, ya que recae en el desarrollador la responsabilidad de revisar su código.
Para mejorar este proceso podríamos usar algún SaaS que realice las comprobaciones pertinentes en los Pull Requests de nuestro proyecto (por ejemplo podríamos usar Hound CI), pero si ya contamos con algún sistema de integración continua como TravisCI o CircleCI no nos será necesario delegar las comprobaciones a ningún SaaS, que ya que estos sistemas nos permiten lanzar scripts en varias fases de nuestra suite de test. Aprovecharemos esta funcionalidad para lanzar nuestro propio comando de revisión de código.
Pronto
Pronto es una herramienta creada específicamente para comprobar los cambios realizados en un Pull Request, ya sea en Github, Gitlab o Bitbucket. Cuenta con distintos plugins según lo que se quiera revisar, en este ejemplo de configuración usaremos una aplicación Rails como base y revisaremos las reglas de estilo con Pronto que a su vez usará Rubocop.
Configuración de la aplicación Rails
En nuestra aplicación necesitaremos instalar para los entornos de development y test las gemas de pronto y pronto-rubocop:
Desde este momento podemos comprobar en nuestro entorno de desarrollo si el código que generamos sigue las reglas de estilo de Rubocop, por ejemplo si añadimos el siguiente código a nuestro modelo Article y posteriormente ejecutamos pronto:
De esta forma podemos revisar el código que acabamos de añadir previamente a su subida, pero queremos que esto se haga automáticamente, ¿no?
Revisión en los Pull Requests
El siguiente paso es que se ejecute automáticamente cada vez que se realice un Pull Request en nuestro proyecto de Github, para esto usaremos las posibilidades que nos brinda nuestro sistema de integración continua, en nuestro caso Travis.
Para ello tendremos que añadir/actualizar el fichero .travis.yml con la siguiente configuración:
Con la variable de entorno TRAVIS_PULL_REQUEST obtenemos el ID del Pull Request que estamos revisando y ejecutaremos Pronto únicamente en los cambios que existan en la rama con respecto a origin/master.
En este caso se ha configurado la revisión después de la ejecución satisfactoria de los tests, pero tienes bastantes hooks distintos entre los que elegir.
Antes de poder comprobar que todo funciona correctamente tendremos que crear un token de acceso al repositorio de Github y añadirlo a la build de Travis.
Para ello desde la configuración de tu cuenta en Github genera un nuevo token que solo tenga permisos de lectura del repositorio:
Una vez tengas la clave creada solo tienes que añadirla como variable de entorno de tu build de Travis con el nombre PRONTO_GITHUB_ACCESS_TOKEN
Si todo ha ido bien puedes crear un nuevo Pull Request en tu proyecto y comprobar que pronto hace su trabajo.
Este sería el resultado con el código del ejemplo anterior:
Conclusión
El abanico de herramientas a nuestro servicio para mejorar nuestro trabajo es inmenso, desde revisar el estilo hasta comprobaciones de seguridad y complejidad de nuestro código.
Aquí solo hemos visto un pequeño ejemplo que puede ser explotado mucho más según las necesidades de cada equipo de trabajo.
Lo importante es que sometamos nuestro código a unas pruebas que certifiquen que cumplimos con un estándar de calidad y que nos permitan centrarnos en la lógica de nuestra aplicación. Además facilitaremos tanto la rotación del equipo entre proyectos como el mantenimiento de los mismos.
