Introducción: Despliegues fríos y cálidos en CI/CD. En este artículo explicamos la diferencia entre despliegue frío y despliegue cálido, cómo varían los despliegues en aplicaciones web tradicionales frente a microservicios, y presentamos pasos prácticos y comandos para realizar cada estrategia en entornos de producción.

Conceptos clave: Despliegue frío: detener la aplicación, desplegar el nuevo artefacto y volver a arrancar; los usuarios experimentan tiempo de inactividad. Despliegue cálido: desplegar sin detener el servicio, con downtime mínimo o nulo. Entender tiempos de inactividad, rollback y riesgos es crítico en producción.

Despliegue frío en aplicaciones web tradicionales. Escenario: desplegar un archivo WAR en Tomcat. Pasos prácticos: 1 Detener Tomcat: sudo systemctl stop tomcat 2 Reemplazar WAR: cp /tmp/app.war /opt/tomcat/webapps/app.war 3 Iniciar Tomcat: sudo systemctl start tomcat 4 Verificar salud: curl -f http://web1:8080/app/health || echo Deployment failed Notas: mientras Tomcat está parado los usuarios no acceden a la app. El tiempo de inactividad depende del arranque de la aplicación. Es sencillo pero arriesgado en producción.

Despliegue cálido en aplicaciones tradicionales. Escenario: Tomcat Manager. Pasos prácticos: 1 Subir nuevo WAR sin parar el servidor con curl -u admin:password -T target/app.war http://web1:8080/manager/text/deploy?path=/app&update=true 2 Verificar: curl -f http://web1:8080/app/health Notas: el servidor permanece en línea, sin downtime. Riesgos: fugas de memoria por classloader o pérdida de sesión. Alternativa robusta: usar actualizaciones rolling detrás de un balanceador de carga; sacar una instancia del balanceador, desplegar, probar y reincorporarla.

Despliegue frío en microservicios. Escenario: Docker Compose. Pasos prácticos: 1 Detener servicios: docker-compose -f docker-compose.prod.yml down 2 Descargar imágenes: docker-compose -f docker-compose.prod.yml pull 3 Levantar servicios: docker-compose -f docker-compose.prod.yml up -d 4 Probar endpoints: curl -f http://microservice:8080/health Notas: todos los contenedores se detienen antes de arrancar los nuevos, por lo que hay tiempo de inactividad. Útil para despliegues de pequeña escala pero no recomendado en entornos críticos.

Despliegue cálido en microservicios. Escenario: Docker Swarm con rolling update. Pasos prácticos: 1 Construir y publicar imagen: docker build -t registry/myapp:v2 . y docker push registry/myapp:v2 2 Actualizar servicio con estrategia rolling: docker service update --image registry/myapp:v2 --update-parallelism 1 --update-delay 10s myapp_service 3 Monitorizar: docker service ps myapp_service Notas: las tareas se actualizan una a una manteniendo el servicio en línea. Baja afectación a usuarios y buena opción para microservicios.

Despliegue cálido en Kubernetes. Rolling update por defecto. Estrategia típica: maxUnavailable 1 y maxSurge 1. Pasos prácticos: 1 Construir y publicar imagen: docker build -t registry/myapp:2.0 . y docker push registry/myapp:2.0 2 Actualizar despliegue: kubectl set image deployment/myapp myapp=registry/myapp:2.0 --record 3 Monitorizar rollout: kubectl rollout status deployment/myapp y kubectl get pods -l app=myapp -w Notas: los nuevos pods deben pasar readiness probes antes de terminar los antiguos, lo que permite cero downtime. Rollback sencillo: kubectl rollout undo deployment/myapp

Blue Green. Concepto: ejecutar simultaneamente la version antigua blue y la nueva green y cambiar el trafico a green tras validarla. Pasos: desplegar myapp-green con etiqueta version=green, realizar pruebas funcionales y si todo va bien cambiar el selector del servicio: kubectl patch svc myapp -p {spec:{selector:{version:green}}} Si hay problemas revertir selector a blue. Pros: rollback instantaneo y minimo impacto. Contras: requiere recursos duplicados mientras coexisten ambas versiones.

