Pipelines de CI/CD y estrategias de despliegue

Del commit a producción: para qué sirve un pipeline

La Sección 0.8 (cómo se hace el software) presentó la integración continua (cada cambio se fusiona y se verifica automáticamente), la entrega continua (la rama principal está siempre lista para lanzarse) y el despliegue continuo (cada cambio que supera las comprobaciones pasa a producción sin una decisión humana). Esta sección los trata como arquitectura: el diseño del camino que sigue un cambio y las estrategias que lo llevan a producción sin perjudicar a los usuarios.

La idea central es el pipeline de despliegue, descrito por Jez Humble y David Farley en Continuous Delivery (2010). Cada commit desencadena una secuencia automatizada de etapas. Las primeras etapas son rápidas y baratas y detectan la mayoría de los problemas; las posteriores son más lentas, más realistas y más caras. Un cambio pasa a la siguiente etapa solo si la anterior se superó, de modo que cuanto más avanza una compilación, más confianza se ha ganado. Un fallo en cualquier punto detiene esa compilación y vuelve directamente a la persona que hizo el cambio, mientras aún lo tiene fresco en la mente.

El pipeline importa a los arquitectos por tres razones. Primero, es donde la desplegabilidad, un atributo de calidad de la sección 2.6, se logra o se pierde de verdad. Segundo, su velocidad limita la rapidez con la que la organización puede responder a un cambio del mercado o a una vulnerabilidad de seguridad: si una corrección de una línea tarda dos días en llegar a producción, la arquitectura tiene dos días de lentitud, se vea como se vea el código. Tercero, la forma del sistema condiciona la forma del pipeline: los servicios desplegables de forma independiente pueden tener pipelines independientes, pero un monolito distribuido obliga a lanzamientos coordinados por muy ingeniosas que sean las herramientas.

Build once, deploy many y el repositorio de artefactos

Una regla de Continuous Delivery que se sigue incumpliendo con sorprendente frecuencia es build once, deploy many (compilar una vez, desplegar muchas): compila y empaqueta cada cambio exactamente una vez y luego promueve ese mismo artefacto por todos los entornos. Si un equipo recompila para staging y otra vez para producción, lo que probó no es lo que entregó. Un parche distinto del compilador, una dependencia resuelta durante la noche a una versión más reciente o una imagen base cambiada pueden hacer que las dos compilaciones difieran, y las pruebas no demuestran nada sobre la segunda.

Lo que cambia entre entornos es la configuración, proporcionada en el momento del despliegue o del arranque (direcciones de bases de datos, credenciales, ajustes de los feature flags), nunca incorporada al artefacto. Es el factor de configuración de la aplicación de doce factores. Una imagen de contenedor etiquetada orders:4f1c2ab (el hash del commit) se despliega en pruebas, staging y producción; solo cambian sus variables de entorno y los secretos montados.

El repositorio de artefactos es el almacén entre la compilación y el despliegue: un registro de contenedores (Amazon ECR, Azure Container Registry, Google Artifact Registry, GitHub Container Registry, Harbor) o un repositorio universal como JFrog Artifactory o Sonatype Nexus para paquetes y binarios. Trátalo como infraestructura crítica. Despliega por digest inmutable (sha256:...) en lugar de por una etiqueta mutable como latest, que puede moverse para apuntar a otra imagen; conserva los artefactos que están o estuvieron en producción durante todo el tiempo que puedas necesitar volver a ellos o investigarlos; y registra la procedencia, es decir, qué commit, qué ejecución del pipeline y qué dependencias produjeron cada artefacto.

Desarrollo basado en trunk y lotes pequeños

La forma de usar las ramas decide con qué frecuencia se integra realmente el código. En el desarrollo basado en trunk (trunk-based development) todos integran cambios pequeños en una única rama principal (el trunk) al menos una vez al día, ya sea haciendo commit directamente o mediante ramas de corta duración y pull requests que viven horas, no semanas. El programa de investigación DORA ha asociado repetidamente las ramas de corta duración y las fusiones frecuentes con un mayor rendimiento de entrega, y es una condición previa para la integración continua en sentido literal: el código que pasa tres semanas en una rama no se está integrando de forma continua.

