TruquiTrucos Dev – Automatizando el desarrollo de plugins para WordPress

Hace un par de semanas leí un artículo que me pareció extremadamente divertido (aunque ya tiene un par de años): un programador había escrito un montón de scripts para automatizar casi todo su trabajo, desde enviar correos a su mujer con excusas de porqué seguía en el trabajo hasta solucionar los tickets de soporte de un cliente pesado aplicando un rollback en su base de datos y diciéndole que «ya está todo arreglado; ten más cuidado la próxima vez» ?. ¡Desde entonces este tío es mi ídolo! Y es que, amigo, la máxima de todo buen informático es automatizar todo aquello que tengas que hacer más de dos veces.

¿Para qué repetir la misma acción una y otra vez, si puedes tener un script que haga el trabajo por ti? Las automatizaciones te permiten ahorrar tiempo. Tiempo que puedes dedicar a otros quehaceres más interesantes o productivos: atender a un cliente, aprender una nueva tecnología, corregir un bug, etc. Además, las automatizaciones evitan errores: cuando realizas una misma tarea una y otra vez, al final resultará tediosa, repetitiva y aburrida, con lo que las probabilidades de meter la pata serán mayores.

En la entrada de hoy me gustaría compartir contigo algunos de los scripts que usamos en Nelio para automatizar el empaquetado de nuevas versiones de nuestros plugins. Como verás, no se trata de nada excesivamente complicado, pero estoy convencido de que pueden serte útiles a ti también y que, además, quizás te sirvan de inspiración para crear tus propios scripts.

Tareas repetitivas en la creación de un plugin

La creación de cualquier software tiene siempre un deje artesanal. Aunque apliquemos metodologías y seamos lo más rigurosos posibles, escribir software requiere de cierta brillantez y talento; a fin de cuentas, hay que saber expresar en líneas de código los requisitos de nuestros usuarios para conseguir un producto que satisfaga sus necesidades.

Pero que no te engañe la parte «manual» del trabajo; muchas de las tareas que realizas durante la creación y el mantenimiento de una pieza de software son repetitivas y perfectamente automatizables. Veamos algunos ejemplos con los que probablemente ya te hayas encontrado varias veces:

1. Minificar los archivos CSS y JavaScript. Esta es una tarea bastante común hoy en día, especialmente si definimos las diferentes reglas CSS o funciones/objetos JavaScript en varios ficheros y tenemos que concatenarlos y minificarlo todo en un único fichero que acabaremos incluyendo en nuestra instalación.
2. Generar el archivo .pot con las cadenas a traducir. Si quieres crear un plugin que pueda tener un impacto internacional, está claro que debes hacerlo pensando que alguien lo traducirá y adaptará a su idioma local. Para ello, lo más habitual es usar todas las funciones de internacionalización de WordPress y, por lo tanto, acabar generando un fichero .pot para traducir.
3. Lanzar tests unitarios de tu plugin. Como ya hemos discutido en este blog, es muy importante que realices tests unitarios a tu código para verificar su correcto funcionamiento. Aunque existen herramientas muy completas para realizar integración continua y similares, lo mínimo que deberías plantearte es poder lanzar una suite de tests fácilmente y comprobar que todo aparece en verde.
4. Empaquetar y subir nuevas versiones del plugin. Después de haber dedicado unas semanas o meses a implementar nuevas funcionalidades, a corregir posibles errores o a mejorar aspectos de tu plugin, llega el momento de empaquetarlo como una nueva versión y subirlo al repositorio de plugins de WordPress.org para que se lo descarguen tus usuarios.

Como puedes ver, muchas de las tareas habituales en el desarrollo de plugins son bastante sencillas; de hecho, se caracterizan por ser simples y repetitivas y, por lo tanto, son las candidatas perfectas para ser automatizadas. El hecho de haber escogido estos ejemplos y no otros no es baladí: en Nelio tenemos automatizadas todas estas tareas en mayor o menor medida… y hoy compartimos contigo los scripts que hacen la magia en Nelio ?

Automatizando que es gerundio

Existen multitud de herramientas para automatizar tareas. En nuestro caso, solemos usar Gulp y scripts en Bash. De todas formas, no es mi intención defender ninguna herramienta por encima de otra; puedes usar lo que expongo en esta entrada para crear tus propios automatismos con la herramienta o lenguaje que más cómodo te resulte. ¡Vamos allá!

Scripts Gulp a usar para JavaScript y CSS mientras desarrollas

Una de las tareas más habituales que realizamos los desarrolladores web es la minificación de nuestros scripts; esto es, quitar todos los espacios y caracteres innecesarios de nuestro código para ahorrarnos unos pocos bytes. Pues bien, en Gulp esto es extremadamente sencillo:

basta con incluir unos pocos paquetes y conseguiremos ser capaces de coger todos los scripts JavaScript que tenemos en nuestro proyecto (línea 6), minificarlos (línea 7) y guardarlos con el sufijo .min en el directorio que queramos (líneas 8 y 9).

Y lo mismo para concatenar y minificar ficheros CSS, por supuesto:

En este caso, fíjate que usamos dos paquetes para trabajar con CSS: CSS Next y CSS Nano. El primero es una pequeña utilidad que nos permite escribir código CSS «del futuro» (es decir, instrucciones que quizás no están todavía soportadas por los navegadores) y la herramienta lo traduce a CSS actual (es un transpilador, vaya) y CSS Nano es el que se encarga de la minificación del fichero CSS resultante. Pero, vaya, como no quiero agobiarte con estos detalles, pasemos a las automatizaciones interesantes en si…

