Mis notas - Lo que aprendí de GitLab CI y pipelines (principiante)

Buenas a todos. Este es mi primer articulo por este medio, es una guía simple y corta con algunos conceptos básicos sobre GitLab CI y pipelines. No es mi intención entrar en detalles muy técnicos ni profundos.

Espero que para aquellos que recién empiezan con GitLab CI les sirva de apoyo.

TEMAS

1. Introducción
2. Pipelines
3. Jobs
4. Runners

1. Introducción

En la imagen de arriba se puede observar en un nivel general el flujo de CI/CD en GitLab CI, en donde el programador hace un push de sus cambios a una nueva rama y es el mismo GitLab a través de un pipeline y un(o varios) runners que puede integrar y distribuir los nuevos cambios de una manera continua.

Este CI/CD esta basado en etapas en donde se deben cumplir ciertos requerimientos para pasar a la siguiente. Cada una de estas etapas tiene un objetivo, como por ejemplo hacer tests, construir, entregar, etc.

Para cumplir estos objetivos, las etapas estan conformadas por una serie de trabajos. 

Posiblemente la mejor analogía seria una fabrica de autos como la de la imagen de arriba, en donde existen diferentes areas (stages) con objetivos definidos, como por ejemplo el área de ensamblaje o el área de pruebas. En donde en cada área existen diferentes tipos de trabajos(jobs) que ayudan a cumplir el objetivo del área en cuestión. Cada área depende de del trabajo de un area previa (no es posible testear algo si no fue construido previamente).

Mas adelante veremos como se componen cada una de estas etapas y a que nos referimos cuando hablamos de jobs y stages. También aprenderemos a entregar nuestro producto (delivery). Si nos guiamos por el ejemplo de la fabrica de autos, seria la entrega del auto ya terminado y testeado al cliente.

2. Pipelines

Un pipeline en el mundo de la ingeniera de software es entendido como una cadena de eventos (de procesos, componentes, etc) que automáticamente disparan y entregan inputs al siguiente elemento. Esto se parece mucho a los pipelines físicos que existen en el mundo real.

En un contexto de CI, un pipeline es una colección de pasos secuenciales que integran el código de diferentes programadores. La cadena de eventos es disparada por un commit o por un push al código fuente del repositorio como un Gitlab. El sistema de build (por ejemplo Jenkins o Gitlab) es notificado de esta nueva versión, lo compila, lo coloca como nuevo código y corre tests unitarios.

Antes de continuar es importante entender que:

SIN TESTS UNITARIOS O TEST AUTOMATICOS, EL ESFUERZO DE INTEGRAR PIEZAS DE CODIGO DE DIFERENTES PROGRAMADORES ES MUY COMPLICADO.

ASI QUE ANTES DE ESCRIBIR Y EMPEZAR CON PIPELINES ES IMPORTANTE QUE LOS DESARROLLADORES TENGAN ESCRITOS SUS TESTS.

Si los test unitarios son exitosos, el siguiente paso será correr tests de integración. Si estos también son exitosos, el artefacto (la app) que fue construido será pusheado o guardado en algún repositorio y/o "deployado" a un entorno de staging.

3. Jobs

La configuración de los pipelines empiezan con jobs, pero... que son los jobs?

Los jobs son el elemento mas fundamental de un pipeline y son ejecutados por los GitLab Runners. Son creados con restricciones que indican bajo que condiciones deben ejecutarse, a su vez son elementos de nivel superior que pueden tener un nombre arbitrario y deben contener un script como requerimiento mínimo.

Nota: Puede haber un numero ilimitado de jobs.

Ejemplo de 2 jobs

job1: 
script: "execute-this-script-for-job1" 
job2: 
script: "execute-this-script-for-job2"        

En un vistazo general de los pipelines, se pueden encontrar varios jobs. Los mismos tienen un ID, son parte de algún stage y tienen un nombre.

4. Runners

No es la idea de este articulo explicar en profundidad los runners, pero si creo que es necesario tener una idea básica de lo que es un runner y como funcionan, así que....

"… los Runners son esencialmente entornos de build que corren en una maquina separada que conecta con el servidor de GitLab y pide por los jobs a ejecutar. Los Runners ayudan a automatizar el desarrollo de productos y lograr la integración de DevOps."

Mastering GitLab 12 By Joost Evertse- Ed. Packt

Existen diferentes tipos de Runners

• Shell executor
• Docker executor
• Docker Machine executor
• Parallels executor
• VirtualBox executor
• SSH executor
• Kubernetes executor

Nota: El archivo de configuración del GitLab Runner en el cliente es nombrado config.toml.

4.1 Características de los Runners

• Los runners pueden correr múltiples jobs en concurrencia.
• Pueden usar múltiples tokens (el cliente GitLab Runner se "enlaza" con el servidor GitLab a través de un token) con múltiples servidores (incluso por proyecto)
• Tiene la capacidad de limitar el numero de jobs por token.

Los GitLab Runners que se ejecutan pueden hacer lo siguiente:

• Correr en una computadora local sin contenedores o virtualización.
• Correr dentro de los contenedores.
• Correr dentro de los contenedores y ejecutar jobs usando SSH.
• Correr usando contenedores Docker con auto-escalamiento en diferentes nubes o virtualizadores.
• Correr por conexiones a un servidor SSH remoto, donde pueden ser ejecutados.