Automatiza tus entregas con confianza: desde artefactos reproducibles en remoto y en Jenkins local hasta staging y producción, el foco está en reducir errores y lanzar más frecuente con decisiones informadas. Aquí verás cuándo aplicar Continuous Delivery o Continuous Deployment y cómo usar Blue/Green, Canary deployments y Rolling para un flujo estable.

¿Qué diferencia hay entre Continuous Delivery y Continuous Deployment?

El pipeline es el mismo: pruebas unitarias, build, deployment stage en staging, pruebas de aceptación y decisión de ir a producción. La diferencia está en el último paso.

• En Continuous Deployment se envía a producción automáticamente según los resultados de los acceptance tests.
• En Continuous Delivery puedes interceder y decidir manualmente si desplegar o no.

Recomendación práctica del instructor: depende del contexto. Si el cambio es crítico y no hay plena seguridad, no lo hagas automático: intercede. Puedes integrar otras prácticas para ganar confianza y, luego, automatizar más.

¿Cuál es el objetivo común de estos enfoques?

• Menos errores en producción.
• Lanzamientos más frecuentes con control.
• Los implementation details importan menos que el resultado: menos fallos.

¿Qué estrategias de deployment reducen errores con monitoreo?

Elige la forma de desplegar según el riesgo y tu capacidad de monitorear. Las favoritas del instructor permiten revertir rápido y observar impacto sin interrumpir el tráfico.

• Blue/Green: mantén dos stacks del mismo código. A sirve tráfico; B recibe update. Cuando B está bien, redirige tráfico vía DNS o load balancer a B. A queda pasivo esperando update. Es potente porque el deployment es, en teoría, inmutable: si hay error, lo ves de inmediato y vuelves a A con seguridad.
• Canary deployments: con un pool de nodos (por ejemplo, tres), modifica solo uno o dos y monitorea el tráfico y el cambio riesgoso. Si “rompe”, solo afecta una fracción del tráfico. Quita el nodo de rotación y listo. Se puede combinar con Blue/Green y con Rolling.
• Rolling: con un set de máquinas, actualiza una, sales, pasas a la siguiente, y así sucesivamente. Puede ser en paralelo, pero todas a la vez no es tan seguro. Ventaja: puedes monitorear el progreso por porcentaje de máquinas actualizadas. Si los errores incrementan, solo afectas el subconjunto actualizado y puedes hacer rollback o sacarlas de rotación.

¿Cómo decidir qué usar en cada caso?

• Si necesitas revertir en segundos: Blue/Green.
• Si el cambio es riesgoso y quieres impacto limitado: Canary deployments.
• Si buscas control gradual y visibilidad continua: Rolling.
• Puedes combinarlas para más seguridad.

¿Con qué herramientas o prácticas puedes implementar estos deployments?

Se puede hacer a mano de forma sencilla, especialmente Blue/Green. Si ya estás en un nivel más avanzado, hay herramientas probadas en la industria.

• A mano: útil para comprender y controlar el flujo.
• Herramientas: Go por go.cd y Spinnaker hecho por Netflix. Son complejas, pero vale evaluarlas si tu operación lo requiere.

¿Qué habilidades y keywords prácticas se refuerzan?

• Artefactos reproducibles: base para despliegues consistentes.
• Jenkins local y repositorio remoto: soporte del pipeline automatizado.
• Staging y acceptance tests: puerta de calidad antes de producción.
• Blue/Green: dos stacks, DNS/load balancer, inmutabilidad y reversión rápida.
• Canary deployments: pool de nodos, monitoreo de tráfico, impacto acotado.
• Rolling: actualización por lotes, medición de errores por porcentaje, rollback.
• Implementation details: lo importante es el resultado: menos errores.
• Decisión manual vs automática: interceder cuando el cambio es crítico.
• Spinnaker y Go: opciones avanzadas cuando el contexto lo justifica.

¿Tienes dudas sobre tu contexto y qué estrategia aplicar? Comenta tu escenario y los riesgos que ves para explorar una combinación adecuada.