Pre-CI: Arquitectura general del pipeline CI/CD y comprobaciones previas

📚 Serie: CI/CD y la IA: De la teoría a la práctica

Previo a la integración continua (CI) hay un conjunto de etapas que garantizan que el código que entra en la rama cumple los estándares mínimos de calidad, estilo, seguridad y mantenibilidad antes de activar el pipeline de CI/CD.

Partes de este bloque:

• Parte 1 — Arquitectura general y PR Checks ← estás aquí
• Parte 2 — CI: análisis, tests, calidad y seguridad

Índice

1. Arquitectura general del pipeline CI/CD
2. PR Checks (Pre-CI)

---

Arquitectura general del pipeline CI/CD

Antes de entrar en detalle en cada fase, conviene tener una visión de alto nivel del flujo completo. La idea general es:

En resumen:

Esta será la arquitectura completa CI/CD (Integración y Entrega Continua) que seguiremos:

---

PR Checks (Pre-CI)

Solo si el PR (pull request, solicitud de fusión de código) pasa esta fase, entra en CI. Por ello hay algunos checks (verificaciones) que es interesante que se ejecuten antes de que el pipeline CI/CD se inicie. No hay que hacer aquí nada de lo que se haría de manera completa o profunda en el CI/CD, solo tiene sentido algunos checks extremadamente rápidos o que no tengan otro sentido en otro lugar.

Este bloque es la fase previa al CI, donde:

• todo debe ser rápido (más de 1 minuto se puede considerar hasta lento)
• todo debe ser determinista
• nada debe levantar contenedores
• nada debe ejecutar builds pesados
• nada debe depender de infraestructura externa

Es la fase donde se filtra:

• código mal formateado
• PRs mal definidos
• cambios que rompen contratos
• errores triviales
• problemas de estilo
• vulnerabilidades básicas
• inconsistencias semánticas detectadas por IA

Pasos / Checks incluidos

1) Static Analysis — modo rápido

Es un análisis estático ligero, con reglas básicas y ejecución rápida.

Lo detallaremos cuando hablemos de “Static Analysis — Modo profundo”.

Es rápido y evita que código obviamente incorrecto llegue al CI.

Detecta:

• vulnerabilidades simples
• patrones peligrosos obvios
• errores de calidad básicos
• código duplicado evidente
• malas prácticas triviales

No hace:

• análisis profundo
• SAST (Static Application Security Testing, prueba de seguridad de aplicaciones estáticas) completo
• SCA (Software Composition Analysis, análisis de composición de software) completo
• análisis semántico avanzado

Ejemplos:

• SonarQube PR mode
• Semgrep light rules
• Checkmarx Express

2) Linting rápido (opcional)

Ejecución del linter en modo rápido, sin reglas pesadas.

Es opcional porque algunos equipos prefieren ejecutar el linting completo en CI, pero incluirlo en PR acelera la retroalimentación.

Detecta:

• imports no usados
• variables no usadas
• errores de estilo
• inconsistencias triviales
• problemas de formato

Ejemplos:

• ESLint (modo rápido)
• Flake8
• Checkstyle básico

3) Validación de formato (Prettier, Spotless)

Validación automática del formato del código según las reglas del equipo.

Es instantáneo y evita PRs con ruido innecesario.

Detecta:

• comillas incorrectas
• indentación incorrecta
• espacios extra
• saltos de línea inconsistentes
• formato no estandarizado

Ejemplos:

• Prettier (JS/TS)
• Spotless (Java/Kotlin)
• Black (Python)

4) Validación de convenciones (nombres, commits, PR template)

Validación automática de que el PR cumple las normas del equipo.

Evita PRs mal definidos, difíciles de revisar o sin contexto.

Valida:

• nombre del PR
• formato del commit (Conventional Commits)
• etiquetas obligatorias
• descripción obligatoria
• checklist del PR template
• referencia a ticket Jira

Ejemplos:

• commitlint
• Danger.js
• GitHub Actions con reglas personalizadas

5) Validación de OpenAPI/gRPC (si aplica)

Validación de que los cambios en la API cumplen el contrato.

Es rápido y evita romper a otros equipos antes de entrar en CI.

Valida si:

• cumplen el contrato
• no rompen compatibilidad
• siguen las reglas del equipo
• no introducen breaking changes (cambios incompatibles)

Detecta:

• cambios no documentados
• rutas nuevas sin especificación
• cambios incompatibles en modelos
• errores en el schema

Ejemplos:

• OpenAPI Diff
• gRPC Contract Validator
• Spring Cloud Contract (modo stub)

6) Tests unitarios rápidos (opcional)

Ejecución de una selección de tests unitarios rápidos, sin levantar contexto pesado.

Es opcional porque algunos equipos prefieren ejecutar todos los unit tests en CI, no en PR.

Detecta:

• errores triviales
• regresiones simples
• fallos en lógica pura

Se recomienda en:

• repos grandes
• PRs frecuentes
• equipos con alta rotación

7) IA Pre‑Review (opcional)

Una revisión automática del PR realizada por IA, antes de la revisión humana.

Es opcional porque depende de la madurez del equipo y de la política de adopción de IA.

Aporta:

• explica cambios
• detecta inconsistencias
• sugiere mejoras
• identifica riesgos
• propone refactors
• detecta duplicación semántica
• revisa nombres, patrones y estilo

No hace:

• aprobar el PR
• sustituir la revisión humana
• ejecutar tests

Tabla comparativa de PR Checks

---

En el siguiente artículo, “CI (Integración Continua): análisis, tests, calidad y seguridad”, exploraremos en detalle las etapas del CI —desde el linting y la compilación hasta el análisis estático profundo, los tests (unitarios, de integración y de servicio), la cobertura, el Quality Gate y los escaneos de seguridad— y el papel que puede jugar la IA en cada una.