Publicar tus proyectos con git

Si eres programador seguramente conoces alguna herramienta de control de version. En mi caso uso Git y actualmente me resulta imprescindible para el desarrollo de proyectos. No voy a escribir una guía de iniciación a Git ni nada por el estilo, ya hay mucha documentación en la red. En esta entrada explicaré como uso git para plublicar proyectos en servidores de producción.

Publicar con git es una tarea que puede hacerse de varias formas. Suele ser habitual usar un repositorio remoto alojado en servicios como github o similares donde se centraliza el desarrollo del proyecto. Este método es una buena solución sobre todo para equipos con varios desarrolladores.

Otro método usado sobre todo si estás solo en el proyecto o no quieres utilizar github, consiste en publicar directamente en servidores de producción desde tu respositorio local. Este último es que vamos a ver en esta entrada.

Publicar En Produccion Con Git

Requisitos previos

Obviamente necesitas un cliente git tanto en el servidor como en nuestra máquina local. También necesitas acceso SSH al servidor.

Si tienes un VPN o un servidor dedicado probablemente tienes todos los requisitos (o puedes instalarlos). Si tienes un hosting compartido deberás comprobarlo (no todos tienen accesso SSH). Una vez comprobados los requisitos vamos con la configuración del servidor:

1. Configurar respositorio en servidor

Accede por SSH al servidor de producción.

ssh USER@DOMAIN.COM -p 2222
...
Enter your password: *********

Cambia USER, DOMAIN.COM y el número de puerto por los tuyos, si no los conoces consulta con tu proveedor de hosting.

Una vez dentro dirígete al directorio de producción y crea un repositorio git.

git init

Git debe aceptar push desde otros respositorios. Para ello ejecutamos el siguiente comando:

git config receive.denyCurrentBranch ignore

A continuación hay que utilizar los hooks de git. Un hook es un archivo con comandos que se ejecutan después de una acción. En nuestro caso necesitamos que git actualice el directorio de producción cuando reciba una acción push. Para ello debes crear un archivo llamado post-receive en la siguiente ruta PATH_TO_DIR/.git/hooks/post-receive. El contenido del archivo debe ser el siguiente:

#!/bin/sh
GIT_WORK_TREE=../ git checkout -f

Asegúrate de que el archivo post-receive tiene persmisos de ejecución:

chmod +x PATH_TO_DIR/.git/hooks/post-receive

2. Configurar SSH en local

Ahora volvemos a nuestra máquina local. Si usas el puerto por defecto (es el 22) para las conexiones SSH puedes saltarte este paso. Para mi conexión necesito el puerto 2222, por lo que debo especificarlo en el archivo config de SSH que se encuentra en la siguiente ruta: ~/.ssh/config. Si el fichero config no existe lo creas y le añades el siguiete contenido:

Host DOMAIN.COM
  Port 2222

Esto hace que cualquier intento de conexión con DOMAIN.COM se haga a través del puerto 2222. Algo necesario para las conexiones de git a la hora de publicar en nuestro servidor.

3. Configurar respositorio en local

Seguimos en nuestra máquina local y el último paso consiste en añadir el repositorio remoto al repositorio local. Vamos a nuestro directorio de trabajo y ejecutamos el siguiente comando:

git remote add PRODUCTION USER@DOMAIN.COM:PATH_TO_DIR_PRODUCTION
  • USER es el usuario para acceder al servidor.
  • DOMAIN.COM es el servidor.
  • PRODUCTION es el nombre que le damos al respositorio remoto. Puedes elegir el que quieras
  • PATH_TO_DIR_PRODUCTION es la ruta al repositorio desde el HOME de tu usuario en el servidor

Con esto ya la tienes todo configurado. Cuando vayas a publicar en el servidor tan sólo debes ejecutar el siguiente comando:

git push PRODUCTION master

Te pedirá una contraseña, que no es otra que la que usas para acceder por SSH al servidor.

Extra: Publicar sin contraseña

Si quieres evitar meter la contraseña cada vez que quieras publicar, puedes configurar el acceso SSH con una clave pública.

En nuestra máquina local editamos el contenido del fichero ~/.ssh/config y añadimos PreferredAuthentications publickey a nuestro DOMAIN.COM. El archivo queda de esta forma:

Host DOMAIN.COM
  Port 2222
  PreferredAuthentications publickey

Ahora necesitas una clave pública. Éstas se encuentran en el directorio ~/.ssh/ con nombres como id_rsa.pub. Si no tienes claves públicas puedes crearlas con este comando:

ssh-keygen -t rsa -C "your-email@domain.com"

En uno de los pasos te va a pedir una contraseña, déjala en blanco, si no deberás introducirla cada vez que publiques con git y eso es lo que tratamos de evitar. Ojo con esto, si alguien accede a tu ordenador también podrá acceder a todos los servidores que hayas configurado de esta forma.

Una vez terminado el comando, se habrá creado un clave pública en esta dirección ~/.ssh/id_rsa.pub. La abrimos con un editor de texto y copiamos el contenido.

Ahora debes acceder a tu servidor por SSH y abres el fichero ~/.ssh/authorized_keys . Si no existe el fichero lo creas y pegas el contenido de la clave pública.

Si todo está bien configurado la próxima vez que te conectes por SSH al servidor no te pedirá contraseña. Y tampoco te la pedirá git cuando publiques en el servidor.

Pero si ya tengo mi ftp!

Cada programador tiene sus flujos de trabajo y no hay mejores ni peores. Cada uno tiene sus preferencias, y probablemente publicar por FTP sea lo más usado. En mi flujo de trabajo utilizar git me da mucha rapidez y control de todas las acciones. Te pongo un par de ejemplos.

Desarrollo temas y plugins personalizados para mis clientes. Una vez terminado el desarrollo realizo las pruebas necesarias en local, a continuación etiqueto la versión y lo subo al servidor de producción (o de prueba). Vuelvo a realizar pruebas en el servidor y si algo va mal, utilizo git para volver a la versión anterior en mi máquina local y publico de nuevo en producción. Es un proceso muy rápido y todo sin salir del cliente git.

Otro ejemplo. Supongamos que tengo un tema de WordPress ya en producción y necesito crear una versión nueva. Me creo una rama de desarrollo y me pongo a picar código. En este periodo de desarrollo sale un fallo en producción. Con git vuelvo a la rama master (la que está en producción) saco una rama nueva llamada hotfix, soluciono el fallo y subo a producción. Ahora vuelvo a la rama de desarrollo, hago un merge con los nuevos cambios y continuo trabajando.

La ventaja que veo en todo esto es que el flujo de trabajo está completamente controlado con git, desde el desarrollo hasta la plublicación en producción. Todo muy rápido y sencillo sin cambiar de aplicaicón. Adios ftp!.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *