Nota: este artículo se publicó originalmente en inglés acá.

Si desarrollás sitios web con WordPress de manera profesional (básicamente, si vivís de eso o si una parte significativa de lo que ganás viene de ahí), y si todavía no implementaste un sistema de deployment automatizado, deberías considerar fuertemente hacerlo. Siendo sincero, no es lo más fácil del mundo. De hecho, muy probablemente te lleve unas cuantas horas de trabajo, de pruebas infructuosas y de lidiar con la comunicación entre servidores. Lo bueno es que podés aprovechar unos cuantos recursos variados en la experiencia de mucha gente que se quemó las pestañas poniendo en práctica un sistema de deployment antes que vos. Incluso existen herramientas especialmente pensadas para WordPress que te pueden resultar recontra útiles.

¿Por qué es necesario un sistema automatizado de deployment?

Si usás un cliente FTP para subir los cambios a tu sitio, en algún punto debés haber tenido el típico problema de algún archivo que no se sube en su totalidad, o el de que la subida se corta, o el del límite de archivos que se pueden subir simultáneamente. Es muy usual, además, que si tenés algún problema con la subida por FTP, tengas empezar todo el proceso de nuevo, y que en el medio de la actualización de archivos algo quede roto y deje tu sitio inaccesible. Si usás algún sistema de control de versiones, como Git o Mercurial, siendo que no son herramientas pensadas para deployar un sitio, seguramente te enerve bastante la cantidad de comandos que tenés que correr a la hora de hacer un deploy, y el aber especial cuidado que hay que tener para no pisar una versión con otra. En cualquiera de los dos casos, las desventajas son bastante evidentes.

Ahora imaginate un sistema que, con un único comando de consola, te permita poner tu sitio online en cuestión de minutos (o incluso segundos) y de manera transparente, es decir que quien entra al sitio durante el proceso no ve ningún cambio hasta que el proceso haya terminado. Imaginate también que con otro comando, si notaste que algo quedó mal después del deploy, podés volver a la misma exacta versión anterior, sin tener que tocar ningún archivo.

También puede haber comandos para manejar bases de datos, como procesar backups, restauraciones, descargas y subidas.

Interesante, ¿no? Básicamente, este es el tipo de procesos que permite un sistema de deployment automatizado. Imaginate cuánto tiempo y trabajo podés llegar a ahorrarte.

Deployment automatizado con Capistrano

Capistrano es un framework basado en Ruby que permite ejecutar procesos entre servidores de manera automática por medio de SSH. Hoy en día es la herramienta más utilizada por los desarrolladores de WordPress que optan por sistemas de deployment automatizados. Hay otras opciones muy buenas, algunas de ellas pagas, pero mi recomendación es usar esta, ya que es la más documentada tanto de manera oficial como por la gran cantidad de desarrolladores de primera línea que la usan.

Para poder instalar Capistrano, necesitás tener instalado previamente Ruby Gems en los equipos desde los cuales lo vayas a usar. Mi recomendación es que lo uses sólo en sistemas con Linux (cualquier versión más o menos reciente de Ubuntu o CentOS debería bastarte), o a lo sumo en un OSX. En Windows también debería funcionar bien, pero los sistemas basados en Unix son el estándar sobre el que trabaja la mayoría de los desarrolladores profesionales, y casi toda la documentación no oficial está basada en ellos. Si ya tenés Windows y cambiar de sistema operativo es un problema, hay alternativas de virtualización muy sencillas de instalar y usar, de entre las cuales yo prefiero Vagrant. Es muy recomendable también, si mantenés un control de versiones de tu sitio (y si no lo hacés, deberías), tener instalado el programa que uses (Git, Mercurial, SVN, etc.) en todos los equipos involucrados en el proceso (tu máquina local y tus servidores de testing y producción).

Es importante notar que Capistrano asume que trabajás de una manera determinada, es decir que previamente ya adoptaste ciertas técnicas que sus desarrolladores consideran buenas prácticas, como acceder remotamente a todos los equipos por medio de SSH, y que para llevar a cabo este acceso usás llaves públicas que ya están cargadas en los mencionados servidores.

Por sí mismo, Capistrano no funciona out of the box para hacer un deploy, sino que requiere que creemos y modifiquemos una serie de archivos en pos de lograr que nuestro sitio se suba automáticamente a un servidor. No es estrictamente necesario saber algo de programación en Ruby, pero si se sabe algo, va a aportar muchísimo. No voy a entrar en detalles sobre qué es lo que hay que modificar, porque ya hay muchísima información al respecto. Recomiendo, por sobre todo lo que leí del tema, la serie de tutoriales hechos por Konstantin Kovshenin sobre uso de Capistrano (ver parte 1, parte 2 y parte 3). Son muy ilustrativos y sencillos, incluso para quien no tenga ninguna idea de Ruby (como es mi caso), y si se los sigue de principio a fin, el resultado obtenido es un sistema de deployment automatizado completamente funcional. Konstantin es hoy en día uno de los bloggers y desarrolladores más respetados dentro de la comunidad de WordPress, así que su palabra ya es algo así como una garantía de calidad. Lo malo sobre esto es que, lamentablemente no hay mucha documentación en español al respecto, y hay que esforzarse en leer un poco en inglés.

