Posts en WorkFlow

Cómo manejar WordPress utilizando Git

La semana pasada publicaba un artículo sobre el por qué es una muy mala idea utilizar FTP para manejar nuestro sitio. Aunque el tema es muy general y no aplica únicamente para WordPress, ésta vez quiero explicar un poco más sobre el proceso que uso personalmente para combinar WordPress con Git.

¿Qué es Git?

Si ésta es tu primera pregunta, mi pequeño saltamontes, tienes un gran camino por recorrer. Pero no te preocupes, todos lo tenemos.

Para empezar, Git es un sistema de versión de archivos, algo parecido a SVN, pero generalmente más apreciado. Git permite guardar versiones en el tiempo de cada archivo que modificamos, de ésta forma podemos regresar fácilmente a una versión anterior, o tener un registro de exactamente que ha cambiado, cuando cambió, y quién fue quién lo cambió.

¿Por qué usar Git?

Como mencioné antes, Git guarda versiones de cada archivo de nuestro sitio para que podamos regresar a cualquiera de ellas fácilmente.

¿Alguna vez has hecho una modificación a un archivo, y lo único que lograste fue una pantalla blanca? Con Git, fácilmente podrías regresar a una versión anterior de tu sitio, para poder encontrar el problema sin afectar tus visitas.

Git también es muy útil cuando nos encontramos trabajando en un equipo de gran tamaño, o cuando muchas personas pueden llegar a tocar el código, ya que guarda un historial de quién, y cuándo se ha hecho cada cosa. Y muchas personas pueden trabajar en el mismo sitio al mismo tiempo sin pasar unas encima de otras.

¿Convencido?

¿Cómo utilizar Git en nuestro sitio?

Ya casi llegamos a la parte importante, ahora que sabemos qué es, y para qué lo necesitamos, veamos algunas de las formas más comunes en las que podemos utilizar Git.

Como versión de archivos únicamente

Si únicamente necesitamos tener un historial de los cambios en nuestro sitio, y no necesitamos nada muy complejo, podemos únicamente crear un repositorio, ya sea en Gtihub, Gitlab, o Bitbucket.

Teniendo nuestro repositorio, podemos agregar o modificar cualquier cosa de nuestro sitio en una versión de archivos completamente distinta a lo que tengamos en producción, de esta forma podemos seguir guardándolos en la nube sin peligro de que nuestros archivos en producción sean modificados. También podemos compartir nuestro código con otros miembros de nuestro equipo, quienes podrán seguir haciendo modificaciones en sus propias versiones.

Como herramienta para deployment

Una de las mayores ventajas que le veo al uso de Git + WordPress es, además del versionamiento de archivos. La posibilidad de mover nuestro flujo de deployment a Git (para finalmente olvidarnos de FTP). Éstos métodos son un poco más avanzados, pero sin duda, hacen nuestra existencia mucho más fácil una vez que han sido dominados.

La idea principal es, tener una copia del repositorio en tu máquina de desarrollo, y tener una copia del repositorio en el servidor. Lo recomendado es, tener en el repositorio únicamente cosas de las cuales no nos preocupemos por qué alguna actualización vaya a sobreescribir. Como por ejemplo:

Por lo tanto, la mayoría de las veces, el repositorio estará conformado por nuestra carpeta de wp-content. En el caso de que tengamos más plugins, hechos por otras personas o que están disponibles en el repositorio oficial de WordPress, lo recomendable es ignorarlos en el repositorio, y manejarlos utilizando Composer (de lo que hablaré en un artículo en el futuro).

Digamos que ya hemos creado nuestro repositorio en Github, y que hemos agregado el contenido de nuestra carpeta wp-content a él, entonces tendríamos un repositorio más o menos así:

git@github.com:usuario/sitio.git

Una vez teniendo nuestro repositorio, ya podemos preocuparnos por sincronizarlo con nuestro servidor.

Deployment a través de SSH

