En la entrada anterior vimos a grandes rasgos de qué trata la integración continua. En esta entrada, entonces, vamos a enfocar nuestros esfuerzos en entender un pequeño ejemplo paso a paso. Vamos a partir de un proyecto en el cual ya tengamos un sistema de construcción establecido con un manejador de paquetes como NPM. Además, ya escribimos las pruebas pertinentes para asegurarnos que nuestro proyecto funciona como esperamos. Lo primero que debemos hacer es crear un archivo en la raíz de nuestro proyecto llamado .gitlab-ci.yml.
Algunos conceptos importantes que debes saber para dominar esta primera etapa:
- Gitlab runner: El runner es el encargado de correr el código que se encuentra en el script de CI que vamos a escribir.
- Script: El script está compuesto por una serie de stages y se encuentra en nuestro archivo llamado .gitlab-ci.yml. Este es traducido en pipelines de ejecución los cuales el runner se encarga de calendarizar y correr.
- Stage: Los stages definen las etapas que queremos que se ejecuten. Las más comunes son build, test y deploy.
- Job: Los jobs son un grupo de comandos que se ejecutan secuencialmente para llevar a cabo una tarea específica como la construcción del proyecto o la aplicación de pruebas.
- Step: Son los comandos que componen un job.
Lo primero que tenemos que hacer cuando escribimos un script de CI es seleccionar una imagen sobre la cual queremos que corra el código que estamos escribiendo. Cuando hablamos de imágenes nos referimos a imágenes de Docker, estas son utilizadas por los runners.
# Imagen con node
image: node:12.20
# Definimos las etapas
stages:
- build
- test
- deployEn el código anterior estamos especificando una imagen que contenga la versión 12.20 de node. También se puede seleccionar node:latest para obtener la última versión de node. Luego definimos las etapas de ejecución que vamos a seguir, build, test y deploy.
# Construimos el proyecto
build_project:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
En el extracto de código anterior tenemos la sección de construcción del proyecto. Le indicamos al runner que estamos en un job llamado build_project que contiene una etapa de build en la cual instalamos las dependencias del proyecto, estas se almacenan en node_modules. Con la palabra clave artifacts hacemos que las dependencias que instalamos puedan ser utilizadas por otras etapas e inclusive se almacenen temporalmente en el repositorio y puedan ser descargadas. Ahora veamos la etapa de pruebas.
# Pruebas al proyecto
test_project:
stage: test
services:
- mongo:latest
variables:
MONGODB_HOST_TEST: 'mongo'
script:
- npm run test
En el extracto anterior estamos ejecutando la etapa de pruebas. Ya no es necesario construir el proyecto de nuevo ya que de eso nos encargamos en la etapa anterior. En este caso era necesario una conexión a MongoDB por lo que le indicamos al runner que es necesario utilizar un servicio llamado mongo y queremos la última versión de este con :latest. Como pueden sospechar también se utiliza una imagen de Docker para esto. El nombre del host que utiliza el servicio de mongo es por defecto mongo por lo que para correr las pruebas en este ambiente vamos a asignar a la variable MONGODB_HOST_TEST de nuestro proyecto el nombre mongo. También es posible configurar las variables de ambiente del servicio que estamos utilizando. En la última sección corremos el comando npm run test el cual ejecuta las pruebas previamente escritas.
Finalmente vamos a presentar una última etapa en donde desplegamos la documentación de nuestro proyecto en un servicio de Gitlab llamado pages.
# Desplegar documentación a pages
pages:
stage: deploy
before_script:
- npm install
script:
- npm run docs
- mkdir public
- cp -r docs/html/* public
artifacts:
paths:
- public
only:
- developEn este último extracto vamos a introducir varios conceptos nuevos. El primero es el uso del job llamado pages el cual está reservado para hacer un despliegue a este servicio de Gitlab. Aquí vamos a alojar nuestra documentación. El segundo es el uso de before_script para definir los pasos que debe de seguir el job. También existe la palabra clave after_script. Y el último es el uso de la palabra clave only.
En este job estamos primero indicando que corresponde a una etapa de deploy. Luego nos aseguramos de construir el proyecto con el uso de before_script. Una vez construido el proyecto, construimos la documentación del mismo. En este caso el comando npm run docs es un alias para:
jsdoc -c ./docs/docs.json -t ./node_modules/better-docs
Para documentar código de JavaScript en Klooid utilizamos JSDoc, y en algunas ocasiones un template llamado better-docs.
Una vez construida la documentación la copiamos en un directorio llamado public y lo hacemos accesible a Gitlab con la palabra clave artifacts. Si dejamos nuestro código hasta este punto estaríamos corriendo el job llamado pages en cada push al repositorio remoto, sin embargo, en ocasiones vamos a querer correr ciertos jobs solo ante acciones específicas. Una manera de controlar esto es utilizando la palabra clave only. En el ejemplo propuesto sólo se realiza el despliegue a pages cuando se realizan commits a la rama de develop.
Conclusión
Las herramientas de CI/CD de Gitlab permiten que estemos continuamente probando nuestros proyectos en ambientes de prueba y producción. Además, podemos ir algunos pasos más adelante y configurar un despliegue continuo y automático de nuestro proyecto ante diferentes situaciones como commits a la rama master. Algunos de los beneficios de utilizar esta herramienta incluyen:
- Mayor velocidad de innovación y capacidad para competir en el mercado.
- El código en producción genera dinero en lugar de estar en una cola esperando ser implementado
- Código y operaciones de mayor calidad debido a la especialización
- Gran capacidad para atraer y retener talento
¡Estén atentos a nuevo contenido en el blog con más consejos y herramientas para convertirnos en mejores desarrolladores!
Enlaces de interés: