Saltar a contenido

Pipelines CI/CD

InteSys diseña e implementa pipelines CI/CD que automatizan su flujo de build, test y despliegue. Nos especializamos en GitLab CI y GitHub Actions, pero soportamos cualquier plataforma CI/CD importante.

Principios de Diseño de Pipelines

Un pipeline bien diseñado debe ser:

  • Rápido — Etapas paralelas, caché y builds incrementales minimizan el tiempo de feedback
  • Confiable — Builds determinísticos con dependencias fijadas y entornos reproducibles
  • Seguro — Secretos gestionados externamente, imágenes escaneadas y ejecución con mínimos privilegios
  • Observable — Logs claros, artefactos y notificaciones de estado

GitLab CI

GitLab CI es nuestra plataforma recomendada para equipos que usan repositorios autoalojados o GitLab SaaS.

Pipeline de Ejemplo

stages:
  - test
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: "/certs"

test:
  stage: test
  image: python:3.12-slim
  script:
    - pip install -r requirements.txt
    - pytest tests/ --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
  only:
    - main

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  environment:
    name: production
  only:
    - main
  when: manual

Funciones Clave de GitLab CI

  • Docker-in-Docker — Construya imágenes de contenedores dentro de los jobs de CI
  • Artefactos y caché — Comparta archivos entre etapas y acelere los builds
  • Entornos — Rastree despliegues por entorno con soporte de rollback
  • Variables protegidas — Almacene secretos de forma segura con acceso por entorno
  • Review apps — Levante entornos temporales para la revisión de merge requests

GitHub Actions

Para equipos en GitHub, construimos workflows usando GitHub Actions con componentes reutilizables.

Workflow de Ejemplo

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Pruebas Automatizadas en Pipelines

Tipo de Prueba Etapa Propósito
Pruebas unitarias test Validar funciones y métodos individuales
Pruebas de integración test Verificar interacciones entre componentes
Linting test Hacer cumplir el estilo de código y detectar errores comunes
SAST test Análisis estático de seguridad
Escaneo de contenedores build Detectar vulnerabilidades en imágenes Docker
Smoke tests deploy Verificar la salud del despliegue tras una release

Fallar Rápido

Ejecute primero las pruebas más rápidas (linting, pruebas unitarias) para que los desarrolladores reciban feedback rápido. Mueva las pruebas más lentas (integración, escaneos de seguridad) a etapas posteriores.

Estrategias de Despliegue

Despliegue Blue-Green

Mantenga dos entornos idénticos. Despliegue en el inactivo, verifique y luego cambie el tráfico.

  • Cero downtime — El tráfico cambia instantáneamente
  • Rollback sencillo — Vuelva al entorno anterior
  • Costo — Requiere el doble de infraestructura durante el despliegue

Despliegue Canary

Dirija gradualmente un porcentaje del tráfico a la nueva versión.

  • Reducción de riesgo — Los problemas afectan solo a un pequeño porcentaje de usuarios
  • Basado en métricas — Promueva o revierta en función de tasas de error y latencia
  • Complejidad — Requiere división de tráfico (Istio, Nginx o load balancer cloud)

Rolling Update

Reemplace instancias una a una (opción por defecto en Kubernetes).

  • Eficiente en recursos — No se requiere infraestructura adicional
  • Gradual — Las versiones antigua y nueva conviven durante el rollout
  • Rollback — Kubernetes revierte automáticamente ante health checks fallidos

Próximos Pasos