Categorías
Mundo 2.0 programación Tutoriales

Entorno de desarrollo continuo con github y deployHQ

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.

sh /home/raven/cronjob.sh > /dev/null 2>&1
sh /home/raven/mysqljob.sh > /dev/null 2>&1

view raw
cron execution
hosted with ❤ by GitHub

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

#!/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
[…]

view raw
git push sec-copy
hosted with ❤ by GitHub

… y otra de la base de datos, aunque √©sta la guardo en local.

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

view raw
mysql sec-copy
hosted with ❤ by GitHub

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…

mysql -u usuario -pcontrase√Īa base_de_datos < archivo_copia_de_seguridad.sql

view raw
mysql import
hosted with ❤ by GitHub

¬°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.

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.

dep1

Una vez conectado, nos mostrar√° el listado de nuestros repositorios, y podremos elegir cualquiera de ellos.

dep2Y una vez elegido, nos conectar√° con el servicio creando una nueva clave p√ļblica en Github de forma autom√°tica.

dep3

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

ftp

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.

repository

Y la ejecución es tal que así:

deployment

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.

before

Y podemos crear comandos tan peregrinos como éste:

after

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.

Categorías
Mundo 2.0

Git f√°cil en OSX Mavericks

Soy usuario de Git. Lo uso a diario en repositorio local, y sincronizo casi cualquier cosa que hago con GitHub y BitBucket (aunque casi todo con repositorios privados).

bitbucket

Normalmente uso¬†git por l√≠nea de comandos acompa√Īado por Transmit y Sublime Text (otro d√≠a os cuento un poco m√°s acerca del m√©todo de trabajo), y desde que instal√© Mavericks me he encontrado con un problema¬†un poco inc√≥modo: git ahora necesita permisos de administraci√≥n.

Al principio pens√© que ser√≠a sencillo. Cambiar los alias que utilizo en consola a√Īadi√©ndoles un¬†sudo delante, y listo. Ya se ejecuta como administrador.

alias st='sudo git status'
alias ga='sudo git add .'
alias gc='sudo git commit -a -m'
alias gd='sudo git diff'
alias gl='sudo git log'
alias gogit='cd ~/Git'
alias gp='sudo git push origin master'

Pero no fue tan sencillo. Una vez a√Īadido los sudos, el sistema me ped√≠a la clave. Pero no s√≥lo una vez, que era lo que esperaba, sino cada 15 minutos. Algo bastante inc√≥modo, sobre todo si est√°s todo el d√≠a sincronizando.
Buscando soluciones he topado con este artículo de MacWorld que explica, de forma muy sencilla, cómo hacer que no te pida la clave cada vez que tengas que ejecutar algo como root o con permisos de administración.

En mi caso, siguiendo los pasos del art√≠culo, la cadena que he tenido que a√Īadir ha sido la siguiente:

raven   ALL=(ALL) NOPASSWD: ALL

Si habéis tenido el mismo problema, espero que esto os haga la vida un poco más fácil.