Las ramas de funcionalidad de larga duración parecen más seguras porque el trabajo sin terminar se mantiene aparte, pero el riesgo solo se aplaza: cuanto más divergen dos ramas, mayor y más arriesgada es la fusión final, y más tiempo ve el pipeline un código que no es el que se va a entregar. GitFlow, un modelo de ramas con ramas develop y release de larga duración publicado por Vincent Driessen en 2010, se adoptó ampliamente; en 2020 Driessen añadió una nota según la cual los equipos que entregan de forma continua, como los de aplicaciones web, deberían considerar un flujo de trabajo más sencillo. Los equipos que sí necesitan trabajar en cambios grandes en el trunk usan dos técnicas: los feature flags, que ocultan el comportamiento sin terminar, y branch by abstraction, que introduce una interfaz delante de la implementación antigua, construye la nueva detrás de ella y hace el cambio cuando está lista.

Los profesionales discrepan de verdad en los extremos. Los proyectos de código abierto con muchos colaboradores no fiables dependen de pull requests más largos y de la revisión, y los equipos regulados a veces necesitan ramas de lanzamiento explícitas para la auditoría. El principio que sobrevive al desacuerdo es el tamaño del lote: cuanto más pequeño es cada cambio, más fácil es revisarlo, probarlo, desplegarlo, diagnosticarlo y deshacerlo.

name: delivery
on:
  push:
    branches: [main]
env:
  IMAGE: registry.example.com/food/orders:${{ github.sha }}
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make lint test              # fast feedback first
      - run: docker build -t "$IMAGE" . && docker push "$IMAGE"
  staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh staging "$IMAGE" && ./smoke-test.sh staging
  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production            # can require an approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh production "$IMAGE" --canary 5

Estrategias de despliegue

Una estrategia de despliegue decide cómo sustituye la nueva versión a la antigua en producción y, por tanto, a cuántos usuarios puede perjudicar una versión defectuosa antes de que se detenga. Las estrategias difieren en la infraestructura adicional que necesitan, en la rapidez del rollback y en si se ejecutan dos versiones a la vez. Siempre que se ejecutan dos versiones a la vez, deben ser compatibles con los datos y los mensajes de la otra, y ese es el precio de todas las estrategias salvo la recreación.

Martin Fowler describió el despliegue azul-verde en 2010, atribuyéndolo a Dan North y Jez Humble; el lanzamiento canario, llamado así por los canarios que llevaban los mineros para detectar gas, lo documentó Danilo Sato en el mismo sitio en 2014. En Kubernetes, las actualizaciones graduales vienen integradas; los lanzamientos azul-verde y canario suelen venir de un controlador de entrega progresiva (Argo Rollouts, Flagger) o de un service mesh y del enrutamiento ponderado de la Gateway API. En las plataformas gestionadas, las funciones equivalentes se llaman división del tráfico (traffic splitting) o ranuras de despliegue (deployment slots).

Separar el despliegue del lanzamiento con feature flags

El despliegue instala una nueva versión del software en un entorno; el lanzamiento pone un comportamiento a disposición de los usuarios. Tratarlos como un solo acontecimiento convierte cada despliegue en un acontecimiento de negocio, con todo el nerviosismo que eso conlleva. Los feature flags (feature toggles) los separan: el código nuevo se despliega desactivado, y el comportamiento se lanza más tarde, de forma gradual y reversible, cambiando la configuración. El artículo de Pete Hodgson Feature Toggles (aka Feature Flags) en martinfowler.com (2017) distingue cuatro categorías según cuánto tiempo viven y con qué dinamismo deciden.

Los flags tienen un costo de mantenimiento. Cada flag duplica los caminos por el código que protege, añade combinaciones de prueba y deja código muerto una vez que su decisión está tomada. Hodgson recomienda tratar los flags como un inventario: añadir una tarea de eliminación cuando se crea un toggle de lanzamiento, dar a los flags fechas de caducidad, añadir pruebas que fallen cuando un flag ha pasado su fecha y limitar cuántos pueden existir a la vez. La pérdida de Knight Capital en 2012, descrita en la sección 1.3, tuvo que ver con un flag reutilizado que reactivó código antiguo en un servidor que se había saltado un despliegue manual: un recordatorio de no reutilizar nunca los nombres de los flags y de borrar el código muerto que hay detrás de los flags ya decididos. A escala, los flags los sirve un servicio dedicado (opciones de código abierto como Unleash y Flagsmith, comerciales como LaunchDarkly, o la API neutral respecto al proveedor OpenFeature) para que un cambio se propague en segundos y quede auditado.

Cambios de base de datos en el pipeline