Como mencionaba en mi artículo pasado, SSH es mucho más seguro que FTP, y si necesitamos ingresar a nuestro servidor a mover archivos o hacer configuraciones, es también mucho más recomendado.

Para empezar, necesitamos conectarnos a nuestro servidor a traves de SSH (puede variar dependiendo de tu empresa de hosting, asegúrate de tener acceso).

Nota: Éste proceso puede variar mucho dependiendo de qué persona lo use, algunas urls y procedimientos dependen mucho de cuestiones personales, toma la idea básica y ajusta a tus gustos.

Digamos que nuestro repositorio está conformado por la carpeta wp-content, y que éste se ve así:

Para poder reemplazar nuestra carpeta por defecto con nuestro nuevo repositorio, necesitamos entrar al servidor y crear una copia del repositorio:

!Y eso es todo! Ahora tenemos en sincronía nuestro repositorio local, con nuestro repositorio en el servidor, y podemos compartir archivos entre ambos de una manera muy fácil.

Yo recomiendo, tener al menos tres branches en el repositorio:

El procedimiento de desarrollo es bastante sencillo una vez que se domina, digamos que hemos creado un feature/slideshow y que estamos listo para probarlo en staging, entonces haríamos algo como esto:

Ahora ya tenemos nuestra nueva funcionalidad en el repositorio, pero aún necesitamos algún lugar para probarla ¿cierto?

Para esto yo recomiendo tener un nuevo ambiente de pruebas en el servidor (algo cómo staging.sitio.com). Con una completamente distinta instalación de WordPress, su propia base de datos, etc. En la cual repetiremos los mismos pasos que hicimos anteriormente para crear una copia del repositorio en el servidor, con dos diferencias:

  1. Crearemos la copia del repositorio dentro de la carpeta de nuestro sitio de pruebas (ejemplo: /staging.sitio.com/public_html en lugar de /public_html)
  2. La base de éste repositorio será un branch llamado staging en lugar de master, así nos aseguramos de probar las cosas en el lugar correcto.

Para hacer nuestro deploy y probar en staging, nos movemos a la carpeta donde tenemos la copia del repositorio (wp-content), y hacemos lo siguiente:

Y eso es todo, ahora si entramos a staging.sitio.com veremos la versión más reciente de nuestro branch staging, que ahora ya tiene los cambios hechos en feature/slideshow. Así, una vez que ya hemos probado el sitio de pruebas (aún no hemos tocado producción) y estamos seguros de que funcionará correctamente en producción, podemos unir nuestros nuevos cambios:

Ahora que tenemos la versión más reciente en el repositorio de Github, nos hemos asegurado de que todo funciona como queremos, y estamos listos para el deploy a producción. Podemos entrar a nuestro servidor y bajar los cambios más recientes a producción:

¡Y listo! Ya tenemos la versión más reciente de nuestro sitio en producción, ahora podemos hacer una última prueba sólo para confirmar y nuestro deployment está completo.

¿Qué pasa si algo salió mal?

En el dudoso caso de que no probaramos como deberíamos la nueva funcionalidad y por alguna razón nuestro sitio en producción se vino abajo, no hay razón para alarmarse, la prioridad ahora es regresar producción a una versión anterior que si funcionaba, que en éste caso, sería justo antes de unir el carrusel a producción, es decir, justo una versión antes, entramos a la terminal y hacemos algo como esto:

Ésto nos regresará exactamente una versión atrás, que en este caso, justo antes de nuestro carrusel, levantando nuestro sitio en producción y dándonos tiempo de buscar y solucionar el error localmente sin que producción se vuelva a ver afectado.

Siguientes pasos

Éste resultó un articulo más grande de lo que esperaba, pero éste no es el flujo ideal que inspiró éste articulo, en el siguiente, explicaré como poder automatizar el proceso en staging para reducir la cantidad de veces que entramos al servidor, y explicaré qué herramientas pueden hacer este proceso aún más sencillo.