Arquitectura CI/CD — Wiedii
El sistema CI/CD de Wiedii es centralizado y gestionado por el equipo de Infraestructura. Los repositorios de desarrollo no contienen configuraciones de pipeline — todo el CI/CD vive en un repo dedicado de infra y se conecta a cada proyecto desde GitLab.
Modelo general
┌─────────────────────────────────────────────────────────────┐
│ gitlab.wiedii.co │
│ │
│ ┌─────────────────┐ ┌──────────────────────────┐ │
│ │ Repo del dev │ │ Repo CI/CD de Infra │ │
│ │ (tu código) │ │ <<REPO_CI_INFRA>> │ │
│ │ │ │ │ │
│ │ ❌ Sin │ ────▶ │ Pipelines, templates, │ │
│ │ .gitlab-ci.yaml│ │ stages, variables │ │
│ │ │ (1) │ │ │
│ └─────────────────┘ └──────────────────────────┘ │
│ │ │ │
│ │ Settings → CI/CD │ (2) dispara │
│ │ (apunta al repo de infra) ▼ │
│ │ ┌──────────────────────┐ │
│ └──────────────────▶│ GitLab CI Orchestr. │ │
│ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
(3) conectores remotos
│
┌─────────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────── ───────────┐ ┌────────────────┐
│ Servidor CI │ │ Servidor CI │ │ Servidor CI │
│ (imágenes │ │ (compilaciones) │ │ (otros jobs) │
│ Docker) │ │ │ │ │
└─────────────────┘ └──────────────────┘ └────────────────┘
(1) La configuración CI de cada proyecto se configura en GitLab → Settings → CI/CD → General pipelines → CI/CD configuration file, apuntando al repo de infra. El repo del dev no tiene .gitlab-ci.yaml.
(2) Cuando hay un push/MR, GitLab lee la configuración desde el repo de infra y orquesta el pipeline.
(3) El servidor de GitLab no ejecuta los jobs directamente. Usa conectores remotos a servidores CI especializados según el tipo de tarea (build de imágenes, compilaciones, etc.).
Repositorio CI/CD de Infra
| Campo | Valor |
|---|---|
| Repo | <<REPO_CI_INFRA>> |
| Dueño | Equipo de Infraestructura |
| Acceso dev | Solo lectura — los cambios se solicitan al equipo de Infra |
Importante: los desarrolladores no modifican este repo directamente. Para pedir cambios en el pipeline de un proyecto, crear un request en Squadlinx dirigido al equipo de Infraestructura.
¿Qué hace el equipo de desarrollo con CI/CD?
✅ Lo que SÍ hace un dev
- Consultar el estado del pipeline en GitLab (commits, MRs, ramas)
- Interpretar los logs cuando un job falla para identificar si el problema es del código o del pipeline
- Solicitar cambios o nuevas etapas al equipo de Infra cuando el proyecto lo necesita — mediante un request en Squadlinx
- Respetar las variables de entorno y secretos que Infra configura a nivel de proyecto en GitLab → Settings → CI/CD → Variables
❌ Lo que NO hace un dev
| Acción | Por qué |
|---|---|
Crear o modificar .gitlab-ci.yaml en el repo | La config CI vive en el repo de infra |
| Añadir runners propios al proyecto | Los runners están gestionados por Infra |
| Modificar el repo CI de infra sin autorización | Es territorio de Infra — cambios coordinados |
Almacenar secrets en el código o en .env commiteados | Los secrets van en GitLab → Settings → CI/CD → Variables |
Servidores remotos de CI
El servidor de GitLab no ejecuta jobs pesados localmente. Para tareas como build de imágenes Docker o compilaciones, el orquestador de GitLab delega a servidores CI remotos especializados via conectores.
Esto significa:
- El servidor de GitLab mantiene baja carga (solo orquestación)
- Cada tipo de job puede correr en hardware optimizado para esa tarea
- Los devs no necesitan preocuparse por los detalles del runner — si el job corre, corre en el servidor correcto
Los detalles de infraestructura de los servidores CI remotos (hostnames, capacidades, mantenimiento) son responsabilidad exclusiva del equipo de Infra.
Flujo de un pipeline típico
Push / MR abierto
│
▼
GitLab lee config desde <<REPO_CI_INFRA>>
│
├─▶ Stage: lint / test
│ └─▶ Runner remoto ejecuta
│
├─▶ Stage: build imagen Docker
│ └─▶ Servidor especializado en imágenes
│
├─▶ Stage: deploy a staging
│ └─▶ Runner remoto ejecuta
│
└─▶ Stage: deploy a producción (solo en main, manual)
└─▶ Runner remoto ejecuta
Los stages exactos y condiciones dependen de cada proyecto y son configurados por Infra.
Cómo pedir cambios en el pipeline
Si tu proyecto necesita un nuevo stage, una variable de entorno, o cualquier cambio en el comportamiento del CI:
- Crear un request en Squadlinx dirigido al equipo de Infra, describiendo: qué necesitas, para qué proyecto, en qué rama/stage
- Infra evalúa si aplica al repo de infra central o es configuración de proyecto
- Infra implementa y notifica
- Verificar en el próximo pipeline que el cambio funciona correctamente
Variables de entorno y secretos
Los secretos (tokens, passwords, keys de API) nunca van en el código ni en archivos commiteados. Se configuran en:
GitLab → Proyecto → Settings → CI/CD → Variables
El equipo de Infra gestiona las variables de proyectos. Si un servicio necesita una nueva variable, solicitarla al equipo de Infra con:
- Nombre de la variable (ej.
DATABASE_URL) - Para qué entorno aplica (staging / producción / todos)
- Si debe ser Protected y/o Masked
Ver también la política de seguridad en security-scanners para el manejo de credenciales en código.
Referencias
- ci-caching — referencia de caching en pipelines (uso para equipo de Infra)
- security-scanners — escáneres de seguridad integrados al pipeline
- branch-protection — cómo las reglas de rama se conectan con el pipeline (require passing CI)
- git-flow — el flujo de ramas que dispara los pipelines