Julio
2009
Sistemas de control de versiones en la vida real
Los sistemas de control de versiones no son ninguna novedad (CVS, SVN, GIT, Mercurial...) lo que si es novedad es empezar a usarlos en sitios que hace unos años ni siquiera se hubieran contemplado.
Tenía ganas de hablar sobre este tema pero me acaba de convencer un bug que acabo de recibir: #537237 .
Desde hace ya varios meses en todos los servidores que administro y en mi portátil personal tengo montado el directorio /etc bajo control de versiones con GIT. Hacerlo es de lo más sencillo que hay:
cd /etc git init git add . git commit -m "importado /etc"
¿Qué ventajas tiene esto?
Pues más que en un equipo de escritorio (que puede ayudarnos a arreglar cosas si andamos con Debian unstable) en los servidores es super útil.
¿Hay que crear un VirtualHost en Apache o editar cierta configuración?
Nuevo "commit" con su respectivo comentario y eso queda para la historia si alguna vez nos da problemas y no sabemos por donde arreglarlo tenemos el log y los diff.
Existen paquetes como etckeeper que se encargan de la parte más complicada por nosotros, pero a mi me sirve con usar git a pelo. Una de las cosas que he añadido es un disparador para apt que se encargue de hacer un commit cada vez que instalamos o desinstalamos algo. (lo tomé prestado de algún sitio y ahora no recuerdo donde)
#!/bin/bash
set -e
caller=$(ps axww | mawk '/aptitude|apt-get/ {for (i=5; i<=NF ; i++) printf ("%s ",$i); printf ("\n") }' | head -1)
STATUS="$(git status)" || true if echo $STATUS | grep '\(modified\|new\|remove\)' > /dev/null 2>&1 ; then echo "git-snapshot-script: found changed files" echo $STATUS git commit -a -m "snapshot after: $caller" else echo " **GIT** git-snapshot-script: no changes" fi echo " **GIT** git-snapshot-script: done"
Basicamente se lee el nombre de proceso que llama a este script (por ejemplo: apt-get install postfix) se mira si el directorio /etc ha cambiado y se hace el commit quedando en el log el programa que provoco esos cambios.
Para que el invento funcione debemos decirle a apt que llame al script:
cat /etc/apt/apt.conf
DPkg {
Post-Invoke {"cd /etc ; ./apt/git-snapshot-script";};
}
IMPORTANTE: Procura que el directorio /etc/.git solo pueda leerlo y escribirlo root (chmod 700 /etc/.git; chown root:root /etc/.git), con ese directorio se puede sacar el /etc/shadow por ejemplo y probar programas de fuerza bruta para sacar las contraseñas.
Mi vicio por git no termina aquí. Últimamente ando modificando unos cuantos CMS para uso personal o para clientes y un día puse esas web bajo control de versiones, ¡qué gozada! hacer mini-cambios y poder revertirlos, jugar con varias ramas, etiquetar... y para ejemplo un botón, Galopín es nuestro sistema de facturación interno y he ido tocando cosas que no acababan de convencerme, aquí está el git publicado. El primer import tiene parches ya de varios años de uso ;)
para temas web es interesante tener un repositorio en tu servidor web. Trabajando en local, una vez tengas los cambios que quieres puedes hacer un "git push" (teniendo como remote el server) y con un hook (post-recieve) hacer el deploy (un reset del working copy y otras tareas)
Acabo de descubrir que si pones "mariodebian" en la barra de url de Firefox te trae directamente al blog. "Vas a Tener Suerte"
Me encantó la idea de poner un script en apt que haga un commit al cambiar algo. ¿No se podría poner de wishlist algo así para que sea parte de apt?
Hola. No se nada de git por eso me ha gustado este post. Una duda: supongo que al teclear los dos primeros comandos se crea un directorio .git dentro del que estamos trabajando, que es el que se condiera como "repositorio" de los "cambios". Si es así, habría que hacer esto en cada directorio de trabajo que queramos "monitorizar" con git, por lo que los repositorios estarán distribuidos, ¿es mejor tenerlos así o es mejor tener un repositorio central? Lo digo por temas como el backup, etc.
Otra cosilla que me gustaría, javisantana, es posible obtener una guía, howto, o similar, con un ejemplo práctico de lo que sugieres. Es justo lo que me gustaría conseguir.
Muchas gracias.
Yo hace poco que he empezado con GIT para controlar el super grub disk. La verdad es que aún no lo tengo cogido del todo. Pero lo poco que he podido experimentar me gusta. El no tener que depender de un repositorio remoto, me refiero a no tener que necesitar conexión a internet.
El poder abrir ramas hasta el infinito (muy acorde a mi forma de ver el mundo).
Se hace uno lio con el push, pull y merge (aún tengo que aprender que hace cada cosa exactamente) pero creo que merece la pena.
Ya había oido eso de usar .git para administrar el /etc pero quizás sea a partir de esta guia que me anime a usarlo, pero, la verdad, el /etc no es que lo toque mucho. Pero el otro día estaba intentando hacer funcionar una aplicación en Debian Unstable y conforme usaba unos paquetes y otros tenía que repetir la modificación de la configuración de un fichero y... con un par de comandos me hubiera ahorrado esos comandos.
Gracias por compartir tus experiencias, a ver si tomo ejemplo y actualizo mi blog más a menudo que lo tengo algo parado.
Aquí un script intertesante empleando incron y git
http://andrew.mcmillan.net.nz/blog/using_incron_to_autoversion_a_directory