Pongámonos técnicos

Primero, un poco de contexto y algunos detalles.

He estado trabajando en una aplicación web y el flujo de desarrollo y deployment ha sido muy simple. Tenemos todo el hosting montado en un VPS de digitalocean y todo el código está en bitbucket.org (básicamente porque se pueden tener repositorios privados de manera gratuita, contrario a github.com) y en el mismo bitbucket llevamos todo el seguimiento de los issues, cambios y requerimientos.

En el VPS, tenemos el servidor de producción y cada vez que se realiza un push al bitbucket, entramos al servidor y con un pequeño script, actualizamos el código y al mismo tiempo reiniciamos la aplicación (corre en Node.JS):

#!/bin/sh
cd /webapp
git checkout .;
git pull;
ps -ef | grep node | grep webapp | awk '{print $2}' | xargs kill;
exit $?

Esto de tener que entrar al servidor y ejecutar el deployment manual (aunque no es lo más recomendado), nos ha dado la oportunidad de lanzar código a producción solo después de pasar por varias pruebas locales y además, que solo tengan accesos las personas que puedan trabajar con esa información sensible de usuarios reales.

Sin embargo, a estas alturas del desarrollo, es necesario trabajar con un stage porque vamos a realizar unos cambios considerables que van a romper algunas cosas de la plataforma y además, habrá más personajes involucrados en el desarrollo y necesitarán ver en “vivo” los cambios que se vayan haciendo.

Por esa razón y porque tener un stage es parte del proceso de desarrollo, vamos a hacer la configuración para que esto funcione.

En el ambiente local

Primero, vamos a tener que generar las llaves para conectarnos mediante SSH al servidor de producción:

ssh-keygen -C "usuario@dominio.com"

Esto genera como resultado lo siguiente y dos archivos, que uno de ellos lo usaremos más adelante (id_rsa.pub):

[ arathvelazquez@Air:~/.ssh ] $ ssh-keygen -C "usuario@dominio.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/arathvelazquez/.ssh/id_rsa): id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in test_rsa.
Your public key has been saved in test_rsa.pub.
The key fingerprint is:
98:2f:bd:ba:ww:ww:xx:xx:yy:yy:87:3e:56:2a:01:da usuario@dominio.com
The key's randomart image is:
+--[ RSA 2048]----+
| .o |
... (algunos renglones más)
| + o o |
| oo. |
+-----------------+

En el servidor

Del lado del servidor, estando como root, vamos a crear un usuario que se llame git.

root@prod:~# su -
root@prod:~# adduser git
Adding user `git' ...
Adding new group `git' (1000) ...
Adding new user `git' (1000) with group `git' ...
Creating home directory `/home/git' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for git
Enter the new value, or press ENTER for the default
Full Name []: git
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y

Una vez creado este nuevo usuario, vamos a hacer login como git, vamos a crear el directorio de .ssh en su home y vamos a crear un archivo que tendrá la lista de las llaves públicas de los usuarios que podrán acceder y poder conectarse.


root@prod:~# su git
git@prod:~$ pwd
/home/git
git@prod:~$ ls -l
total 0
git@prod:~$ pwd
/home/git
git@prod:~$ mkdir ~/.ssh && touch ~/.ssh/authorized_keys

Teniendo eso listo, vamos a tener que agregar al archivo ~/.ssh/authorized_keys la llave pública que generamos en nuestro ambiente local.

Aún en nuestro servidor, vamos a crear lo siguiente:

git@prod:~$ mkdir stage.git && cd stage.git
git@prod:~/stage.git$ git init
Initialized empty Git repository in /home/git/stage.git/.git/

En el comando de git init se podría agregar --bare, que lo que hace es que no se trae el código, solo el controlador de version de Git pero en mi caso, sí necesito el código ya que haré pruebas en stage y necesito correr el servidor con los nuevo cambios.

Otra vez en el ambiente local

En nuestro directorio con el código, vamos a crear un nuevo repositorio que llamaremos “stage” pero antes, vamos a enlistar los actuales de la siguiente manera:


[ arathvelazquez@Air:~/Code/webapp ] $ git remote -v
origin git@bitbucket.org:arathvelazquez/webapp.git (fetch)
origin git@bitbucket.org:arathvelazquez/webapp.git (push)

Creamos el nuevo repositorio

[ arathvelazquez@Air:~/Code/webapp ] $ git remote add stage ssh://git@dominio-webapp.com/home/git/stage.git
[ arathvelazquez@Air:~/Code/webapp ] $ git remote -v
origin git@bitbucket.org:arathvelazquez/webapp.git (fetch)
origin git@bitbucket.org:arathvelazquez/webapp.git (push)
stage ssh://git@dominio-webapp.com/home/git/stage.git (fetch)
stage ssh://git@dominio-webapp.com/home/git/stage.git (push)

Si fuera necesario actualizar la URL del nuevo repositorio, sería de la siguiente manera

[ arathvelazquez@Air:~/Code/webapp ] $ git remote set-url stage ssh://git@dominio-webapp.com/home/git/stage.git
[ arathvelazquez@Air:~/Code/webapp ] $ git remote -v
origin git@bitbucket.org:arathvelazquez/webapp.git (fetch)
origin git@bitbucket.org:arathvelazquez/webapp.git (push)
stage ssh://git@dominio-webapp.com/home/git/stage.git (fetch)
stage ssh://git@dominio-webapp.com/home/git/stage.git (push)

De ahora en adelante, si queremos hacer el push a “stage”, solo bastará con hacerlo de la siguiente manera:

[ arathvelazquez@Air:~/Code/webapp ] $ git push stage master

Deja un comentario

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