Continuous deployment

En el Radar compartido: Adopt (valoración de la edición aportada).

Cómo funciona

El pipeline convierte cambios pequeños en artefactos identificables y aplica controles antes de promoverlos. La decisión rutinaria de desplegar se automatiza; los equipos conservan la capacidad de detener el flujo o recuperar el servicio.

Ejemplo: recorrido de una entrega

Commit integrado
  → Pruebas y controles de seguridad
  → Construcción de un artefacto versionado
  → Despliegue progresivo con observación
  → Promoción automática o interrupción según los resultados

Las comprobaciones posteriores al despliegue forman parte del proceso. Tener un job que publica sin pruebas suficientes no representa por sí solo esta práctica con garantías operativas.

Delivery frente a deployment

Práctica	Qué significa
Integración continua	Cada cambio se integra y verifica en la rama principal
Continuous delivery	Cada cambio queda listo para producción; desplegar es una decisión de negocio (un botón)
Continuous deployment	Cada cambio que supera los controles se despliega sin intervención humana

Continuous deployment exige que los controles automáticos sean la fuente de confianza; la aprobación manual desaparece del camino habitual.

Estrategias de despliegue

Estrategia	Cómo	Recuperación
Rolling	Reemplazar instancias poco a poco	Desplegar la versión anterior
Blue/green	Dos entornos completos, se cambia el tráfico de golpe	Volver al entorno anterior, inmediato
Canary	Pequeño porcentaje a la nueva versión, ampliando con evidencia	Retirar el tráfico de la canary (1% canary)
Dark launch + toggles	Código desplegado y desactivado, se activa por cohortes	Apagar el toggle (feature toggles)

Promoción automática con Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - analysis:
            templates: [{ templateName: tasa-errores }]
        - setWeight: 25
        - pause: { duration: 15m }
        - analysis:
            templates:
              [{ templateName: tasa-errores }, { templateName: latencia-p95 }]
        - setWeight: 100

Si un análisis falla, el rollout se aborta y el tráfico vuelve a la versión estable. En Cloud Run se logra lo mismo moviendo porcentajes de tráfico entre revisiones desde el pipeline.

Migraciones de base de datos compatibles

El despliegue continuo exige que dos versiones del código convivan con el mismo esquema. Patrón expand and contract:

1. Expandir: añadir la columna nueva (nullable) sin tocar la antigua.
2. Desplegar código que escribe en ambas y lee de la antigua.
3. Migrar los datos existentes en segundo plano.
4. Desplegar código que lee de la nueva.
5. Contraer: eliminar la columna antigua en un despliegue posterior.

Cada paso es un despliegue independiente y reversible. Ver PostgreSQL para operaciones sin bloqueo.

Prerrequisitos y métricas

Trunk-based development, suite automática fiable, observabilidad con SLO, recuperación probada y cultura de postmortems sin culpa. Mide el efecto con las métricas DORA: debería aumentar la frecuencia y reducir el lead time sin empeorar la tasa de fallos.

En sectores regulados

La segregación de funciones no exige una aprobación manual en cada despliegue: la revisión obligatoria del pull request por otra persona, controles automáticos auditables y la evidencia del pipeline suelen satisfacer el requisito (continuous compliance). Acuerda el enfoque con auditoría antes de cambiar el proceso.

Criterios de implementación

Mantén lotes pequeños, migraciones compatibles y mecanismos de recuperación probados. Establece qué señales detienen la promoción y quién responde. Comienza por un servicio cuyo riesgo puedas gestionar y mejora la calidad del flujo antes de aumentar la frecuencia.