Imagina dos equipos de desarrollo.
El primer equipo prepara una nueva versión de la aplicación.
El programador termina una tarea. Alguien revisa el código. Luego hay que ejecutar las pruebas. Alguien prepara el paquete. Otra persona inicia sesión en el servidor. Después hay que realizar varias acciones manuales, comprobar la configuración y observar el sistema tras el despliegue. Si todo sale bien, la nueva versión queda disponible.
El segundo equipo trabaja de otra manera.
El código llega al repositorio. Automáticamente se ejecutan las pruebas, el análisis de calidad y los controles de seguridad. El sistema compila la versión de la aplicación, la despliega en el entorno de pruebas, realiza comprobaciones adicionales y, tras cumplir determinadas condiciones, puede desplegarla en producción. Si algo sale mal, el despliegue se detiene o el sistema puede volver a la versión anterior.
Ambos equipos crean software.
Pero solo uno de ellos ha construido un proceso repetible de entrega de software.
Y justamente de eso trata CI/CD.
"Funciona en producción" todavía no es un proceso maduro
Muchas empresas miden el éxito con una métrica muy simple: la aplicación funciona.
Por supuesto, ese es el requisito básico.
Pero a medida que el sistema crece, surgen nuevas preguntas:
- ¿Con qué rapidez podemos desplegar una corrección?
- ¿Con qué frecuencia podemos publicar nuevas funciones?
- ¿Cuántas acciones manuales realizamos en cada despliegue?
- ¿Puede cada desarrollador iniciar el proceso de despliegue siguiendo las mismas reglas?
- ¿Sabemos qué versión está funcionando actualmente?
- ¿Somos capaces de volver a la versión anterior?
- ¿Después del despliegue comprobamos automáticamente que el sistema funciona correctamente?
- ¿Tenemos monitorización?
- ¿Sabemos que el despliegue causó un problema antes de que lo reporte el cliente?
Estas son preguntas sobre software delivery, y no solo sobre la programación en sí.
CI y CD: dos elementos de un solo proceso
CI, es decir Continuous Integration, significa integración continua de cambios.
En la práctica, se trata de que los cambios lleguen con frecuencia al repositorio compartido y se verifiquen automáticamente.
Un pipeline típico puede ejecutar, entre otras cosas:
-
compilación o construcción de la aplicación,
-
pruebas unitarias,
-
pruebas de integración,
-
linting,
-
análisis estático de código,
-
escaneo de dependencias,
-
controles de seguridad,
-
creación de artefactos de despliegue.
Gracias a ello, el problema puede detectarse antes de que el código llegue a producción.
CD, es decir Continuous Delivery o Continuous Deployment, se refiere a la siguiente etapa: la entrega de cambios.
Según el modelo adoptado, el sistema puede preparar una versión lista para desplegar o desplegarla automáticamente después de pasar ciertos controles.
Esta distinción es importante.
Continuous Delivery no tiene por qué significar el despliegue automático de cada cambio en producción.
Puede significar simplemente que cada versión se prepara de forma repetible para su despliegue.
¿Por qué los despliegues manuales se convierten en un problema?
Un despliegue manual no tiene por qué ser malo.
En un proyecto pequeño puede ser perfectamente suficiente.
El problema empieza cuando el proceso crece junto con la aplicación.
Primero tenemos a una persona que sabe cómo desplegar el sistema. Luego aparece un segundo servidor. Después el entorno de pruebas. Más tarde, la base de datos, la caché, las colas, el almacenamiento, varios servicios y APIs externas. A eso se suman distintas configuraciones para desarrollo, pruebas y producción.
Después de unos años, el proceso puede parecer algo así:
"Primero ejecuta X, luego cambia el parámetro Y, después reinicia el servicio Z, pero antes haz una copia de la base de datos. Y si aparece un error, llama a la persona que lo desplegó la última vez."
Eso ya no es un proceso. Es conocimiento oculto en la cabeza de una persona. Y precisamente entonces el riesgo aumenta.
La automatización no sirve solo para la comodidad de los desarrolladores
A menudo se presenta CI/CD como una herramienta que mejora la comodidad de los desarrolladores. Es cierto, pero solo es una parte de la historia.
La automatización de delivery sobre todo aumenta la repetibilidad del proceso.
Si el despliegue lo realiza una persona, existe la posibilidad de que cada vez haga algo un poco distinto.
Si lo hace un pipeline, se puede definir una secuencia exacta de pasos.
La misma versión.
Las mismas pruebas.
Los mismos controles.
Las mismas reglas.
Esto es especialmente importante en proyectos desarrollados por varias personas o varios equipos.
Las pruebas antes del despliegue son más importantes que la velocidad del despliegue
La automatización sin pruebas puede hacer únicamente que los errores aparezcan más rápido.
Por eso, un pipeline bien diseñado no debería ser solo un mecanismo: "código → producción".
Debería ser un sistema de control de calidad.
Según el proyecto, puede incluir:
- Pruebas unitarias - comprueban elementos individuales de la lógica.
- Pruebas de integración - comprueban la colaboración entre componentes.
- Pruebas end-to-end - simulan escenarios reales de usuario.
- Pruebas de seguridad - comprueban, entre otras cosas, dependencias y vulnerabilidades conocidas.
- Pruebas de rendimiento - necesarias donde es importante soportar una carga determinada.
No todas las aplicaciones necesitan todas estas capas en la misma medida.
Y eso es importante.
CI/CD no consiste en meter la mayor cantidad posible de herramientas en el pipeline.
Se trata de elegir los controles adecuados para el riesgo de un sistema concreto.
¿Qué ocurre cuando una prueba falla?
Esta es una de las preguntas más importantes de todo el proceso.
Un pipeline maduro debería tener reglas claramente definidas.
Si una prueba crítica falla, la versión no debería considerarse lista para desplegarse.
Si un escaneo de seguridad detecta un cierto nivel de riesgo, el pipeline puede detener el proceso.
Si la compilación falla, no hay nada que desplegar.
Suena trivial. Pero precisamente estas "barreras" automáticas hacen que la calidad no dependa solo de la memoria y la precisión de una persona.
¿Y si aun así el despliegue falla?
Incluso el mejor proceso no elimina todos los errores. Por eso el segundo elemento de un delivery maduro es la posibilidad de revertir el cambio de forma controlada.
Rollback puede significar volver al artefacto anterior, a la imagen del contenedor o a la versión de la aplicación. Pero aquí aparece un problema importante. El rollback del código no siempre significa rollback de los datos.
Si la nueva versión ha cambiado la estructura de la base de datos, la situación se vuelve más complicada.
Por eso, las migraciones de bases de datos deben diseñarse de forma que todo el proceso sea lo más seguro y reversible posible, o al menos compatible con la versión anterior de la aplicación.
Este es uno de los ejemplos que muestran que el CI/CD profesional es un problema arquitectónico y no solo una configuración de herramienta.
Blue-green, canary y otras estrategias de despliegue
En sistemas más exigentes no es necesario cambiar de inmediato a todos los usuarios a la nueva versión. Se pueden aplicar distintas estrategias de deployment.
Blue-green deployment
Hay dos versiones del entorno en funcionamiento.
Una gestiona el tráfico, la otra se prepara para asumirlo.
Tras una verificación positiva, se realiza el cambio.
La ventaja es la posibilidad de volver rápidamente al entorno anterior.
La desventaja puede ser un mayor consumo de infraestructura.
Canary deployment
La nueva versión llega primero a una pequeña parte de los usuarios o del tráfico.
Si el monitoreo no muestra problemas, el alcance del despliegue puede aumentarse gradualmente.
Esto limita el alcance potencial del error.
Sin embargo, requiere la infraestructura, el monitoreo y la forma de gestionar el tráfico adecuados.
Feature flags
Una funcionalidad puede desplegarse en el sistema, pero permanecer desactivada para los usuarios.
Así, el despliegue del código y la activación de la funcionalidad se convierten en dos procesos separados.
Esto ofrece un mayor control, especialmente en cambios grandes.
Sin embargo, esto no significa que las feature flags sean una solución para todos los proyectos. Su exceso también puede aumentar la complejidad del sistema.
Monitoreo después del despliegue
Se pueden realizar todas las pruebas. Se puede tener un pipeline excelente. Se puede desplegar una nueva versión sin ningún error. Y unos minutos después, la aplicación puede empezar a comportarse de forma diferente bajo la carga real.
Por eso, el proceso no debería terminar con el deploy. Se necesita observability, es decir, la capacidad de entender qué sucede dentro del sistema en ejecución.
Dependiendo de la arquitectura, incluye entre otras cosas:
-
logs,
-
métricas,
-
tracing,
-
monitoreo de infraestructura,
-
monitoreo de la aplicación,
-
alertas,
-
información sobre errores,
-
indicadores de negocio.
No se trata de recopilarlo todo. Se trata de poder responder a las preguntas importantes basándose en los datos.
¿La aplicación funciona?
¿Funciona más lento que antes?
¿Ha aumentado el número de errores?
¿Qué servicio está generando el problema?
¿El problema afecta a todos los usuarios o solo a una parte?
100 despliegues al día no siempre son el objetivo
El título de este artículo habla de 100 despliegues al día, pero no se trata de establecer esa cifra como objetivo.
En un sistema interno actualizado una vez al mes no tiene sentido perseguir artificialmente cientos de deployments. En un sistema desarrollado de forma muy intensiva, esa frecuencia puede ser técnicamente posible.
Lo clave es la capacidad de entregar cambios de forma segura, no la cantidad de despliegues en sí. Esa es una diferencia fundamental.
La madurez del proceso no se mide por la frecuencia con la que desplegamos, sino por lo predeciblemente y seguro que podemos hacerlo.
¿Cuándo CI/CD puede ser una complicación innecesaria?
No toda aplicación necesita una infraestructura de deployment complicada.
Si tenemos una aplicación pequeña, un equipo reducido y unos pocos despliegues al año, un pipeline complejo puede costar más que los problemas que resuelve.
Lo mismo ocurre en sistemas muy específicos, donde el despliegue requiere control manual por motivos de seguridad, regulación o por la naturaleza de la infraestructura.
Por eso, la arquitectura de delivery debe surgir de las necesidades del sistema. No de las modas.
¿Cuándo la automatización de despliegues aporta especialmente mucho?
Conviene considerarla especialmente cuando:
-
el sistema se desarrolla regularmente,
-
varias personas trabajan sobre el código,
-
existe más de un entorno,
-
los despliegues son frecuentes,
-
los despliegues manuales generan errores,
-
el sistema tiene importancia crítica para el negocio,
-
necesitamos rollback rápido,
-
la aplicación tiene muchos componentes,
-
se requieren auditorías o trazabilidad de cambios,
-
el tiempo de entrega de funcionalidades tiene importancia para el negocio.
En tales casos, un pipeline bien diseñado puede ser uno de los elementos más importantes del proceso de desarrollo de software.
CI/CD no arregla una mala arquitectura
Esto también conviene subrayarlo.
Se puede crear un gran pipeline para una mala aplicación.
Probar automáticamente código malo.
Desplegar automáticamente una mala arquitectura.
Escalar automáticamente un sistema mal diseñado.
La automatización, por tanto, no sustituye la arquitectura, las pruebas ni la competencia del equipo.
Potencia el proceso existente.
Si el proceso es bueno, ayuda a escalarlo.
Si el proceso es malo, simplemente puede hacer más rápido las cosas malas.
¿Cómo es un proceso maduro?
No existe un único pipeline universal.
Pero un proceso maduro debería tener varias propiedades básicas.
Repetibilidad - el despliegue se realiza según pasos definidos.
Automatización - las máquinas ejecutan la mayor parte posible del trabajo repetitivo.
Testabilidad - los cambios se verifican automáticamente.
Seguridad - el proceso incluye los controles de seguridad adecuados.
Observabilidad - después del despliegue se sabe qué está ocurriendo con el sistema.
Reversibilidad - existe una forma planificada de responder a un cambio fallido.
Trazabilidad de cambios - se sabe qué versión se desplegó y a partir de qué se creó.
Control de acceso - no cualquiera puede desplegar lo que quiera a producción.
Precisamente de estos elementos surge un proceso profesional de software delivery.
El cambio más importante comienza con una pregunta distinta
Las empresas suelen preguntar: "¿Qué tan rápido podemos crear esta funcionalidad?"
Vale la pena añadir una segunda pregunta: "¿Qué tan rápido y de forma segura podremos entregar las siguientes 50 funcionalidades?"
Porque un único despliegue se puede hacer manualmente. Incluso se puede desplegar una aplicación manualmente durante varios años. Pero a medida que crecen el producto, el equipo, el número de usuarios y el número de cambios, también aumenta el coste de ese enfoque.
Por eso, CI/CD, las pruebas automáticas, el monitoreo y los deployments controlados no son solo soluciones para grandes corporaciones.
Son elementos de la infraestructura del proceso que permiten desarrollar software sin añadir riesgo innecesario a cada cambio posterior.
Y, al final, de eso se trata.
No de 100 despliegues al día.
No de herramientas de moda.
No se trata del pipeline más complicado.
Sino de poder decir:
"Tenemos un cambio. Lo hemos comprobado. Sabemos qué vamos a desplegar. Sabemos cómo vigilarlo. Y sabemos qué haremos si algo sale mal."