El código se puede revertir en segundos; los datos, no. Un despliegue que renombra una columna y luego se revierte deja al código antiguo frente a un esquema que no entiende. La solución, tratada en profundidad en evolución de esquemas, es hacer que cada cambio de esquema sea compatible hacia atrás con la versión del código que se está ejecutando, usando expandir y contraer: añade primero la nueva estructura, despliega código que escriba en ambas y lea de cualquiera, rellena los datos (backfill), cambia los lectores y elimina la estructura antigua solo en un lanzamiento posterior, cuando ya nada la use.

En el pipeline, esto significa que las migraciones son artefactos versionados que se ejecutan como un paso propio, antes de desplegar el código que las necesita, y que se prueban con una copia de los datos del tamaño de producción, para que un bloqueo en una tabla grande se descubra en staging y no a la hora de comer. Los pasos destructivos (eliminar columnas o tablas) se retrasan y se ejecutan por separado, porque son el único tipo de cambio que un rollback no puede deshacer. Una comprobación útil del pipeline hace fallar la compilación cuando una migración no es aditiva, salvo que esté marcada explícitamente como paso de contracción.

Entrega progresiva y análisis canario automatizado

La entrega progresiva, un término popularizado por James Governor, de la firma de análisis RedMonk, en 2018, combina canarios, feature flags y verificación automatizada: un cambio llega a públicos cada vez mayores y, en cada paso, es el sistema, no una persona que mira paneles, quien decide si continuar. La decisión usa el análisis canario automatizado: las métricas del canario (tasa de errores, percentiles de latencia, saturación, señales de negocio como los pedidos realizados) se comparan estadísticamente con una línea base. Netflix y Google publicaron como código abierto su motor de análisis, Kayenta, en 2018; Argo Rollouts y Flagger ofrecen pasos de análisis similares en Kubernetes.

Tres detalles deciden si se puede confiar en el análisis. Compara lo comparable: una línea base nueva de la versión antigua que recibe la misma parte del tráfico evita culpar a la nueva versión de diferencias causadas por cachés frías o reinicios recientes. Ten suficiente tráfico: con el 5% de un servicio que atiende diez solicitudes por minuto, una hora de canario ve treinta solicitudes, demasiado pocas para detectar una tasa de errores del 1%, así que los servicios con poco tráfico necesitan pasos más largos, carga sintética o una estrategia distinta. Elige métricas ligadas a los objetivos de nivel de servicio y a los resultados de negocio, porque una versión puede ser rápida y no tener errores mientras cobra en silencio una tarifa de envío incorrecta.

Rollback o roll forward

Cuando un lanzamiento sale mal, hay dos salidas. El rollback vuelve al artefacto anterior, lo que es rápido y no necesita código nuevo, siempre que la versión anterior siga funcionando con los datos actuales y con las versiones de los demás servicios. El roll forward (corrección hacia adelante) entrega una corrección a través del pipeline, lo que es más lento, pero a veces es la única opción, por ejemplo tras una migración de datos que no se puede revertir o un cambio del que ya dependen otros servicios.

Un buen criterio por defecto es revertir primero, diagnosticar después: restablece el servicio con la acción segura más rápida y luego investiga sin presión. Corregir hacia adelante bajo presión tiende a saltarse las comprobaciones del pipeline, y una corrección precipitada de un incidente en producción es una fuente clásica del siguiente incidente. El rollback solo es una opción real si se diseña desde el principio: conservar los artefactos anteriores, hacer que los cambios de esquema sean compatibles en ambas direcciones durante al menos una versión, que los mensajes los puedan leer consumidores antiguos y nuevos, y ejercitar con regularidad el propio camino de rollback. Un equipo que nunca ha hecho un rollback debería suponer que no puede hacerlo.

Medir el pipeline

Las métricas DORA de entrega de software presentadas en la sección 2.6 (tiempo de entrega de los cambios, frecuencia de despliegue, tasa de fallos de los cambios, tiempo de recuperación de un despliegue fallido y tasa de retrabajo de despliegues) son en gran medida propiedades del pipeline y de la arquitectura en conjunto. Los lotes pequeños y el desarrollo basado en trunk acortan el tiempo de entrega y aumentan la frecuencia; las pruebas automatizadas y el análisis canario reducen la tasa de fallos de los cambios; el rollback rápido y los flags acortan el tiempo de recuperación. Mídelas por servicio, observa las tendencias en lugar de valores aislados y nunca las conviertas en objetivos individuales, lo que solo invita a manipularlas.