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:
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:
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:
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):
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:
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:
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:
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.