Una de las cosas que me está tocando hacer en mi nueva empresa es el staging. Buscar formas para que podamos tener un desarrollo continuo de todos nuestros productos y servicios, a la vez que tengamos todo controlado perfectamente.
Uno podría pensar que con github puede ser suficiente para montar un entorno como el descrito. Y lo es. Aunque soy más fan de crear releases y desplegarlas, podemos utilizar los commits como puntos de anclaje y así poder ir hacia adelante y hacia atrás en sus cambios.
Pero claro, a nosotros no nos importa entrar en el servidor y hacernos nuestro git push. Y no todo el mundo es como nosotros.
Además, cuestión comprensible, mi jefe me pide poder hacer él los commits de forma autónoma después de haberlos comprobado en el servidor de desarrollo. Y un método igual de sencillo para poder revertirlo. ¿Qué solución le damos?
Git como herramienta de versionado
Está claro que GitHub (git, en realidad) es la herramienta básica que todos utilizamos para llevar el control de nuestras versiones de código y para poder trabajar de forma colaborativa. Algunos todavía utilizamos en algunos entornos SVN (sobre todo los que hacemos cosas para WordPress, que en este aspecto sigue un poco en el pasado), y otros han pasado de GitHub a GitLab o Bitbucket.
En mi caso, yo me quedo con GitHub para todo lo que sea software libre (todos los repositorios públicos son gratuitos), y con Bitbucket para todo lo que sea privado (hasta 6 usuarios es gratuito). De esta forma, tengo todos los proyectos libres en GitHub, y todo lo relacionado con clientes en mi repositorio de Bitbucket. De esta forma puedo tener una copia completa de su sistema, configuración incluida, y siempre puedo ir hacia adelante y hacia atrás en el sistema.
Copias de seguridad con Bitbucket
Además del trabajo normal y rutinario, donde actualizamos cosas o programamos cosas y las añadimos a nuestro git, una de las cosas que tengo automatizadas para todos los clientes son las copias de seguridad. ¿Cómo las hago?
Aprovechando que Bitbucket no me pone límites a la hora de subir repositorios (aunque me ponga un bonito mensaje grande y amarillo si me paso del giga), lo subo todo ahí.
Cada 6 horas hago que el sistema ejecute un script con cron job.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| sh /home/raven/cronjob.sh > /dev/null 2>&1 | |
| sh /home/raven/mysqljob.sh > /dev/null 2>&1 |
Y hago que se haga una copia de seguridad en Bitbucket… (git add –all borrará también los archivos que se hayan borrado, y esto es importante para después).
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #!/bin/sh | |
| cd ~/domains/bi0xid.es/public_html/web/ | |
| git add –all | |
| git commit -m "copia de seguridad" | |
| git push origin master | |
| cd ~/domains/darkblue.es/public_html/web/ | |
| git add –all | |
| git commit -m "copia de seguridad" | |
| git push origin master | |
| […] | |
… y otra de la base de datos, aunque ésta la guardo en local.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| mysqldump –single-transaction –user=XXXX –password=XXXX –databases XXXX > /home/raven/backup/incremental/XXXX-$(date +%Y%m%d-%H%M).sql | |
| mysqldump –single-transaction –user=XXXX –password=XXXX –databases XXXX > /home/raven/backup/incremental/XXXX-$(date +%Y%m%d-%H%M).sql |
Dando un paso atrás con las bases de datos
Imaginaos que un cliente nos llama porque se ha cargado un artículo que estaba haciendo ayer. No sabe cómo ha pasado, pero el artículo se ha ido a la papelera, y la papelera se ha borrado sola. Sí, pasa mucho. Más de lo que os imagináis. ¿Cómo solucionamos esto?
Pues tiramos de copia de seguridad. Lanzamos este comando y…
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| mysql -u usuario -pcontraseña base_de_datos < archivo_copia_de_seguridad.sql |
¡Restaurado!
Pero atención. Esta copia de la base de datos es una copia completa de la base de datos. Si tenéis algo más que un blog conectado con Jetpack, esto machacará datos de métricas que para vosotros pueden ser muy valiosos. ¿Qué hacemos en ese caso? Pues modificar la copia de seguridad de la base de datos que hacíamos inicialmente, para ajustarla a nuestras necesidades. En el ejemplo tenéis cómo hacer un dump de la base de datos ignorando tablas, o añadiendo sólo las tablas que queramos.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| mysqldump –single-transaction –user=XXXX –password=XXXX –databases XXXX –ignore-table=wp_options > /home/raven/backup/incremental/XXXX-$(date +%Y%m%d-%H%M).sql | |
| mysqldump –single-transaction –user=XXXX –password=XXXX –databases XXXX wp_commentmeta wp_comments wp_postmeta wp_posts wp_term_relationships wp_term_taxonomy wp_terms > /home/raven/backup/incremental/XXXX-$(date +%Y%m%d-%H%M).sql | |
Lo bueno que tiene este sistema es que nos podemos hacer una copia por cada tabla, o agruparlas de la forma que queramos, para que cualquier restauración del sistema sea muy sencilla y rápida de hacer. Si lo tenemos todo correctamente automatizado, podremos incluso hacerlo desde el móvil.
¿Esto sustituye a la copia de seguridad tradicional?
Podría, pero la respuesta es NO. Hago hasta tres copias de seguridad de todo, y en alguna ocasión he tenido que tirar de la tercera. Para no hacer una cuarta, organicé este sistema que me ayuda en el día a día. Pero estamos confiando en un sistema externo, por lo que debe ser una copia más.
Staging con DeployHQ
DeployHQ es un servicio que nos permite conectar un servicio de versionado como GitHub o Bitbucket a una cuenta.
Una vez conectado, nos mostrará el listado de nuestros repositorios, y podremos elegir cualquiera de ellos.
Y una vez elegido, nos conectará con el servicio creando una nueva clave pública en Github de forma automática.
Tras este paso, DeployHQ nos cacheará el repositorio. De esta forma, podemos hacer cualquier despliegue en segundos.
Después añadiremos nuestro servidor (que puede ser una conexión por FTP, si estamos trabajando para un cliente externo).
Y a partir de este momento, ya estaremos preparados para enviar cosas al servidor. Todo lo que esté giteado lo podremos mover hacia adelante y hacia atrás, y el sistema de DeployHQ nos añadirá o borrará la información necesaria correspondiente a nuestro git. Y si ha pasado algo raro, incluso podemos volcar el repositorio completo.
Y la ejecución es tal que así:
Así que tenemos:
- Copias de seguridad que podemos llevar hacia adelante y hacia atrás siempre que necesitemos
- Una forma de poner en producción cambios, y de revertirlos en seguida en caso de que vayan mal
Si estamos desarrollando en local, en un servidor de desarrollo, o en un directorio del mismo servidor, de esta forma podemos montarnos un sistema de control muy cómodo e interesante que nos puede ahorrar muchas horas y quebraderos de cabeza.
DeployHQ es gratis para un proyecto. También para proyectos Open Source si hablas con ellos. Y para repositorios privados, £6 al mes por 10 repositorios. Un precio más que razonable para tener totalmente atados los proyectos en los que estás trabajando.
Ejecutando comandos con DeployHQ
Después de probar distintos softwares para integración continua, me decanté por DeployHQ por estas razones:
- Enlaza a tus cuentas existentes en GitHub, GitLab y Bitbucket. No tienes que contar con sus repositorios para funcionar.
- Su web es totalmente responsive, lo que me permite utilizarla desde el móvil sin sufrimiento.
- Permite conexión con servidores FTP, que es lo más común que vas a tener cuando trabajas con clientes externos que tienen servidores reguleros. La mayoría de otros servicios de integración continua funcionan únicamente a través de git pull/push.
- Si lo conectamos a través de SSH, permite la ejecución de comandos.
Sí. Podemos decirle que ejecute comandos. Antes o después del despliegue, e incluso en qué despliegues queremos que ocurra.
Y podemos crear comandos tan peregrinos como éste:
Básicamente, nos permite jugar con todo lo que queramos. Si le ponemos un servidor dummy, que no haga ningún deploy, también podemos utilizarlo para:
- lanzar copias de seguridad concretas
- copias a FTP
- copias a otro servidor
- sincronización de servidores de desarrollo y producción con rsync o scp
- …
Las posibilidades son muy grandes, y es lo que me gusta de haber montado un sistema así. Sí, £6 al mes. Merecen la pena.
Deja un comentario