Entornos en GitLab CI/CD: ¿Cómo manejar tus despliegues?

Entornos en GitLab CI/CD: ¿Cómo manejar tus despliegues?

¿Qué son los entornos (environments) de GitLab?

Hasta ahora hemos visto las siguientes fases de CI.

Build (Construcción) -> Code Quality (Calidad del Código) -> Tests (Pruebas) -> Package (Empaquetamiento)

Y de producción solo hemos analizado un escenario en donde el despliegue se hace directamente a prod (producción), sin embargo en un entorno de trabajo real tenemos mas ambientes para la revisión de un proyecto.

¿Qué son los environments (entornos)?

  • Los environments nos permiten controlar el proceso de CD (continuous delivery/deployment).
  • Mantiene un monitoreo sencillo de los deployments.
  • Se conoce exactamente que ha sido desplegado y en que ambiente.
  • Se tiene un historial completo de los deployments.
  • Podemos etiquetar nuestros procesos.

Ahora vamos a extender nuestro CD para tener una capa de staging (staging) y otra de producción (prod), para ello expandimos el bloque stages, de forma que tengamos…

  • build
  • test
  • deploy staging
  • deploy production
  • test production

Actualizamos los nombres en los stages que hemos cambiado y realizamos una copia de production que renombramos como staging.

image: node

stages:
    - build
    - test
    - deploy staging
    - deploy production
    - test production

cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
        - node_modules/

build website:
    stage: build
    script:
        - npm i
        - npm i -g gatsby-cli
        - gatsby build
        - sed -i "s/%%VERSION%%/$CI_COMMIT_SHORT_SHA/" ./public/index.html
    artifacts:
        paths:
            - ./public

test index:
    stage: test
    script:
        - grep "Gatsby" "./public/index.html"

deploy staging:
    stage: deploy staging
    script:
        - npm i -g surge
        - surge --project ./public --domain dominio-staging-static.surge.sh

deploy production:
    stage: deploy production
    script:
        - npm i -g surge
        - surge --project ./public --domain dominio-static.surge.sh

test deployment:
    image: alpine
    stage: test production
    script:
        - apk add --no-cache curl
        - curl -s "https://dominio-static.surge.sh/" | grep -q "Hi people"
        - curl -s "https://dominio-static.surge.sh/" | grep -q "$CI_COMMIT_SHORT_SHA"

Es importante es que staging tenga su propio dominio para que no se reescriban entre si los stages staging y production.

Para etiquetar cada uno de los ambientes utilizamos el rótulo environment.

deploy staging:
    stage: deploy staging
    environment:
        name: staging
        url: https://dominio-staging-static.surge.sh
    ...

deploy production:
    stage: deploy production
    environment:
        name: production
        url: https://dominio-static.surge.sh
    ...

Empujamos los cambios para permitir que la pipeline realice sus operaciones.

Para poder ver el monitoreo de cada uno de los entornos en GitLab nos dirigimos a Deployments / Environments, aquí podremos abrir cada uno de las direcciones url en donde se han desplegado cada uno de los ambientes así como la información de cuando y que ambiente ha sido desplegado.