Os presento una serie de artículos sobre configuración y uso de GIT para gestión de proyectos Web con la que explicamos como configurar un entorno de producción + desarrollo y como desplegar nuevas versiones correctamente.

La arquitectura que vamos a crear es la de la siguiente figura:

Dicha arquitectura presenta las siguientes características:

• Permite varios desarrolladores trabajando en paralelo.
• Los desarrolladores trabajan en su máquina local y publican los cambios a un repositorio común compartido.
• Proporciona un entorno de pruebas (pre-producción), donde testar nuevas funcionalidades y cambios antes de pasar cambios al entorno de producción.

Configuración del servidor Web

Aunque no es estrictamente algo relacionado con GIT, será necesario configurar el servidor Web para poder trabajar con un subdominio que utilizaremos para la fase de test, de forma que:

• En www.midominio.com será visible la versión en producción.
• En test.midominio.com será visible la versión en pre-producción.

Si tienes un hosting con Panel de gestión, está operación es sencilla desde el mismo. Si eres como nosotros, de los aventurados que quieren tener todo el control y no tienes Panel, entonces lo tendrás un poco más complicado, pero seguramente no necesitarás un tutorial para hacerlo ;)

Instalación y configuración de GIT

El siguiente paso será instalar GIT en el servidor y crear los repositorios, tanto en el servidor (respositorio central compartido), como en los ordenadores de los desarrolladores.

Supondremos que tenemos un proyecto ya con una serie de archivos por ser el caso más complejo.

En el artículo Crear repositorio GIT con proyecto existente se explica el proceso y como enviar al repositorio compartido la primera versión del proyecto.

Como nota adicional, se puede consultar el siguiente artículo, que describe la diferencia entre repositorios GIT bare y non-bare, algo que sin duda vendrá bien a los que os estáis iniciando en GIT.

GIT branches del proyecto y su gestión

Con una arquitectura como la anterior, deberemos tener habitualmente 3 ramas de desarrollo.

• Branch development. Sirve para desarrollo y para ir almacenando versiones intermedias, compartir commits entre desarrolladores, etc, pero no tiene una versión accesible en el servidor del proyecto.
• Branch test. Es una versión de pre-producción, que contendrá todos los cambios para la versión en preparación y servirá para realizar todos los test antes de su publicación.
• Branch master. Es la versión en producción, visible por los usuarios de la Web.

Versiones de producción y preproducción en GIT

Desde el punto de vista de GIT, las versiones en producción y test son repositorios con una copia de trabajo, de forma similar a los repositorios existentes en las máquinas locales de los desarrolladores.

Esto permite hacer cambios directamente en los sistemas de producción y test (accediendo por FTP/SSH) y realizar los correspondientes commits y push al repositorio compartido sin perder la trazabilidad de los archivos y el control de versiones, es decir, podemos ‘desarrollar’ directamente en las carpetas del servidor de producción o de test, como si lo hiciésemos en una de las máquinas de los desarrolladores.

Evidentemente esto no es recomendable, pero a veces es muy útil en ciertas situaciones de emergencia.

Deploy de versiones en GIT

Cuando se alcanzan un determinado punto del desarrollo y queremos publicar los cambios, lo habitual será que el desarrollador principal reuna todos los cambios en su equipo, realice los merges correspondientes desde cada rama de cada funcionalidad y finalmente publique los cambios al servidor de pre-producción.

El flujo de trabajo podría ser el siguiente:

Obtenemos la rama test, sobre la que vamos a unir todas las ramas de desarrollo que otros desarrolladores (o nosotros mismos) hemos mantenido en paralelo.

user@mipc:/# git checkout test

Merge de las ramas de desarrollo. Durante este proceso, pueden aparecer conflictos cuando varias ramas del desarrollo modifican el mismo fichero. Si el caso habrá que solucionarlo manualmente y realizar el commit correspondiente, pero por simplificar, dejaremos dicha situación para otro momento.

user@mipc:/# git merge funcion-1
user@mipc:/# git merge funcion-2
user@mipc:/# git merge funcion-3

En este punto podemos realizar algunas pruebas de validación locales para validar que el proceso de merge se ha realizado correctamente. Una vez comprobado publicamos los cambios al servidor compartido para iniciar la fase de test.

user@mipc:/# git push origin test

Y para que los cambios se vean en el servidor, tendremos que entrar vía SSH y actualizar la rama de test en el servidor:

user@mipc:/# ssh user:server
user@mipc:/# git pull origin test

Deploy automático de versiones con GIT

Este último paso puede ser muy tedioso si tenemos que enviar cambios a test o producción con mucha frecuencia, ya que cada vez tenemos que repetir el proceso y conectarnos en remoto al servidor para realizar el pull correspondiente.

Este paso puede evitarse con un sistema de deploy automático que realice el pull de forma automática cuando realizamos un push al repositorio compartido. Para ello se utilizan los denominados hooks de GIT, y podéis ver como implementarlo en el artículo Deploy automático de versiones con GIT.