Verificando autenticación…

Saltar al contenido principal

Pipelines para ANDES DX

Pipelines para ANDES DX es la solución del equipo de Plataformas ANDES para el CI/CD en Gitlab, integrando capacidades existentes de Framework-1, Framework-2 y Runway bajo un modelo unificado y gobernado.

Con lo anterior se busca darle soporte a las diferentes necesidades de entrega para toda la compañía

Estado Actual​

info

Pipelines para ANDES DX se encuentra actualmente en desarrollo

Principios​

En su concepción como solución se pensaron los siguientes principios:

  • Gitlab Components como base para la construcción, con esto se busca usar las capacidades propias de Gitlab y explotarlas al máximo, además de que vivan en la misma herramienta donde se usan, y sean accesibles a todos los usuarios. Para más información revisar: https://docs.gitlab.com/ci/components/
  • Componentes que tengan pruebas unitarias. Poder validar el comportamiento de cada componente puede ser una herramienta y práctica valiosa al momento de dar soporte, expandir, corregir, alterar el comportamiento, pues podemos detectar cambios indeseados, y a su vez poder robustecer el control de calidad del componente con el tiempo.
  • Componentes reutilizables. Las piezas que se construyan no sólo pueden ser usadas por ANDES sino que por cualquier desarrollador de LATAM.
  • Minimizar dependencias. Preferir contratos explícitos (inputs/outputs), artifacts versionados y needs: declarados sobre acoplamientos por variables globales o convenciones ocultas.
  • Componentes con responsabilidad única. Las herramientas y procesos pueden cambiar, la idea es que las responsabilidades estén bien separadas, cumpliendo con uno de los principios SOLID, para en caso de que tengamos que cambiar, pueda ser simplemente conectar/desconectar una pieza. Un ejemplo es Krane: puedo generar los manifiestos con Krane, ¿pero que pasa si luego se busca cambiar por KCL o HELM? Los componentes deben ser modulares, para poder generar nuevos en caso de necesidad y que no altere el funcionamiento del pipeline

Modelo​

Definición​

Pipelines para ANDES DX tiene un modelo simple y jerárquico para definirse, y poder organizarse donde los servicios, tienen pipelines y estos están compuestos por componentes

Si esto lo llevamos a un ejemplo concreto como sería Java

Service​

Los servicios serían los stack tecnológicos que se usan. Como por ejemplo serían:

  • Java
  • React
  • Node (proximamente)
  • Python
  • Golang

Asimismo, los servicios contendrán los diferentes Pipelines que se requieran:

Pipeline​

Los Pipelines están divididos por Dominio. Esta división permite gestionar los pipelines según las necesidades específicas de cada uno de los dominios que utilicen Pipelines para ANDES DX, dado que no necesariamente todos tengan las mismas etapas o necesidades, o incluso el mismo flujo.

Este es un ejemplo simplificado de un Pipeline. Como se puede ver, no tiene una suite de pruebas completa, pero nos ayudará a definir una base y nos servirá de ejemplo:

Component​

Los componentes es la unidad base de los pipelines, equivalen a los jobs que se ejecutarán. Estos pueden recibir diferentes inputs y generar (o no) un output que puede ser usado en otra etapa de la ejecución.

Los componentes son stage-agnostic por defecto; el wrapper/pipeline define stages y ubica cada job.

Topics​

Para poder usar Pipelines para ANDES DX es importante setear tópicos en el proyecto como se puede ver en la imagen:

Go Home

En estos se define:

  • Dominio
  • Stack Tecnológico
  • Fuente de Información
info

Estos se definen automáticamente a través de ANDES DX

¿Cómo funciona?​

Actualmente el gitlab-ci.yml para poderlo usar se puede ver así:

spec:
  inputs:
    release_candidate:
      description: "The release candidate used to deploy to prod"
      default: ""
    image_name:
      description: "The image name"
      default: ""
    image_tag:
      description: "The image tag"
      default: ""

---

include:
  - component: $ANDES_PIPELINES@$ANDES_PIPELINES_VERSION
    inputs:
      release_candidate: $[[ inputs.release_candidate ]]
      image_name: $[[ inputs.image_name ]]
      image_tag: $[[ inputs.image_tag ]]

Podemos identificar

  • Component
    • ANDES_PIPELINES Variable de Gitlab. Referencia al Pipeline base de Pipelines para ANDES DX
    • ANDES_PIPELINES_VERSION Variable de Gitlab. Referencia a la versión actual de Pipelines para ANDES DX
  • Inputs
    • release_candidate Texto correspondiente al release candidate. Por defecto vacío
    • image_name Nombre de la imagen que equivale a la url donde se publica en el registry Por defecto vacío
    • image_tag Commit de la imagen

Con lo anterior:

  • Tengo un pipeline base que sirve para todos los despliegues
  • A través de los tópicos se identifica que service y dominio son los del proyecto
  • Existen diferentes versiones, y existe una variable en Gitlab con la última versión estable
  • Este es un gitlab-ci.yml válido, pues las variables esta definidas a nivel de Gitlab

Las variables ANDES_PIPELINES y ANDES_PIPELINES_VERSION las maneja el equipo de ANDES. Así mismo están declaradas a la altura de LATAMAIRLINES en los ficheros de Gitlab

Trunk Based Development​

Pipelines para ANDES DX toma como base TBD:

Todas las ramas nacen desde main.

aviso

Existen ramas llamadas master que son legadas de otros sistemas Para Gitlab debiese ser main

Repositorios​