Una de las cosas que más me fastidia de trabajar con ficheros fuente y sus versiones minificadas es que cada vez que hago un cambio en uno de los ficheros fuente tengo que acordarme de generar su minificación, pues esta última es la que incluyo en mi web y, por lo tanto, la que «testeo» en mi navegador. Por suerte, Gulp incluye una herramienta que detecta cuándo se produce un cambio en alguno de tus ficheros fuente y ejecuta una o más tareas como respuesta. Es decir, que puedo decirle a Gulp: «oye, cuando cambie alguno de estos ficheros JavaScript o CSS, vuelve a generar las versiones minificadas»:

Y, oye, cuando le coges el gustillo a trabajar con Gulp, empiezas a usarlo para un montón de chorraditas, como por ejemplo llamar a los tests unitarios de PHP y JavaScript con un sólo comando:

o para generar el fichero de traducciones .pot:

Mola, ¿eh? Pues aquí te dejo el script completo, por si quieres descargarlo, adaptarlo y usarlo en tus propios desarrollos.

Nelio Content

Estoy tan contento con Nelio Content que parece que me hayan pagado para hablar bién de él… pero es que también a ti te encantará: funciona como prometen, la programación automática de mensajes es increíble, la calidad/precio no tiene parangón y su equipo de soporte se siente como si fueran parte del tuyo.

Panozk

WordPress.org

Ver planes

Script Bash para preparar una nueva versión del plugin

Como bien sabes, cuando subes por primera vez un plugin al directorio de plugins de WordPress y te lo aprueban, te dan acceso a un repositorio SVN desde el que poder seguir desarrollando las siguientes iteraciones del plugin y con el que marcar las diferentes versiones estables que publiques. El problema es que a día de hoy la mayoría de los desarrolladores usan Git para trabajar en sus proyectos, con lo que en un momento u otro tienen que copiar los ficheros que tienen en el proyecto Git al repositorio SVN. Como puedes ver, estamos de nuevo ante una tarea que repetiremos una y otra vez (siempre que queramos publicar una nueva versión), así que ya va siendo hora de crear un script que nos permita hacerlo de forma fácil, rápida y cómoda.

El script que vamos a hacer es muy sencillo: simplemente va a tomar como parámetros el número de versión que queremos crear y la ruta al directorio donde tenemos el proyecto en SVN (suponemos que ejecutamos el script desde el directorio Git donde normalmente trabajamos):

david@xps:~/vagrant/wordpress/wp-content/plugins/nelio-content/ $ 
./mkversion 1.5.0 ~/svn/nelio-content/

Vamos, pues, a ver todos los pasos que suele implicar la publicación de una nueva versión y el fragmento de un script (escrito en bash) que lo completa.

1. Actualizar el fichero README. Cada vez que publicas una nueva versión, deberías actualizar el fichero README en, como mínimo, tres puntos. Primero deberás modificar el número de versión estable de tu plugin (aunque eso lo harás una vez estés seguro que la quieres marcar como tal). En segundo lugar, tendrás que añadir un nuevo apartado en el Changelog para que los usuarios puedan ver qué cambio hay en la nueva versión (esto es algo que deberías haber estado actualizando mientras trabajabas en el plugin). Finalmente, deberás añadir una pequeña línea al final del README con el Upgrade Notice; es decir, un pequeño resumen de las novedades de la nueva versión.

Lo que debemos hacer de forma automática, pues, es comprobar que el fichero README, en su apartado Changelog, incluye el registro de cambios de la versión que estamos a punto de crear. Si está, añadiremos la fecha actual como fecha en la que hemos publicado esa versión y actualizaremos el Upgrade Notice según nos convenga:

Fíjate que hay algunas variables (como, por ejemplo, $version) o algunas funciones (como question o error) que existen porque las hemos definido al principio de nuestro script.

2. Ejecutar algunas tareas básicas. Otra cosa habitual que deberemos hacer al lanzar una nueva versión de nuestro plugin es asegurarnos de que todos los ficheros que se generan automáticamente están correctamente actualizados. Es decir, deberemos minificar los CSS y JavaScript, generar el fichero .pot de traducciones y asegurarnos que el número de versión del plugin (el que aparece en la cabecera del fichero principal, donde ponemos la Version:) están correctamente definidos:

3. Copiar de Git al trunk de SVN. Una vez tenemos el directorio Git en condiciones, es hora de mover el proyecto de Git a SVN. Esto es bastante sencillo, pero debemos recordar que no todo lo que tenemos en Git se tiene que copiar al SVN (por ejemplo, probablemente querremos ignorar el directorio .git o node_modules):

4. Crear una versión en tags a partir de trunk. El siguiente paso ya es específico de SVN: para marcar un estado de trunk como «estable», hay que crear una copia de trunk en el directorio tags con el nombre de la versión que estás creando. Además, puede ser un buen momento (si quieres) para eliminar morralla, como por ejemplo los archivos src a partir de los cuales has generado las versiones minificadas y tal (con lo que dejas que tus usuarios se ahorren unos megas al descargar la nueva versión):

5. Actualizar los índices del SVN. Finalmente, ya sólo te queda actualizar los índices del proyecto en SVN para que éste pueda ver qué ficheros son nuevos, cuáles han cambiado y cuáles has eliminado:

Después de todos estos pasos, ya tienes el proyecto listo para ser «commiteado» y subido a WordPress.org. El script completo lo puedes encontrar aquí.

Ahora te toca a ti…

Espero que la entrada de hoy te haya parecido útil e interesante. Soy plenamente consciente de que cada maestrillo tiene su librillo, y estoy seguro de que también tú tendrás tus propios scripts y consejos para automatizar estas tareas. ¿Por qué no las compartes con nosotros en los comentarios? ¡Me encantaría saber como lo haces tú o qué cosas crees que podemos mejorar en nuestro proceso!

Imagen destacada de Dominik Scythe vía Unsplash.