Canary. Concepto: liberar la nueva versión a un porcentaje reducido de usuarios y aumentar gradualmente si no aparecen errores. Ejemplo con Ingress: anotar la regla canary y ajustar canary-weight a 10 para probar con 10 por ciento de trafico. Monitorizar logs y metrica y aumentar el porcentaje. Requiere controlador Ingress o service mesh como Istio o Linkerd para mayor control.

Comparativa breve: Downtime: despliegue frio si, despliegue calido no o minimo. En aplicaciones tradicionales el despliegue frio implica parar el servidor, reemplazar el artefacto y arrancar. El despliegue calido puede usar Tomcat Manager o rolling updates con balanceador. En microservicios el despliegue frio detiene contenedores y levanta otros; el despliegue calido usa rolling, blue green o canary. Rollback: en frio es redeploy manual, en caliente es facil y automatizable. Riesgo: frio alto por downtime, calido bajo si se usan probes y automatizacion.

Buenas practicas: siempre usar readiness y liveness probes. Mantener servicios stateless cuando sea posible. Usar feature flags para activar o desactivar funcionalidades sin redeploy. Seguir el patron expand contract para migraciones de base de datos. Monitorizar metricas de despliegue y hacer rollback si se supera un umbral de errores. Ejecutar smoke tests antes de enrutar trafico. Centralizar logs con ELK o EFK para facilitar troubleshooting.

Pipeline CI CD recomendado para despliegues calientes en Kubernetes. Flujos tipicos: 1 Checkout del repositorio 2 Compilar y ejecutar tests unitarios 3 Construir imagen Docker y etiquetarla con hash de commit 4 Push de imagen al registry 5 Actualizar deployment en Kubernetes con kubectl set image y esperar a kubectl rollout status 6 Ejecutar pruebas de humo y en caso de fallo ejecutar kubectl rollout undo Notas: versionar imagenes evita confusiones; usar namespaces separados para staging y produccion; automatizar rollback en el pipeline garantiza seguridad operacional.

Ejemplo de comandos utiles: git clone origen, mvn clean package -DskipTests para construir, docker build -t registry.example.com/myapp:COMMIT y docker push registry.example.com/myapp:COMMIT para distribuir imagenes, kubectl set image deployment/myapp myapp=registry.example.com/myapp:COMMIT --record, kubectl rollout status deployment/myapp --timeout=120s, kubectl rollout undo deployment/myapp para revertir. Integrar comprobaciones de salud con curl -f http://myapp.example.com/health para validar antes de finalizar el pipeline.

Opciones avanzadas: implementar blue green creando myapp-green y cambiando el selector del servicio tras pruebas; implementar canary controlando porcentaje de trafico con Ingress o service mesh y escalando gradualmente; combinar feature flags y pruebas automatizadas para reducir riesgos.

Conclusión: Los despliegues fríos son simples pero conllevan tiempo de inactividad y riesgos para usuarios. Los despliegues cálidos permiten actualizaciones con downtime minimo o nulo y son el estandar en entornos CI CD modernos, especialmente en arquitecturas de microservicios y Kubernetes. La verdadera ingenieria se centra en desplegar de forma segura y fiable, no solo rapida.

Sobre Q2BSTUDIO: Q2BSTUDIO es una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, inteligencia artificial y ciberseguridad. Diseñamos soluciones cloud y ofrecemos servicios cloud aws y azure, servicios de inteligencia de negocio y proyectos con power bi para mejorar la toma de decisiones. Además desarrollamos soluciones de ia para empresas, agentes IA y automatizacion de procesos que integran seguridad y escalabilidad. Si necesita crear una aplicacion a medida visite nuestra pagina de aplicaciones a medida y si busca migrar o desplegar en la nube conozca nuestros servicios cloud aws y azure. Contacte con Q2BSTUDIO para una estrategia de despliegue CI CD segura y adaptada a su negocio.