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:

• Nuestros themes personalizados
• Nuestros plugins personalizados

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í:

1git@github.com:usuario/sitio.git
2

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).

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

1- sitio
2--	.gitignore
3--	themes
4---		nuestro-theme
5----		style.css
6--	plugins
7---		nuestro-plugin
8----		nuestro-plugin.php
9

View Gist on GitHub

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

1# Asumiendo que nuestra carpeta wp-content se encuentra en /public_html/wp-content
2
3$ ssh usuario@dominio.com
4$ cd /public_html
5$ mv wp-content wp-content.bk # Crea un backup de la actual carpeta wp-content en caso de necesitarla en un futuro
6$ git clone git@github.com:usuario/sitio.git wp-content # Crea una copia del repositorio en un forder llamado wp-content
7

View Gist on GitHub

!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:

• master, que usaremos como producción, todo lo que está aquí es la versión final del sitio y debe estar 100% probada antes de llegar. También sirve como la base de nuestras ramas “feature”
• staging, que será la versión de pruebas de nuestro sitio, una versión “beta” por así decirlo, una vez demostrado que la nueva funcionalidad funciona aquí, podemos enviarla a master
• feature/* Nuestras ramas “feature” son trabajo en desarrollo, no están listas para ver producción y sólo deben ser unidas a master una vez que se ha comprobado al 100% que funciona en staging. Una vez que han sido unidas a master, serán eliminadas del 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:

1# Asumiendo que el trabajo ha sido completado
2
3$ git checkout master
4$ git pull origin master # Asegurarnos de que tenemos la versión más reciente
5$ git checkout -b feature/slideshow # Movernos a un nuevo branch para no modificar producción
6
7# Comienzo y fin del trabajo
8
9$ git add -A
10$ git commit -m "Implementando carrusel de imágenes" # Guardar una versión de estos archivos con las nuevas modificaciones
11$ git push origin feature/slideshow # Enviar ésta nueva versión al repositorio remoto (en Github)
12$ git checkout staging # Nos movemos a la versión de staging
13$ git pull origin staging # Asegurarnos de tener la versión reciente
14$ git merge --no-ff feature/slideshow # Unimos nuestra versión con el carrusel a staging para poder probarla
15$ git push origin staging # Enviar la nueva versión de staging al repositorio remoto (en Github)
16

View Gist on GitHub

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:

1$ ssh usuario@dominio.com // Entrar al servidor
2# cd /staging.sitio.com/public_html/wp-content // Asegurarnos de estar en el sitio de pruebas
3# git checkout staging // Asegurarnos de estar en el branch de pruebas
4# git merge --no-ff feature/slideshow // Unir nuestro nuevo trabajo a nuestra rama de staging
5

View Gist on GitHub

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:

1$ git checkout master # Asegurarnos de tener la versión más reciente de master
2$ git merge --no-ff feature/slideshow # Unir nuestra nueva funcionalidad a master
3$ git pxush origin master # Enviar la versión más reciente al repositorio (en Github)
4

View Gist on GitHub

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:

1$ ssh usuario@sitio.com
2$ cd /public_html # Asegurarnos de estar en producción
3$ git checkout master
4$ git pull origin master # Descargar los cambios más recientes del repositiorio (en Github)
5

View Gist on GitHub

¡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:

1$ ssh usuario@sitio.com
2$ cd /public_html # Asegurarnos de estar en producción
3$ git checkout master
4$ git revert HEAD # Revierte el último commit, regresa a una versión anterior
5

View Gist on GitHub

É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.