CI/CD es una práctica que automatiza el build, las pruebas y el lanzamiento de código, para que cada cambio vaya del commit a producción en pasos pequeños. El nombre comprime dos ideas — integración continua (fusionar y verificar constantemente) y entrega continua (mantener cada cambio listo para lanzar) — más una ambigüedad famosa: la segunda “D” también puede significar deploy continuo, donde nada salvo una prueba que falla separa un commit de producción.
Puntos clave
| Pregunta | Respuesta |
|---|---|
| Qué es | Automatización que convierte el “día del release” en un no-evento que ocurre todo el tiempo |
| CI | Fusionar cambios pequeños a diario; cada merge dispara build y pruebas automáticamente |
| Las dos CD | La entrega mantiene una aprobación humana antes de producción; el deploy la elimina |
| Por qué funciona | Los cambios pequeños fallan en pequeño; el feedback rápido atrapa bugs minutos después de crearse |
| Cómo se mide | Las cinco métricas DORA — y velocidad y estabilidad suben juntas |
Cómo se ve un pipeline en la práctica
La práctica entera cabe en un archivo de configuración — este es el artefacto que toda página de “CI/CD explicado” describe y casi ninguna muestra:
# pipeline.yml — la automatización que reemplaza el "día del deploy"
on: push to main
jobs:
build:
steps:
- checkout
- run: npm ci && npm run build
test:
needs: build
steps:
- run: npm test # unitarias + integración, en cada commit
- run: npm run lint # análisis estático
deploy:
needs: test
approval: manual # borra esta línea → deploy continuo
steps:
- run: npm run deployMinutos después de que corre ese último paso, todos los clientes ya están llamando a la nueva versión del backend — que es exactamente el punto:
// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
print('API version: ${response.result}'); // fresh from the deploy
}// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
if case .success(let version) = result {
print("API version: \(version)") // fresh from the deploy
}
}// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}CI vs. entrega continua vs. deploy continuo
| Dimensión | Integración continua | Entrega continua | Deploy continuo |
|---|---|---|---|
| Alcance | Merge + build + pruebas | …más artefactos siempre listos para release | …más release automático |
| Disparador | Cada commit en la mainline | Cada build que pasa | Cada build que pasa |
| Gate humano | Ninguno (las pruebas son el gate) | Sí — una aprobación de release | Ninguno |
| Producción se actualiza | Cuando alguien lanza | Cuando alguien hace clic | Continuamente |
| Mejor para | Todo el mundo | Releases regulados, lanzamientos con fecha de marketing | Backends web, SaaS, suites de prueba de alta confianza |
El linaje merece una frase: el artículo canónico de Martin Fowler definió la CI en 2000, el libro de 2010 Continuous Delivery la extendió al proceso de release, y DevOps hizo del par su columna vertebral de automatización. Una arista afilada de Fowler todavía corta hoy: correr un servidor de build contra feature branches de vida larga es “semi-integración” — CI de verdad significa que la mainline integra el trabajo de todos al menos una vez al día.
El pipeline, etapa por etapa
- Fuente. Un commit o merge lo dispara todo. Nunca builds manuales — si no fue disparado, no es CI.
- Build. Compilar, resolver dependencias, producir el artefacto (bundle, imagen de contenedor) que todas las etapas posteriores reutilizan — build una vez, promueve en todas partes.
- Prueba. Verificaciones rápidas primero: pruebas unitarias y lint en cada commit; pruebas de integración contra dependencias reales después; end-to-end, performance y escaneos de seguridad en corridas posteriores o agendadas. La velocidad del feedback decide el orden de las etapas.
- Entrega. El artefacto aterriza en un entorno de staging parecido a producción. En la entrega continua, espera ahí — listo para release — por un sí humano.
- Deploy. Producción. Los pipelines maduros hacen deploy gradual — una tajada canary o un entorno blue/green paralelo — para que un cambio malo sea un rollback contenido, no una caída.
Cómo medirlo: las métricas DORA
“¿Somos buenos entregando?” tiene una respuesta estándar: las cinco métricas del programa de investigación DORA — frecuencia de deploy, lead time de los cambios, tasa de fallas de los cambios, tiempo de recuperación de deploys fallidos y tasa de retrabajo de deploy. El hallazgo más citado de la investigación es que el clásico trade-off velocidad-versus-estabilidad es falso: los equipos que más deploys hacen son también los que menos rompen, porque los cambios pequeños y frecuentes son individualmente de bajo riesgo y rápidos de diagnosticar. Si tu trabajo en el pipeline no mueve una de las cinco, es plomería, no progreso.
Casos de uso comunes
- Backends web y de API — el hogar natural del deploy continuo pleno: alto volumen de cambios, rollback instantáneo, ningún paso de instalación.
- Apps móviles — CI más entrega continua: el pipeline construye, prueba y prepara cada cambio, mientras la revisión de las tiendas hace que el empujón final sea inherentemente gateado.
- Equipos que crecen más allá de un único deployer — el pipeline reemplaza a la única persona que “sabe hacer el release” por un proceso que cualquiera ejecuta.
- Entornos regulados — el gate de aprobación se vuelve una feature: automatización total hasta la línea, una decisión humana auditable sobre ella.
- Proyectos open source — cada pull request construido y probado automáticamente es la CI sirviendo de puerta de entrada del proyecto.
¿Deberías mantener un gate antes de producción? Matriz de decisión
| Elige deploy continuo cuando… | Mantén el gate de entrega cuando… |
|---|---|
| La suite de pruebas tiene la confianza de producción | La cobertura de pruebas todavía está creciendo hasta merecer esa confianza |
| El rollback es un comando | El rollback es un proyecto |
| Los usuarios esperan actualizaciones invisibles y constantes | Los releases se alinean con fechas de marketing o de contrato |
| El producto es un backend web o SaaS | El producto pasa por la revisión de las tiendas de aplicaciones |
| Las fallas se degradan con gracia detrás de feature flags | Un release malo tiene consecuencias regulatorias |
La secuencia honesta: gánate el deploy practicando la entrega — automatiza todo hasta el gate, observa la tasa de fallas y quita el gate cuando ya no esté haciendo nada.
Limitaciones y trade-offs
- El pipeline es código tuyo. Runners, YAML, cachés, secrets — todo eso necesita mantenimiento, y en ciertos tamaños de equipo el pipeline se convierte en un producto propio, con guardia propia.
- Las pruebas flaky lo envenenan todo. Una suite que falla al azar entrena a la gente a hacer clic en “retry”, lo que convierte silenciosamente el deploy continuo de vuelta en deploy manual con pasos extra.
- La cultura es prerrequisito, no subproducto. Merges pequeños, desarrollo en la mainline y arreglar builds rojos de inmediato son hábitos; comprar un pipeline no los instala.
- Velocidad sin observabilidad es apostar. Hacer deploy todo el tiempo solo es seguro si ves las fallas rápido — el monitoreo y las alertas son parte de la práctica, no un agregado.
- La última milla varía. Bases de datos, migraciones y servicios stateful se resisten al “solo redeploya”; el pipeline necesita estrategias (migraciones expand-contract, feature flags) que ningún YAML escribe por ti.
CI/CD en Back4app
Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su efecto sobre el CI/CD es sustracción del lado de la entrega: Cloud Code hace deploy con un comando de CLI o directo desde un repositorio Git, y el backend estándar — base de datos, autenticación, APIs — nunca aparece en tu pipeline, porque no hay nada que buildear ni lanzar. Lo que queda es la mitad que deberías conservar: tus pruebas, corriendo en cada commit, delante de un paso de deploy que ahora tiene una sola línea.
Preguntas frecuentes
¿Qué significa CI/CD?
Continuous Integration y Continuous Delivery — integración continua y entrega continua — con una ambigüedad incorporada que todo practicante debería conocer: la "CD" también puede significar deploy continuo (continuous deployment). La entrega mantiene una aprobación humana antes de producción; el deploy la elimina. Cuando alguien dice "hacemos CI/CD", la pregunta útil siempre es: ¿cuál de las dos CD?
¿Qué es la integración continua?
La práctica de fusionar cambios pequeños en una mainline compartida con frecuencia — al menos a diario, en la definición canónica — con cada merge disparando un build y una corrida de pruebas automatizadas. El punto es el feedback rápido: los problemas de integración aparecen minutos después de crearse, y no semanas más tarde, en el apuro de un release.
¿Cuál es la diferencia entre entrega continua y deploy continuo?
Un paso de aprobación manual. En la entrega continua, cada cambio se construye, se prueba y se mantiene listo para lanzar automáticamente, pero un humano decide cuándo se actualiza producción de verdad. En el deploy continuo no hay gate: cada cambio que pasa el pipeline sale a producción automáticamente, y solo lo detiene una prueba que falla.
¿Qué es un pipeline de CI/CD?
El flujo automatizado que un cambio recorre del commit a producción: disparador en el código fuente, build, pruebas automatizadas, entrega a un entorno de staging y deploy. Cada etapa debe pasar antes de que corra la siguiente, así que el pipeline actúa como un gate de calidad que todo cambio atraviesa de la misma manera — sin casos especiales, sin heroísmos de deploy.
¿Qué son las métricas DORA?
La forma estándar de la industria de medir el desempeño de entrega, salida del programa de investigación DORA: frecuencia de deploy, lead time de los cambios, tasa de fallas de los cambios, tiempo de recuperación de deploys fallidos y — agregada más recientemente — tasa de retrabajo de deploy. El hallazgo más citado de la investigación es que velocidad y estabilidad no son un trade-off: los mejores equipos puntúan alto en ambas.
¿CI/CD es lo mismo que DevOps?
No — DevOps es la cultura más amplia de unificar desarrollo y operaciones; CI/CD es su columna vertebral de automatización. Puedes adoptar las herramientas de CI/CD sin la cultura (ayuda menos de lo que se espera) y predicar la cultura sin la automatización (cambia menos de lo que se promete). Las prácticas se refuerzan entre sí, pero nombran cosas distintas.
¿Qué pruebas corren en un pipeline de CI/CD?
En capas, por velocidad: las pruebas unitarias y el análisis estático corren en cada commit porque son rápidos; las pruebas de integración verifican componentes contra dependencias reales; end-to-end, performance y escaneos de seguridad corren en etapas posteriores o agendadas, porque son lentos. La regla de diseño: cuanto más rápido el feedback, más temprana la etapa.
¿Los equipos pequeños necesitan CI/CD?
Necesitan la práctica más que la plomería. Hasta un equipo de dos personas se beneficia de pruebas automatizadas en cada cambio y de deploys de un solo comando — eso ya es CI/CD en sustancia. Lo que los equipos pequeños deben evitar es operar infraestructura pesada de pipeline; los runners alojados o las plataformas con deploy incorporado reducen la práctica a configuración.