Creamos nuestra cuenta en GitLab

Vamos a crear nuestra cuenta en GitLab, que va a ser la herramienta utilizada para llevar
a la práctica nuestros Pipelines.

Registración y preparación del entorno

1. En la pantalla inicial, nos dirigimos a “Register now”

2. Los datos que debemos completar son los siguientes, automáticamente nos
informará si el nombre de usuario o email seleccionado está en uso.

3. Recibiremos una confirmación y se nos informa que debemos ir a chequear nuestro

email; revisar correctamente tanto Inbox como carpetas de Spam.

1
4. Confirmamos nuestra cuenta, con lo cual ya estamos en condiciones de loguearnos.
5. En la pantalla inicial de bienvenida seleccionamos “Create Project”, luego “Create
blank Project” y finalmente, completamos el dato de “Project Name”; dejamos la
visibilidad de este en “Private”.

1) 2)

3)
6. Por defecto se nos crea un Repositorio Git en el cual podemos subir nuestros
archivos, en el mismo se incluye un README.md con instrucciones básicas para
dicho fin. Si bien como en todo repositorio Git podemos subir nuestros archivos a
través de la interfaz Web, no es su uso habitual, así que ahora prepararemos nuestro
entorno para poder subir código desde nuestro equipo; nos llevara unos pasos en los
cuales debemos utilizar nuestra línea de comandos / consola
6.1. Abrimos en NUESTRO EQUIPO un Shell como Bash o la Terminal de Linux con el
propósito de generar una SSH Key, para ello ejecutamos:
ssh-keygen -t rsa

2
 Nos preguntará por un nombre y un passphrase (opcional), dejamos todo por
defecto
Leemos el contenido del mismo con
cat ~/.ssh/id_rsa.pub
se nos mostrará un contenido tal como
cat ~/.ssh/id_rsa.pub
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABgQCmixQfacbczvWXZmkQJ6+UqNRYQuglycl+0qJ0gvsbX
gG8D9MjwClrQQPeKmmOpSSZPmog3anGMEv3CraRJD0nwjml+NSPRyrHSV+l7V9x++gxk+b52l
xKnQuHMzrgWt62uflABx8hi5pzgrC1SpF3fkyzG25sO7xNclJ9cKuAwzfHCJ1JEOCQQ1yUsu5
0+xEgGdo3AjaGpAn04Mqniq435CwmMbEDZqWpcWCqw7V0gwgonbPBYrrprTUIRpAu7az7RoW4
z1GUzMWEr9KICfpgvBBUgmfwULKxSaGuetHfRAa9NQenSc2emaMSURdxkkm8b+r2xyK7TJ6y+
140rVkfXKHm8jdEz9XJlyJBn3QoeYLShYp9TmSiGwTy9SCcuUljQO4K3eSA49Zbh+ZUjE0H2m
v9ws9TVYl88mww+oLxgj3z+AJN5f8DEaFm9mhx+CBgfmQzOKkXes+8jveUgjrLO8Zzg/rsTB9
h+h2dCPMWKcexhSvwqpHPIxpW6U7lrHs= mundose@mundose

