¿Qué es CI/CD? Integración y entrega continuas explicadas de forma sencilla

CI/CD es una forma de publicar software en la que cada cambio de código se compila, se prueba automáticamente y, si pasa, se prepara para publicarse o se publica. CI (integración continua) significa que los cambios se fusionan a menudo y se comprueban con pruebas automáticas cada vez. CD (entrega o despliegue continuo) significa que los cambios que pasan se empaquetan y se envían hacia tus usuarios con poco o ningún trabajo manual.

La idea es sencilla: detectar los errores minutos después de cometerlos, no semanas después, cuando un cliente los encuentra.

Por qué importa CI/CD cuando construyes con IA

Los constructores de apps con IA hacen cambios de código muy rápido. Un solo prompt puede tocar diez archivos. Esa velocidad es estupenda hasta que un cambio en la página de pago rompe en silencio la página de inicio de sesión y nadie se da cuenta hasta que un usuario te escribe.

CI/CD es la red de seguridad justo para eso. En lugar de confiar en que cada cambio está bien, un pipeline ejecuta las mismas comprobaciones cada vez:

• ¿La app sigue compilando sin errores?
• ¿Siguen pasando las pruebas automáticas?
• ¿El código cumple las reglas del proyecto (tipos, formato, controles de seguridad)?

Si alguna comprobación falla, el cambio se detiene antes de llegar a los usuarios. Cuanto más rápido cambia tu código, más valiosa es una comprobación que nunca se cansa ni se salta un paso.

Una analogía cotidiana

Piensa en una panadería que vende pan a las tiendas cada mañana.

• Sin CI/CD, cada panadero trabaja durante una semana en sus propios ajustes de receta, y el viernes por la noche todos combinan sus cambios y esperan que el pan siga subiendo. Cuando no sube, nadie sabe qué cambio lo causó.
• Con CI, cada pequeño cambio de receta se hornea enseguida en una barra de prueba y se comprueba: sabor, peso, forma. Un mal cambio se detecta el mismo día, y sabes exactamente cuál fue.
• Con CD, las barras que pasan la inspección van directamente a la furgoneta de reparto, empaquetadas y etiquetadas siempre igual, en lugar de que alguien empaquete cajas a mano a las 5 de la mañana.

La inspección no hace mejores a los panaderos. Hace que sus errores salgan baratos.

Cómo funciona un pipeline de CI/CD

Un pipeline es una lista de pasos que un servicio de CI/CD ejecuta automáticamente cuando ocurre algo, normalmente cuando alguien sube código a un repositorio como GitHub. Un pipeline típico tiene este aspecto:

Cada paso se ejecuta en una máquina limpia, no en el portátil de alguien, así que «en mi ordenador funciona» deja de ser una excusa. Si un paso falla, el pipeline se detiene y avisa a quien hizo el cambio.

Los pasos se definen en un archivo de configuración que vive junto al código. En GitHub Actions, por ejemplo, es un archivo YAML en la carpeta .github/workflows del repositorio.

Entrega continua vs despliegue continuo

La «CD» es ambigua, y la gente la usa de las dos formas:

El despliegue continuo solo funciona bien si las pruebas son buenas. Si tus pruebas no cubren el pago, el despliegue continuo publicará con gusto un pago roto.

Ejemplo práctico: una app de reservas con un pipeline

Supongamos que tienes una app de reservas para un salón de belleza, y su código está en un repositorio de GitHub. Pides a un constructor de apps con IA que «añada un 10% de descuento para clientes que vienen por primera vez».

1. El cambio se sube a una rama nueva y se abre una pull request.
2. El pipeline arranca. Instala paquetes y compila la app: pasa.
3. Ejecuta las pruebas. Una, «un cliente que vuelve paga precio completo», falla: el descuento se está aplicando a todos.
4. La pull request muestra una cruz roja. El cambio no puede fusionarse.
5. Pides a la IA que lo corrija. Sube una corrección; el pipeline vuelve a ejecutarse y todo pasa.
6. El cambio se fusiona. El pipeline lo despliega en un entorno de staging, donde haces una reserva de prueba.
7. Lo apruebas, y se despliega en producción.

Sin el pipeline, el paso 3 habría ocurrido en el bolsillo de tus clientes.

Términos clave

Conceptos erróneos habituales

• «CI/CD significa que mi app está probada». Un pipeline solo ejecuta las pruebas que tengas. Si no hay pruebas, CI solo demuestra que la app compila, nada más. Pide a tu IA que escriba pruebas para los flujos más importantes.
• «CI/CD es solo para grandes empresas». Herramientas alojadas como GitHub Actions se configuran con un archivo corto, y los equipos pequeños las usan constantemente. El esfuerzo está en las pruebas, no en la herramienta.
• «El despliegue automático significa que nadie revisa nada». Los buenos pipelines añaden comprobaciones, no las quitan. Muchos equipos mantienen un paso de aprobación humana antes de producción.
• «Si el pipeline está en verde, la app funciona». Significa que las comprobaciones automáticas pasaron. Aun así, deberías probar el cambio tú mismo, idealmente en una vista previa o en staging.
• «CI/CD sustituye a las copias de seguridad». No es así. Una migración de base de datos que pasa las pruebas puede dañar datos reales. Mantén copias de seguridad y una forma de volver atrás.

Qué pedir a tu constructor de apps con IA

• «Escribe pruebas automáticas para el registro, el inicio de sesión y el pago, y muéstrame cómo ejecutarlas.»
• «Configura un workflow de GitHub Actions que instale dependencias, compile la app y ejecute las pruebas en cada pull request.»
• «Añade una comprobación de tipos y un linter al pipeline, y haz que falle si hay errores.»
• «Explica en lenguaje sencillo qué hace cada paso del pipeline.»
• «¿Qué pasa si un despliegue falla a medias? ¿Cómo vuelvo atrás?»
• «Comprueba que no haya secretos escritos en el repositorio ni impresos en los logs del pipeline.»

Si tu app usa claves de API, el pipeline también las necesita, guardadas como secretos cifrados en la herramienta de CI, nunca en el archivo de configuración. Consulta variables de entorno y secretos.

CI/CD y Mythex

Mythex no ejecuta un pipeline de CI por ti, pero cubre varias de las mismas necesidades a su manera:

• Checkpoints. Tras cada turno exitoso del agente, Mythex guarda un checkpoint de git, y Volver a este punto revierte el proyecto si un cambio salió mal. Consulta Chat.
• App Testing. Escribe /test y el agente recorre tu vista previa en vivo como lo haría un usuario y te informa de los flujos rotos, útil antes de cada publicación. Consulta App Testing.
• Publicar es un paso deliberado. Los cambios aparecen primero en la vista previa privada; tu app pública solo se actualiza cuando vuelves a publicar: más cerca de la entrega continua que del despliegue continuo.
• Sincronización con GitHub (Pro). Sincroniza el proyecto con un repositorio de GitHub y podrás añadir tus propios workflows de GitHub Actions para ejecutar pruebas en cada subida. Consulta GitHub y exportación.

Para una lista de comprobación de lo que conviene probar a mano antes de salir en directo, consulta cómo probar tu app antes del lanzamiento, y para trabajar con control de versiones, cómo usar Git con una app construida con IA.

Preguntas