Sin embargo, si uno prefiere no hacer todo el trabajo desde cero, existen varias herramientas que, básicamente, consisten en librerías de preconfiguraciones orientadas al deployment de sitios basados en WordPress.

Deployment en WordPress: WP-Stack y Stage WP

Una de las librerías más populares basadas en Capistrano y orientadas puntualmente a deployment de sitios web hechos con WordPress es WP-Stack, obra de Mark Jaquith, uno de los lead developers del core de WordPress. Mark es uno de los desarrolladores más importantes del ambiente hoy en día, y al igual que el de Konstantin Kovshenin, su trabajo también habla por sí solo. WP-Stack utiliza Capistrano para realizar deploys a ambientes de producción y/o testing, y funciona perfectamente haciendo una mínima personalización de archivos que no requiere ningún conocimiento específico de Ruby. También provee una serie de MU plugins capaces de mejorar tu trabajo y el rendimiento de tu sitio significativamente.

De todas maneras, hay tres limitaciones en WP-Stack que creo que vas a necesitar tener en cuenta:

1. No está pensado para hacer deploys desde tu equipo local. Es necesario que instales WP-Stack en tu servidor de producción y ejecutes tus deployments desde ahí. No debería ser un gran problema, pero yo (y creo que bastante gente) prefiero hacer mi deploy desde el mismo sistema en el que estoy trabajando.
2. No provee un método sencillo para sincronizar bases de datos y archivos estáticos entre diferentes equipos. Es posible traer archivos y base de datos desde producción hacia staging, pero no desde staging o producción al equipo local.
3. Tiene poca documentación, especialmente sobre su configuración. No es exactamente algo de lo que debamos quejarnos, ya que Mark desarrolló WP-Stack para sus propias necesidades. Algunos desarrolladores que trabajan en su propio fork de Github hicieron intentos mejorar la documentación, así que si te sentís un poco confundido por la de Mark, quizás prefieras pegarle una mirada a alguno de esos forks.

Si tenés algún conocimiento previo de Ruby y necesitás más funcionalidades, podés empezar a aprender cómo funciona Capistrano y escribir tus propias tareas. Yo mismo hice eso en un fork, trabajando en mi propio sistema, llamado Stage WP, el cual trato de mantener con frecuencia, y que ofrece documentación un poco más detallada.

Stage WP está pensado para trabajar localmente, y se le puede añadir cualquier stage adicional que haga falta (no sé por qué alguien necesitaría hacer eso, pero la decisión es del usuario). Además, agregué algunas tareas que mejoran el manejo de base de datos y archivos estáticos, y que facilitan la sincronización entre diferentes servidores, así que quizás quieras darle una oportunidad.

Tanto WP-Stack como Stage WP pueden ser utilizados con cualquier tipo de instalación de WordPress, aunque su rendimiento mejora notablemente si se los usa en conjunto con una instalación de WordPress basada en un repositorio de Git, como es el caso de WordPress Skeleton para WP-Stack y WordPress Bareboner para Stage WP. Estos proyectos proveen una manera alternativa de instalar WordPress bien organizada, de la cual voy a hablar más adelante.

Claro que hay muchas otras librerías basadas en Capistrano para deployment de WordPress, tal como Bedrock, la cual parece ser una muy buena solución, pero por el momento creo que solamente puedo hablar de las herramientas que con las que trabajé.

Algunas consideraciones finales

Como decía al principio, lo más probable es que aplicar un sistema como Capistrano + WP-Stack/Stage WP no te resulte sencillo. Las distintas pruebas y configuraciones que necesites hacer van depender de las características y necesidades de tus servidores y de tus sitios, y cabe la posibilidad de que dos sitios distintos necesiten configuraciones diferentes.

Probablemente tengas que implementar virtual hosts, si usás Apache, o server block, si usás NGINX, y cambiar la carpeta a la que va a apuntar el directorio raíz de tu sitio (olvidate de poner todo en public_html, como se estila tradicionalmente). ¿Algo así te daría mucho trabajo?

Es posible que tengas que modificar varias cosas de tu flujo de trabajo normal, lo cual te puede llevar bastante tiempo de adaptación. En este punto vas a tener que evaluar si la cantidad de tiempo y trabajo que vayas a destinarle a la implementación del sistema compensa lo que te vas a ahorrar más adelante, es decir cuánto tengas que trabajar en el futuro en el sitio, la frecuencia de actualización y mantenimiento que se supone que va a tener, y qué tan dispuesto estés a hacer cambios en tu forma de trabajar.

Si es algo en lo que vas a estar trabajando constantemente, sin duda el cambio va a ser una gran ventaja. Por otra parte, si no va a requerir actualizaciones de manera muy frecuente, no vas a ahorrar la gran cosa en tiempo y cantidad de trabajo, pero sí en seguridad (con muchas menos chances de que tu sitio se rompa mientras lo estás actualizando) y en estabilidad (teniendo procesos automatizados y estandarizados para controlar tus modificaciones).

Creo que a veces la cantidad de horas que uno puede ahorrar son algo menor en comparación con la paz mental y el sentimiento de alivio otorgados por algo en lo que podés confiar para que haga un montón de cosas por vos, por lo cual recomiento enfáticamente hacer este cambio. Creo que más importante que ahorrar horas o trabajar más rápido es trabajar mejor, de manera más cómoda y mejor organizada.