Me gustaría hablar del trabajo con WordPress en cuanto al despliegue se refiere. Quiero evitar perder el tiempo trabajando horas o días, para luego darnos cuenta de que cuando lo subimos lo único que vemos es la pantalla en blanco… Se podría haber evitado?
Esto es aplicable a cualquier plataforma, ya que al final todo se basa en tener un entorno local idéntico a producción y un entorno de desarrollo en el mismo servidor que tenemos producción donde testear lo más real posible. Pero hago hincapié en algunas herramientas que WordPress nos da para hacer esto casi de forma automática.
NOTA: este post no pretende ser un tutorial paso a paso. Pretendo hablar sobre lo que voy trabajando, y en este caso ha tocado una estrategia de trabajo con WordPress. Por lo que quiero que quede claro los pasos a nivel general, las herramientas que uso, los motivos, los pros y los contras.
Explicaciones previas:
¿Motivos para indagar en el despliegue de aplicaciones con WordPress? ¿Merece la pena?
Dos casos que nos habrá pasado a todos, y si no es así, tiempo al tiempo 😉
Despotriquemos un poquito.
Estoy cansado de trabajar en local y que al subirlo al servidor falle… sobre todo cuando el cliente tiene un servidor propio al que no me da acceso hasta haberle terminado la web entera. Sorpresa al entrar a su servidor y ver que su plan de hosting no sporta actualizaciones de mysql sin desmontar el servidor entero, y que la versión de php que tiene está anticuada. Quiero importar la base de datos de mi trabajo local, pero los tipos son incompatibles y empiezan los problemas. Está claro que puede contratar un nuevo hosting, cambiar las DNS del dominio, etc… Pero a veces esto no es posible: qué pasa entonces con el correo? Empiezas haciendo un WordPress sencillo y acabas configurando un servidor, migrando correos, cambiando contraseñas…
Otro caso es el de un compañero de trabajo que desarrolla en su ordenador Mac (yo uso Linux, Ubuntu concretamente). Mi compañero es diseñador pero hizo un curso de WordPress hace años. Tiene MAMP instalado y ha hecho un WordPress en local, me lo pasa para que lo suba, pero no sabe qué configuración local tiene. De nuevo los problemas. Versión de su MySQL? Versión de su PHP? Ya ni hablar de módulos de Apache activos, o módulos de PHP… Evidentemente ni puedo migrarlo a mi servidor local por incompatibilidades por todos lados.
¿Merece la pena? Claro que merece la pena. En ambos casos, tener un servidor local con idénticas características que el servidor al que se va a desplegar la aplicación (el WordPress en este caso) evita grandes ingestas de café para aguantar las horas de solucionar problemas imprevistos respecto al servidor y llegar al plazo a la vez que vas metiendo los cambios finales… un despropósito.
Estrategia de despliegue para evitar problemas
Necesitamos tener 2 servidores: el local (nuestro ordenador) y el remoto (donde subiremos el código finalmente). Pero necesitamos además que el servidor local sea lo más calcado posible al remoto para evitar incompatibilidades. Más adelante detallo algunas cosas a tener en cuenta.
Además necesitamos 3 entornos de trabajo como mínimo (asemejemos “entorno” a una instalación de la aplicación a la que podemos acceder desde una url concreta, luego explicamos cómo conseguirlo). Dividiremos estos entornos entre los 2 servidores.
El servidor local, tendrá un único entorno, por ejemplo “midomonio.dev” que cargará ficheros y bases de datos de nuestro ordenador. Es el entorno de desarrollo, donde trabajaremos y haremos todos los cambios.
El servidor remoto tendrá 2 entornos, el de pruebas y el de producción.
En el de producción, accediendo desde midominio.com, pondremos el código que estamos 100% seguros que funciona y no da problemas, validado por el cliente y será el sitio web visible para el público, la web real vamos.
En el de desarrollo (o también llamado de calidad), al que accederemos desde por ejemplo un subdominio del dominio final (pruebas.midominio.com podría ser una opción), subiremos los cambios hechos en el entorno de desarrollo de nuestro ordenador únicamente para ver qué no da problemas. Una vez validado y visto que no da problemas, podemos subir del entorno de desarrollo al entorno de producción sin miedo que vaya a dar problemas.
Por supuesto, esto lo complementamos con Git para mantener un seguimiento y no perder cambios. ¿Conoces GitFlow? Te hará la vida más fácil sin dudas.
Resumen:
- midominio.com: servidor remoto, entorno de producción, web real
- pruebas.midominio.com: servidor remoto, entorno de pruebas, comprobar que todo funciona bien
- midominio.dev: servidor local, entorno de desarrollo, sitio de trabajo y de hacer cambios, respaldado en Git
¿Por qué hacemos estos pasos?
Siempre que subamos el código de local a remoto, hay una pequeña posiblidad de que algo falle al tratarse de máquinas diferentes. Incluso de un servidor a otro hay diferencias de configuración, memoria, capacidades, etc…
Entonces queremos un sitio, un hueco en el servidor final donde poder probar el código que en local nos funciona bien, donde poder probar la aplicación entera en su entorno final. Es decir, si vemos que al subirlo al servidor final (en el entorno de pruebas) no da problemas, casi seguro no dará problemas en el entorno de producción porque se trata del mismo servidor.
Herramientas a utilizar
Docker (o Vagrant), Git, WP-CLI, WordMove. Este cuarteto de herramientas evitará que nos estiremos de los pelos cada vez que haya un problema, y nos evitará llegar a ciertos problemas. Al final se trata de tener un entorno local que podamos configurar a nuestro gusto y que tengamos acceso por línea de comandos.
Docker: utilizo Devilbox (http://devilbox.org/). Es un completísimo entorno de trabajo local basado en Docker que nos permite configurar versiones de todo lo que necesitemos, mediante la simple edición de un archivo de configuración.
Vagrant (https://vagrantup.com): podríamos decir que es un gestor de máquinas virtuales. Nos generará una máquina virtual que actuará de servidor local. Personalmente utilizo PuPHPet (http://puphpet.com) que con una interfaz gráfica nos ayuda a configurar la máquina en Vagrant. Con PuPHPet podemos casi copiar la configuración del servidor final para tener en local algo idéntico o muy parecido. Ahora mismo prefiero trabajar con Devilbox.
Git (https://git-scm.com): sistema de control de versiones. Iremos registrando un histórico de los cambios hechos en nuestro WordPress que básicamente estará dentro de la carpeta “wp-content”, ya que el resto no deberíamos tocarlo al ser código core. Personalmente utilizo BitBucket por los repositorios privados cuando no quiero exponer públicament el código, y si quiero exponerlo pues GitHub.
WP-CLI (https://wp-cli.org/): programa de líneas de comando para ejecutar funciones de WordPress. Más que nada para ahorrar tiempo. Se tarda menos en copiar y pegar 10 comandos y tener una instalación con todos los plugins que solemos usar ya activados, los usuarios que necesitamos y los temas que necesitamos, que en hacer la instalación tipica e ir siguiendo paso a paso para instalar temas, plugins y crear usuarios.
WordMove (https://github.com/welaika/wordmove): una joya. Gestiona las migraciones de WordPress sin que nos enteremos. Le configuramos los entornos que necesitamos (los 3 que hemos dicho antes) y elegimos adónde desplegar y qué partes de nuestra instalación de WordPress desplegar.
Pasos en general
Omito los pasos de Devilbox, git, vagrant, virtualbox, instalaciones que ya me da PuPHPet (como node, npm, sass, PHP-CLI, etc). Dejo las que muestren la simpleza del trabajo diario con estas herramientas ya instaladas.
1) Preparo dominios, bases de datos remotas y datos de acceso:
Abro el dominio principal (url para el entorno de producción), creo un subdominio (url para el entorno de pruebas), creo una base de datos para cada dominio y tomo nota de los datos de acceso para ambas bases de datos.
Apunto también los datos de acceso por SSH y FTP al servidor.
2) Investigar el servidor remoto
Hay que averiguar: sistema operativo y versión del mismo, servidor web usado (Apache o Nginx), versiones de PHP y MySQL, módulos del servidor web activos, módulos de PHP activos, configuración de límites del servidor (subida de archivos, memoria, etc…)
Esto nos dará los datos para copiar la configuración para el servidor local.
3) Crear servidor local y base de datos local
En Devilbox, configuro todo lo necesario en el fichero .env. O en PuPHPet introduzco los datos sacados de la investigación anterior y hago una instalación de Vagrant siguiendo esa configuración. Suelo crear un dominio local “.dev” o “.loc” del mismo dominio de producción mediante hosts.
Arrancamos Devilbox o Vagrant poner en marcha el entorno local.
Añado la IP del servidor local al dominio que quiero usar en el fichero hosts de mi sistema operativo.
Creo la base de datos en local y me aseguro que tenga la misma colación y conjunto de caracteres que la remota (utf8 y utf8_general_ci), sino es así lo corrijo.
4) Instalar herramientas en local e inicializar repositorio en Git
Aquí instalaría WP-CLI. Instalo WordMove y configuro el fichero Movefile con los datos de los entornos.
Instalación de Wordmove: gem install wordmove e inicializar el el fichero de configuración wordmove init. Configuro datos de acceso al entorno local, pruebas y remoto (SHH y bases de datos)
Inicializo el repositorio en Git y creo un repositorio remoto en Bitbucket para configurar esa url como push/pull en mi git.
Añadir el .gitignore correcto desde gitignore.io y commit inicial.
5) Instalación WordPress en local
Mediante WP-CLI instalo WordPress con el tema a usar, los plugins a usar y los usuarios necesarios. Commit.
wp core download --locale=es_ES && wp core config --dbname=dbname --dbuser=dbuser --dbpass=123 --dbcharset=utf8 --dbcollate=utf8_general_ci && wp core install --url=http://midominio.dev --title=title --admin_user=wordpress --admin_password=123 --admin_email=email@email.com && wp plugin install PLUGINNAME1 --activate && wp plugin install PLUGINNAME2 --activate
6) Prueba del entorno de pruebas
Mediante WordMove, pruebo de hacer un despliegue de la instalación limpia de WordPress y que se vea todo correctamente sin fallo alguno. Después del despliegue hay que crear manualmente un wp-config.php en el servidor porque por seguridad no se sube con Wordmove.
wordmove push -w -e=pruebas && wordmove push --all
7) Fase de trabajo en local
Modificaciones necesarias y todo el grueso del trabajo con sus respectivos commits y copias de la base de datos necesarias.
8) Despliegue a pruebas y validación
Mediante WordMove migro a remoto en el entorno de pruebas y compruebo que todo funciona como debería. Que no, cambios en el entorno de desarrollo para corregir y repetir el paso.
9) Despliegue a producción y finalización
Mediante WordMove migro a remoto en el entorno de producción y vuelvo a comprobar que todo funciona como debería.
wordmove push -w -e=produccion && wordmove push --all
Parece mucha cosa, pero facilita el trabajo con WordPress un montón. Sobre todo el mantenimiento donde hay que hacer cambios y a estar trabajando en remoto con el ftp enlentece el proceso.
Notas finales
Sí ya lo sé. ¿Tanta movida para un WordPress? Pues sí. Quizás inviertas 2 horas más al inicio de un proyecto pero te ahorras problemas al querer finalizarlo de unas 10-15 horas… Además, si no somos capaces de garantizar esto con un WordPress, cómo vamos a ser capaces de hacerlo con un proyecto más grande y complejo como un Magento o algo con código personalizado?