Supongamos que hemos montado un repositorio git en nuestro servidor Web para llevar el control de cambios del desarrollo de los diferentes sitios Web hospedados. Los desarrolladores hacen su trabajo y envían cambios a las diferentes ramas del repositorio periódicamente. Ahora bien, cuando los cambios alcanzan un punto estable, es deseable pasarlos al sitio Web (lo que se conoce comúnmente como deploy) para que sean visibles a los usuarios.
Para ello se requiere ejecutar un checkout, actualizar los archivos en el directorio de trabajo. En este punto surgen dos alternativas: darle acceso y permiso a los desarrolladores para que puedan correr el checkout o intervenir el SysAdmin (correr el checkout manualmente y configurar los permisos según corresponda).
Sin embargo, en ciertos entornos (especialmente en entornos de desarrollo/testing) es deseable que el checkout se realice de forma automática y sin intervención manual (tanto de los desarrolladores como del SysAdmin/DevOps). Por ello, en este artículo voy a explicar cómo pasar automáticamente los cambios al sitio cada vez que un desarrollador actualiza (push) una rama específica del repositorio. Una especie de mecanismo de auto-deploy para que el SysAdmin no deba intervenir manualmente en el proceso.
El primer paso consiste en crear un repositorio git bare, tal como lo explica el artículo Cómo montar un servidor git:
# mkdir -p /var/repo && cd /var/repo # mkdir repositorio1.git && cd repositorio1.git/ # git init --bare
Git posee un mecanismo que permite ejecutar scripts personalizados cuando ciertos eventos importantes ocurren. Estos se llaman hooks, y existen dos grupos: del lado cliente y del lado servidor. En este caso deseamos definir un hook del lado servidor que corra el checkout o deploy al sitio Web, cada vez que un desarrollador realiza un push sobre la rama "testing".
Los hooks se almacenan en el subdirectorio hooks/ del repositorio git. Para realizar una acción cada vez que un usuario realiza un push sobre el repositorio, se debe utilizar el hook "post-receive". Los hooks son simples scripts, y pueden utilizar cualquier shell disponible en el sistema, como dash o bash.
Cambiar al directorio hooks/ y crear el archivo post-receive:
# cd hooks/ # nano post-receive
El script tiene debe tener el siguiente contenido:
#!/bin/sh
GIT_DIR="/var/repo/repositorio1.git"
WORK_TREE="/var/www/demo/aplicacion1"
TARGET_BRANCH="testing"
while read OLDREV NEWREV REFNAME
do
BRANCH=$(git rev-parse --symbolic --abbrev-ref $REFNAME)
if [ -n "$BRANCH" ] && [ "$TARGET_BRANCH" == "$BRANCH" ]; then
git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f
fi
done
Configurar adecuadamente las variables GIT_DIR (directorio del repositorio), WORK_TREE (directorio del sitio Web) y TARGET_BRANCH (rama que dispara la actualización del sitio Web).
Este script correrá automáticamente cada vez que se haga un push sobre el repositorio, por ende es necesario determinar sobre qué rama se hace. No es deseable correr el checkout (deploy al sitio Web) cada vez que se haga un push sobre cualquier rama, sino sobre una rama específica. La rama sobre la cual se hace push que dispara el deploy al sitio Web se indica en la variable $TARGET_BRANCH.
Con este esquema, se hace el deploy automático al sitio Web cada vez que un desarrollador hace push sobre la rama llamada "testing".
Para continuar, dar permiso de ejecución al script:
# chmod +x post-receive
Siendo un entorno de desarrollo/testing se puede ser mas laxo en cuanto a permisos. Para evitar tener que asignar permisos cada vez que se cambian archivos en el sitio, es conveniente agregar al usuario del repositorio remoto (en este ejemplo "webmaster") al grupo que utiliza el servidor HTTP ("www-data" en Debian y derivados). Luego, configurar en el repositorio los permisos necesarios para el sitio Web: lectura para el grupo "www-data", y escritura sólo donde sea específicamente necesario (directorio para subidas de archivos, sesiones, temporales, etc.).
# cd .. # chown -R webmaster:www-data . # chmod -R 750 .
Repetir el esquema de permisos en el directorio Web y comprobar su funcionamiento:
# cd /var/www/demo/aplicacion1/ # chown -R webmaster:www-data . # chmod -R 750 .
Referencias
man git-push man git-checkout
Fuente: linuxito
