Verificando autenticación…

Skip to main content

Pipelines for ANDES DX

Pipelines for ANDES DX is the ANDES Platform team's solution for CI/CD in GitLab, integrating existing capabilities from Framework-1, Framework-2, and Runway under a unified, governed model.

The goal is to support the different delivery needs across the company.

Current Status​

info

Pipelines for ANDES DX is currently in development.

Principles​

The following principles were considered in its design:

  • GitLab Components as the foundation for building. This aims to use GitLab's own capabilities to the fullest, and for components to live in the same tool where they are used and be accessible to all users. For more information see: https://docs.gitlab.com/ci/components/
  • Components with unit tests. Being able to validate each component's behaviour is a valuable tool and practice when supporting, extending, fixing, or changing behaviour, since we can detect unwanted changes and strengthen the component's quality control over time.
  • Reusable components. The pieces built can be used not only by ANDES but by any LATAM developer.
  • Minimize dependencies. Prefer explicit contracts (inputs/outputs), versioned artifacts, and declared needs: over coupling via global variables or hidden conventions.
  • Single-responsibility components. Tools and processes may change; the idea is for responsibilities to be well separated, following one of the SOLID principles, so that when we need to change something, we can simply connect or disconnect a piece. For example, with Krane you can generate manifests—but what if we later want to switch to KCL or HELM? Components must be modular so that new ones can be created when needed without affecting pipeline behaviour.

Model​

Definition​

Pipelines for ANDES DX has a simple, hierarchical model for definition and organization. Services contain pipelines, and these are made up of components.

Here is a concrete example for Java:

Service​

Services represent the technology stacks in use. Examples include:

  • Java
  • Node
  • Python
  • Golang

Likewise, services contain the different pipelines that are required:

Pipeline​

Pipelines are organized by domain. This division allows pipelines to be managed according to the specific needs of each domain that uses Pipelines for ANDES DX, since they do not necessarily all have the same stages, needs, or even the same flow.

This is a simplified example of a pipeline. As you can see, it does not have a full test suite, but it helps define a base and serves as an example:

Component​

Components are the basic unit of pipelines; they correspond to the jobs that will run. They can receive different inputs and produce (or not) an output that can be used in another stage of the execution.

Components are stage-agnostic by default; the wrapper/pipeline defines stages and places each job.

Topics​

To use Pipelines for ANDES DX it is important to set topics on the project, as shown in the image:

Go Home

These define:

  • Domain
  • Technology stack
  • Information source
info

These are set automatically through ANDES DX.

How does it work?​

Currently the gitlab-ci.yml to use it can look like this:

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 ]]

We can identify:

  • Component
    • ANDES_PIPELINES GitLab variable. Reference to the base pipeline of Pipelines for ANDES DX.
    • ANDES_PIPELINES_VERSION GitLab variable. Reference to the current version of Pipelines for ANDES DX.
  • Inputs
    • release_candidate Text for the release candidate. Empty by default.
    • image_name Name of the image, corresponding to the URL where it is published in the registry. Empty by default.
    • image_tag Image commit.

With the above:

  • There is a base pipeline that serves all deployments.
  • Through topics, the service and domain for the project are identified.
  • There are different versions, and a GitLab variable holds the latest stable version.
  • This is a valid gitlab-ci.yml because the variables are defined at the GitLab level.

The ANDES_PIPELINES and ANDES_PIPELINES_VERSION variables are managed by the ANDES team. They are also declared at the LATAMAIRLINES level in GitLab configuration.

Trunk Based Development​

Pipelines for ANDES DX is based on TBD:

All branches originate from main.

warning

There are branches named master that are legacy from other systems. For GitLab it should be main.

Repositories​