Pipeline de CI/CD · Mapas mentales
Pipeline de CI/CD. Un mapa mental editable con ramas de colores, ideas secundarias y conexiones. Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
CI/CD automatiza el camino desde un commit hasta producción: la integración continua compila y prueba cada cambio, y la entrega continua lo empaqueta y lo despliega a través de puertas que deciden si la versión está lo bastante sana para quedarse.
Pipeline de CI/CD · Mapas mentales
El lienzo interactivo de MindMap de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este mapa mental
- Empieza por el tema central y sigue una rama de color para explorar sus ideas.
- Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Commit & build
Esta rama reúne “Developer commits code”, “CI server builds the application”.
Verify
Esta rama reúne “Unit and integration tests run”, “The gate is what makes it CI: a commit that fails a test or a security scan never reaches the registry, let alone production.”, “Build failed — fix and recommit”.
Package
Esta rama reúne “Package the artifact and push to the registry”.
Release
Esta rama reúne “Deploy to staging and run smoke tests”, “Deploy to production”.
Observe & recover
Esta rama reúne “Deployment is not the end of the pipeline: error rates, latency and availability metrics decide whether the release stays.”, “Release is live and monitored”, “Roll back to the last good version”.
Conexiones entre ramas
La CI es la puerta previa a cualquier publicación: compila y prueba cada commit, y rechaza los fallos en el origen.
El artefacto del registro se construye una vez y se ejecuta en todas partes: la reproducibilidad del despliegue depende de ello.
Preproducción demuestra el artefacto en un entorno parecido a producción antes de que producción lo vea.
La salud posterior al despliegue es la puerta de verdad: quien decide si una versión se queda es la monitorización, no el script de despliegue.
Un pipeline sin rollback no es seguro de automatizar; el lienzo dibuja el rollback como un camino de primera clase.
Relaciones clave y conclusiones
- La CI es la puerta previa a cualquier publicación: compila y prueba cada commit, y rechaza los fallos en el origen.
- El artefacto del registro se construye una vez y se ejecuta en todas partes: la reproducibilidad del despliegue depende de ello.
- Preproducción demuestra el artefacto en un entorno parecido a producción antes de que producción lo vea.
- La salud posterior al despliegue es la puerta de verdad: quien decide si una versión se queda es la monitorización, no el script de despliegue.
- Un pipeline sin rollback no es seguro de automatizar; el lienzo dibuja el rollback como un camino de primera clase.
Cuándo usar este diagrama
- Enseñar a un equipo la diferencia entre integración continua y entrega continua antes de que construya un pipeline.
- Diseñar un pipeline: las dos puertas dicen dónde tiene que parar la automatización y dónde empieza el criterio humano (o el rollback).
- Auditar un pipeline existente: una puerta de salud que falta es una versión publicada sin decisión.
Cómo funciona
Adapta el tema central
Cambia el nombre del tema para adaptarlo a tu proyecto o clase.
Desarrolla las ramas
Edita las ideas y añade ejemplos o notas.
Conecta ideas relacionadas
Dibuja conexiones entre ramas; usa flechas cuando la dirección importe.
Preguntas frecuentes
¿Cuál es la diferencia entre CI y CD?
La integración continua (CI) es la práctica de compilar y probar cada commit de forma automática, para que los problemas salgan a la luz en el momento en que se introducen y no al publicar. La entrega continua (CD) toma la salida de CI y automatiza su camino hasta el despliegue (empaquetado, preproducción, publicación) con puertas que deciden cuándo es seguro. La CI es la primera puerta del pipeline; la CD es todo lo que viene después.
¿Por qué son importantes las puertas en un pipeline de CI/CD?
Porque la automatización elimina los puntos de control humanos que antes detectaban los problemas. Las puertas del pipeline los sustituyen por decisiones: la puerta de pruebas detiene una build fallida antes de publicarla y la puerta de salud detiene una mala versión después de publicarla. Por eso el diagrama dibuja ambas como rombos de decisión: un pipeline solo es tan fiable como sus puertas.
¿Qué es un rollback y por qué lo necesita el pipeline?
Un rollback es devolver el sistema a la última versión buena conocida cuando una publicación falla después del despliegue. Los pipelines lo necesitan porque las comprobaciones de salud son imperfectas y producción puede comportarse mal de formas que preproducción nunca mostró. Un rollback automático es lo que permite a los equipos desplegar con frecuencia: el coste de una mala versión pasa a ser una reversión, no un incidente.
¿Qué papel juega el registro de artefactos?
El registro es donde vive, con su versión, el artefacto construido por el pipeline. Todas las etapas posteriores (preproducción, producción, rollback) despliegan exactamente ese artefacto del registro, nunca una recompilación. Eso es lo que hace que el código desplegado sea idéntico al código probado, y también lo que hace seguro el rollback: la última versión buena sigue en el registro.
Editar este mapa mental en QueryChart
Abre este mapa mental en un lienzo editable. Mueve ideas, añade ramas y dibuja conexiones.