6.2. Nos dirigimos al Gitlab, en la sección “SSH Keys” (SSH Keys · User Settings ·
GitLab ”
6.3. Copiamos todo el contenido que se mostró en el punto 6.1 con el comando cat (a
partir de que comienza con ssh-rsa inclusive) y lo pegamos en la sección “Key”, le
damos un nombre en “Title” y opcionalmente una fecha de expiración, luego de
ello en “Add Key”.

6.4. Una vez guardada la misma en GitLab, debemos verificar que podemos
conectarnos desde nuestro entorno, para ello volvemos a nuestro Shell y
ejecutamos
ssh -T [email protected]

3
 Si es satisfactorio, debemos recibir el mensaje “Welcome to GitLab, @MINOMBRE DE
USUARIO!”

Con lo cual podremos subir nuestro código al repositorio de Gitlab.

Subimos nuestro primer código

Como ejemplo, subiremos un código fuente hecho en Node, el mismo se puede
descargar desde aquí
https://gitlab.com/demonccc/node-bulletin-board/-/archive/master/node-bulletin-boar
d-master.zip

1. Una vez descargado y descomprimido, nos dirigimos hacia la carpeta

“node-bulletin-board-master” en nuestro Shell. Una vez allí dentro, inicializamos el
repositorio con el comando

git init

2. Agregamos el origen remoto con el comando, teniendo en cuenta que en lugar de

“usuario” irá su nombre de usuario y en lugar de “proyecto”, el nombre de su proyecto

git remote add origin https://gitlab.com/usuario/proyecto.git

3. Agregamos los archivos del proyecto con

git add .

4. Realizamos el commit con

git commit -m "First Commit"

5. Cambiamos al Branch de test (IMPORTANTE: por defecto GitLab protege al Branch

main, es por ello que usamos un Branch de test)

git branch -M feature-x

6. Finalmente hacemos push de nuestro código

git push -uf origin feature-x
7. Observamos en GitLab, en el Branch correspondiente que nuestro código ya está
subido.

4
Creamos nuestro primer pipeline
Ahora vamos a crear la definición de un pipeline en GitLab es el archivo .gitlab-ci.yml, el
cual debe estar alojado en la raíz de nuestro proyecto.

Para ello, abrimos un Shell en nuestro equipo, nos dirigimos a la raíz de nuestro proyecto
y allí creamos con el editor de texto de nuestra preferencia el archivo .gitlab-ci.yml

1 - Configuramos la imagen

Vamos a definir qué imagen de Docker se va a utilizar para ejecutar los pasos del
pipeline

image: node:14

5
2 - Creamos los stages

La definición del pipeline se da en stage y jobs, estos pertenecen a los stages, es

decir, los primeros stages son los que están a mayor nivel jerárquico.

La ejecución de los stages es de acuerdo a como los definamos en nuestro archivo,

por convención para esta primer práctica, construiremos dos stages

● test
● build

Agregamos en nuestro archivo .gitlab-ci.yml las líneas, recordemos siempre respetar

el indentado

stages:

- test

- build

Si bien esta definición es correcta, básicamente este pipeline no hará nada ya que los
stages carecen de jobs, que es donde se ejecutan los trabajos.

3 - Agregamos los jobs

Los jobs se definen en el archivo y su pseudo estructura es

nombre_job

stage: “stage a la que pertenece”

script:

- “comandos a ejecutar en el job”

Nosotros en primer lugar vamos a definir un job para nuestro stage “test”, el cual
ejecutara los tests especificados para este código, con lo cual el comando será:
“npm run test”.

6
El codigo de nuestro .gitlab-ci.yml con el agregado del job deberá ser:

image: node:14

stages:

- test

- build

test_job:

stage: test

script:

- echo "NPM tests started..."

- npm run test

Hasta ahora, definimos el pipeline, pero aun GitLab no se ha enterado de los cambios, es
momento que lo haga y para ello debemos impactar estos cambios que aún están en
nuestro equipo en el repositorio, es por eso que debemos hacer push de este nuevo
archivo, ejecutando en nuestro equipo:

git add .
git commit -m “Added pipeline”
git push

GitLab, al recibir los cambios en el código, detecta automaticamente la presencia del

archivo .gitlab-ci.yml y si su estructura es válida, EJECUTA los pasos definidos en el, es
por ello que ahora si vamos a nuestro GitLab CI/CD Pipelines, observaremos el listado de
Pipelines ejecutados y alli estará el correspondiente al último commit:

7
Si ingresamos en el número del pipeline allí veremos los stages que se ejecutaron:

Aquí vemos que solo se ejecutó el stage BUILD, y su job “test_job”, si ingresamos en él
observaremos todo el detalle de la ejecución:

8
Detalles de la ejecución del “test_job”, en donde se observa el Job succeeded

Al estar vinculado con el repositorio de código, ante cualquier cambio en mi código

fuente (no solo en el .gitlab-ci.yml) el pipeline se volverá a ejecutar.

Si realizamos un cambio en algún archivo del código fuente (por ejemplo el mensaje
mostrado en index.html) y al realizar el push observar el comportamiento del pipeline.

Al agregar el job de build al stage de Build el pipeline quedaría de esta manera:

image: node:14

stages:

- test

- build

test_job:

stage: test

script:

- echo "NPM tests started..."

- npm install

- npm run test

build_job:

stage: build

script:

- echo "NPM build started..."

- npm run build

9
Nuestro Pipeline se debió ejecutar de manera satisfactoria, con lo cual al ver los detalles
del mismos deberíamos verlo así (lo vemos en el menú CI/CD Pipelines # de pipeline)

Ahora lo que vamos a realizar son modificaciones en el archivo server.js con el propósito
que fallen nuestras stages.

Cuando un Pipeline falla, en este ejemplo hicimos fallar el stage de test, vamos a ver en
nuestro resumen del Pipeline

Y es allí cuando debemos investigar porque sucedió, en este caso nos vamos a dirigir al
test_job y nos abrirá el verbose / debug de todo el proceso, desde que se genera el
entorno para las pruebas hasta el momento en que se prueba.

Lo importante, es que si un stage falla, el siguiente no se ejecutara cómo vemos a

continuación:

10
11