Reglas de Pipeline

Las reglas de pipeline se activan durante CI/CD de Clarive:

• Integración Continua - se ejecutan para cada rama de topic enviada mientras el topic está En Progreso

• Nightly builds - trabajos de pipeline que se ejecutan para ramas de release cada noche

• Despliegue bajo demanda - se ejecutan en solicitudes bajo demanda del usuario para desplegar un topic a un entorno.

Para cada uno de los eventos de ejecución de CI/CD anteriores, Clarive puede iniciar uno o más eventos.

Aquí está el esqueleto de una regla de pipeline:

build:
   - ...

test:
   - ...

deploy:
   - ...

Contenidos del Job

Para cada pipeline habrá diferentes contenidos.

Clarive es un sistema multi-proyecto, multi-repositorio, lo que básicamente significa que un solo job puede desplegar muchas aplicaciones y sus componentes a la vez.

Pipeline	Contenidos
Integración Continua	Un solo proyecto, repositorio y rama de topic
Nightly Builds	Múltiples proyectos, repositorios y ramas de release
Despliegue bajo demanda	Múltiples proyectos, repositorios, releases y ramas de topic

Entorno del Job

Cada job se ejecuta contra un entorno. Los entornos se definen típicamente con letras mayúsculas.

Sus reglas de pipeline pueden llamarse desde cualquier entorno.

Para obtener el entorno actual en el que se está ejecutando su regla, use el objeto de contexto del job ctx.env()

deploy:
 - echo: "This deploy is running for environment {{ ctx.env() }}"
 - if: "{{ ctx.env() == 'PROD' }}"
   then:
   - shell:
       host: prod.server
       cmd: rm -rf /bea/user_projects/domains/yourdomain/servers/yourserver/tmp

Elementos del Job

Los elementos del job son la lista de archivos que han cambiado en comparación con el entorno actual del job.

La comparación la realiza Clarive usando la posición de la etiqueta del entorno para cada repositorio.

# no copiemos el sitio web completo cada vez

deploy:
    - foreach: "{{ ctx.job('items') }}"
      do:
         - ship:
             file: ${it}
             host: web.server
             to: /var/www/

Ejecución

Lo primero que hay que recordar es que todas las reglas de job se ejecutan en el servidor Clarive.

Antes de llegar a ejecutar rulebooks, Clarive extraerá archivos localmente. Cada op de rulebook en una regla de pipeline comenzará con todas sus ramas correctas clonadas para que no sean necesarias operaciones git.

1. Un evento de usuario activa un job. El job se pone en la cola.

2. El demonio de jobs de Clarive en el servidor Clarive recoge el job.

3. Se crea un directorio temporal.

4. Clarive clonará una copia de todos los repositorios Git localmente para que la regla tenga a su disposición todos los repositorios necesarios extraídos en su rama correspondiente y HEAD correcto.

5. Para cada repositorio de proyecto clonado, Clarive ejecutará su correspondiente rulebook clarive.yml, si lo hay.

6. Primero se ejecutan todas las reglas build. Luego todas las reglas test. Si el job está programado para un momento posterior, entra en hibernación hasta ser despertado para las reglas deploy.

Jobs programados

Los jobs bajo demanda pueden ser programados por el usuario para ejecutarse en una fecha posterior. La programación solo afecta a la regla deploy. Eso es porque la mayoría de las veces, queremos construir y probar lo antes posible, y desplegar en un momento posterior. Entonces build y test siempre se ejecutan tan pronto como los recoge la cola de jobs.

Sin embargo, la integración continua y el pipeline de nightly build no caen en la categoría de jobs programados. Los pipelines de recursos se ejecutan tan pronto como sea posible después de que el usuario envíe una rama de topic, mientras que los pipelines Nightly ejecutan todas las reglas en horario nocturno.

Eso significa que el job ejecutará las reglas build y test de inmediato y ejecutará la regla deploy en el momento programado.

Eventos disponibles

Como se mencionó antes, hay 3 eventos básicos que se activan durante un pipeline:

build:

Build se ejecuta una vez por cada repositorio en los contenidos del job.

La regla build comienza tan pronto como se crea el job y es recogido por la cola.

test:

Test se ejecuta una vez por cada repositorio en los contenidos del job, después de que todas las reglas build se hayan ejecutado con éxito.

Las reglas test existen para que podamos comenzar a probar solo después de que toda la construcción haya terminado.

deploy:

Deploy se ejecuta una vez por cada repositorio incluido en el job, al igual que build y test.

Filtrar Reglas

Puede filtrar cuándo se ejecutará su regla agregando variables de alcance en la parte superior de cada entrada de evento.

• environments
• branches

# limitar build solo a ramas feature

build:
   branches:
      - feature/*
   do:
      - cd myproj/src/
      - go build main.go

deploy:
   environments:
      - Testing
      - Staging
      - Production
   do:
      - ship:
          host: ${hostname}
          from: myproj/
          to: /opt/myproject/bin/

build_*, test_*, deploy_*

También puede crear eventos secundarios que se activarán durante su correspondiente evento primario:

# activado durante un evento build:

build_feature:
   branches:
      - feature/.*
   do:
      - g++ src/*.cpp

build_hotfix:
   branches:
      - hotfix/.*
   do:
      # construyamos más rápido
      - g++ -O0 src/*.cpp

# activado durante deploy:

deploy_feature:
   branches:
      - feature/.*
   do:
      - ...

deploy_hotfix:
   branches:
      - hotfix/.*
   do:
      - ...

O separe sus tipos de build según el entorno del job:

build_CI:
    environments:
      - Integration
    do:
      - ...

build_CD:
    environments:
      - Testing
      - Staging
      - Production
    do:
      - ...

Contexto Disponible

Con cada pipeline de job, el motor de rulebook pone a disposición un conjunto de variables de contexto útiles para importar en el job.

build:
   - dist_dir =: ".artifacts/{{ ctx.job('environment') }}/dist/"
   - mkdir -p {{ dist_dir }}
   - touch {{ dir_dist }}/{{ ctx.job('name') }}

Para obtener una lista de todas las variables de contexto, lea el artículo de documentación de datos de contexto.