---
term: 'CI/CD (Integración & Entrega Continuas)'
seoTitle: '¿Qué es CI/CD? Integración y Entrega Continuas Explicadas'
headline: '¿Qué es CI/CD?'
slug: ci-cd
category: cloud-architecture
shortDefinition: '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.'
relatedTerms:
  - no-ops-development
  - containerization
  - kubernetes
  - backend-boilerplate-code
  - cloud-code-serverless-functions
contrastsWith:
  - no-ops-development
faq:
  - question: '¿Qué significa CI/CD?'
    answer: '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?'
  - question: '¿Qué es la integración continua?'
    answer: '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.'
  - question: '¿Cuál es la diferencia entre entrega continua y deploy continuo?'
    answer: '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.'
  - question: '¿Qué es un pipeline de CI/CD?'
    answer: '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.'
  - question: '¿Qué son las métricas DORA?'
    answer: '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.'
  - question: '¿CI/CD es lo mismo que DevOps?'
    answer: '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.'
  - question: '¿Qué pruebas corren en un pipeline de CI/CD?'
    answer: '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.'
  - question: '¿Los equipos pequeños necesitan CI/CD?'
    answer: '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.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Continuous Integration — Martin Fowler (updated 2024)'
    url: 'https://martinfowler.com/articles/continuousIntegration.html'
  - name: 'Continuous Delivery — Martin Fowler'
    url: 'https://martinfowler.com/bliki/ContinuousDelivery.html'
  - name: 'DORA metrics guide (dora.dev)'
    url: 'https://dora.dev/guides/dora-metrics-four-keys/'
  - name: 'CI/CD (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/CI/CD'
cta:
  title: 'Deploy sin la plomería del pipeline'
  text: 'Back4app colapsa la mitad de entrega del CI/CD: las funciones de Cloud Code salen a producción con un comando de CLI o directo desde un repositorio Git, con la base de datos, la autenticación y las APIs ya en vivo. Conserva tus pruebas; prescinde de la granja de runners.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: ci-cd
---

**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:

```yaml
# 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 deploy
```

Minutos 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:**

```javascript
// 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
// 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
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}
```

**Kotlin:**

```kotlin
// 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 |

```mermaid
flowchart LR
  accTitle: Un pipeline de CI/CD
  accDescr: Los commits disparan etapas automatizadas de build y prueba; los cambios aprobados llegan a staging y luego cruzan un gate de aprobación manual, en la entrega continua, o ningún gate, en el deploy continuo, hasta producción.
  A[Commit] --> B[Build] --> C[Pruebas automatizadas] --> D[Staging]
  D --> E{¿Aprobación manual?}
  E -- "sí — entrega continua" --> F[Producción]
  E -- "sin gate — deploy continuo" --> F
```

El linaje merece una frase: el [artículo canónico de Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html) 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](https://dora.dev/guides/dora-metrics-four-keys/) — 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.