Integración y entrega continuas (CI/CD)

CI (integración continua) es comprobar de forma automática cada cambio antes de integrarlo. CD (entrega o despliegue continuos) es llevar ese cambio a un entorno real sin pasos manuales. La mayoría de equipos gana más con una buena CI que con cualquier otra inversión técnica del mismo coste.

Qué comprueba la CI, y en qué orden

1. Lo más rápido primero: formato y *lint*. Falla en segundos y evita ruido en la revisión.
2. Compilación / *type-check*: si no compila, nada más importa.
3. Tests unitarios: el grueso de la confianza, deberían tardar pocos minutos.
4. Tests de integración y *end-to-end*: más lentos y más frágiles; van al final y en paralelo.
5. Build del artefacto de producción: si se prerenderiza o empaqueta, que falle aquí y no en el servidor.

Los tiempos importan más de lo que parece

Si el pipeline tarda 25 minutos, la gente deja de esperarlo: fusiona antes de que termine, acumula cambios y pierde la relación causa-efecto entre un *commit* y su fallo. El objetivo razonable es tener una respuesta de CI en menos de diez minutos. Se consigue con caché de dependencias, paralelización y no repetir trabajo entre etapas.

Gates antes de producción

Entre «la CI pasa» y «está en producción» conviene poner comprobaciones que no son código: revisión aprobada, migraciones de base de datos revisadas aparte, y una forma de volver atrás en un minuto. El despliegue debería ser aburrido; si genera adrenalina, falta automatización.

• Despliegue reproducible: el mismo artefacto que se probó es el que se publica.
• Vuelta atrás rápida: relanzar la versión anterior no puede depender de reconstruir nada.
• Salud tras el despliegue: una comprobación automática de que el servicio responde antes de dar por buena la publicación.

Entornos

Como mínimo, un entorno de integración que se parezca a producción (mismos servicios, datos anonimizados) donde probar antes de publicar. Muchos equipos se ahorran incidencias solo por tener ese entorno y usarlo de verdad.