Todas

Noticias ICM

caso práctico GitLab CI/CD

Caso práctico GitLab CI/CD

Ahora ya sabemos las distintas partes que engloban el funcionamiento de Gitlab CI/CD. En este articulo vamos a mostrar un resumido caso práctico de cómo funcionaría GitLab CI/CD.

Caso práctico GitlLab CI/CD

Vamos a suponer que tenemos un API de Node que trae una lista de libros de una base de datos. Un escenario bastante sencillo y práctico, para no complicar mucho las cosas.

A partir de ahora, podemos crear una tubería (pipeline a partir de ahora), que empuje nuestro código en 3 fases: construcción, pruebas y entrega. Recordemos que un pipeline es un grupo de pasos que son agrupados bajo características similares. Con estas fases o etapas, nuestro pipeline es definido en 3 tipos:

  • 1: El Pipeline del proyecto (Project Pipeline).
  • 2: El Pipeline de integración continua.
  • 3: El Pipeline de entrega.

El pipeline del proyecto instala dependencias, corre los linters y cualquier script que tenga que ver con código. El pipeline de integración continua corre pruebas automatizadas y construye versiones distribuidas del código. Finalmente, el pipeline de entrega, entrega el código a un ambiente de un proveedor de nube designado.
El esquema resultante resumido sería el siguiente:

caso práctico Gitlab CI/CD I

En esta jerarquía, los tres componentes son considerados tres diferentes pipelines. Las partes importantes (build, test y deploy) son etapas (stages) y cada parte debajo de estas secciones son trabajos.

Usando GitLab CI/CD

Para usar GitLab CI/CD, creamos un archivo con nombre “.gitlab-ci.yml” en la raíz del proyecto de nuestro repositorio de GitLab y agregamos el siguiente código yaml:

código yalm

Como mencionamos en el artículo anterior, GitLab CI/CD usa los Runners para ejecutar los pipelines. Podemos definir que sistema operativo y librerías predefinidas en las cuales queremos basar nuestros runners usando la directiva image. En nuestra instancia, estaremos usando una de las últimas versiones de Node.js para nuestro runner.

La directiva stages permite que pre definamos una etapa para la configuración entera. Los trabajos se ejecutan basados en el orden listado en la directiva stages. Por otro lado, la directiva before_script se usa para ejecutar un comando antes de todos los trabajos.

Caso práctico GitLab CI / CD: etapa build

Primero, vamos a comenzar con nuestro trabajo dedicado a la etapa build. Llamaremos a este trabajo “build-min-code”. Vamos a querer que este trabajo instale las dependencias. Así, podemos comenzar esto usando la directiva script, la directiva script es el caparazón del script que se ejecuta dentro del runner. Después vamos a asignar este trabajo a la etapa build.

Para asignar un trabajo a la etapa o stage, usamos la directiva stage:

stage

Ahora tenemos un trabajo asociado con nuestra etapa de construcción (o build) y ahora aplicaremos el proceso para la etapa de prueba (o test):

test

Finalmente, vamos a agregar un trabajo para manejar nuestra etapa de entrega (o deploy) que se va a llamar “deploy-production” y “deploy-staging”. En esta instancia, vamos a tener dos trabajos diferentes para el deployment (staging y production).

Directiva only

Actualmente, todos nuestros trabajos están automáticamente establecidos para ejecutarse en cualquier código (push or branch), que se haya mandado a push, o a cualquier rama. No queremos tener cuando lo entreguemos nuestro código a staging ni mucho menos en producción. Para prevenir que eso suceda, usamos la directiva only. La directiva only define los nombres de las ramas y etiquetas para los trabajos que deberán correr. El trabajo buscará lo siguiente, por ejemplo:

directiva only

En nuestro trabajo deploy-staging, el Runner ejecutará exclusivamente si hubo un cambio en la rama develop, y el trabajo deploy-production si hubo algún cambio en la rama master.

La imagen a continuación muestra el código que ese envía (push) a la rama master:

caso práctico GitLab CI/CD master

De esta imagen podemos observar, que los tres estados y trabajos son detonados con excepción de deploy-staging, ya que el código enviado fue a la rama master.

GitLab CI/CD viene con una intuitiva interface que nos ayuda a mostrar qué trabajos y etapas están corriendo y qué errores han ocurrido en medio de la construcción. Resumiendo el caso práctico de GitLab CI/CD, os dejamos cómo quedaría el archivo .gitlab-ci.yml para este ejemplo:

final caso práctico GitLab CI/CD

Conclusión caso práctico GitLab CI/CD

En este artículo os hemos explicado el caso práctico de usar GitLab CI/CD. Así, hemos podido observar y aprender cómo se construye el .gitlab-ci.yml para poder usar el GitLab CI/CD, aunque solo se muestran algunas capacidades que ofrece GitLab CI/CD.

GitLab tiene la posibilidad de ofrecer un control más a fondo de la automatización de nuestros códigos base, por ejemplo construyendo y publicando imágenes Docker, para integrar con herramientas de terceras partes entre muchas más funciones que tiene.

Tags: , ,
Comenta

Deja una respuesta

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

Confían en nosotros

autopistas
La habitación de las niñas
Naturgy
Andreu World
GREY
Saba
HOPPER
Axel Hotel