8.6 Gestión de lanzamientos y entrega progresiva

Presentación y motivación

La idea más útil en la gestión de lanzamientos moderna también es la más simple: enviar código y exponer una función son dos eventos distintos, y deberías poder hacer uno sin el otro. El capítulo 8.1 (CI/CD y entrega) hace que tu cambio se construya una vez, se pruebe, y se promueva como un artefacto inmutable. Este capítulo trata de lo que pasa después: cómo conviertes ese código desplegado en una experiencia en vivo para usuarios reales, gradualmente, con seguridad, y con una ruta rápida de vuelta. El despliegue significa instalar código en servidores. El lanzamiento significa dejar que los usuarios alcancen una capacidad. Cuando los separas, un despliegue se vuelve rutinario y aburrido, y un lanzamiento se vuelve una decisión controlada y reversible.

Para los equipos grandes, esta separación cambia la temperatura emocional de enviar. Cuando docenas de servicios y cientos de ingenieros cambian producción cada día, un modelo acoplado de «despliegue igual a lanzamiento» significa que cada cambio de cara al usuario es un evento riesgoso y de todo o nada. Desacoplarlos te permite fusionar trabajo inacabado detrás de un interruptor, desplegar una función al uno por ciento del tráfico, vigilar los números, y expandir o retirarte sin tocar la construcción. La entrega progresiva es el término paraguas para esto: liberar un cambio a una audiencia cada vez más amplia mientras las comprobaciones automatizadas deciden si continuar.

Los entornos empresariales y gubernamentales añaden coordinación y prueba. Una plataforma de pagos se lanza a través de muchos servicios que deben acordar un esquema. Una agencia pública opera bajo una autoridad para operar y control de cambios formal, y los auditores quieren evidencia de exactamente quién fue expuesto a qué, y cuándo. Bien hecha, la entrega progresiva satisface tanto el deseo de moverse rápido como la obligación de probar el control, porque el mismo mecanismo que limita el radio de impacto también produce un registro auditable del despliegue.

Principios fundamentales

Desplegar no es lanzar. Envía el código apagado, luego enciéndelo deliberadamente.
Radio de impacto pequeño primero. Expón un cambio a unos pocos antes de exponerlo a todos.
Cada lanzamiento tiene una marcha atrás. Si no puedes revertir en segundos, no has terminado de diseñar el lanzamiento.
Deja que las señales impulsen la promoción. Las métricas de salud y los presupuestos de error, no los calendarios ni el optimismo, deciden si un despliegue avanza.
Una bandera es un pasivo hasta que se elimina. Cada interruptor es código que debes mantener y eventualmente borrar.
Haz que el cambio de base de datos sobreviva ambas direcciones. Los despliegues y las reversiones deben ser seguros ambos contra el mismo esquema.
Las aprobaciones deberían registrar, no obstruir. La evidencia de auditoría es un subproducto del canal, no una reunión semanal.

Recomendaciones

Separa el despliegue del lanzamiento con banderas de función

Una bandera de función, o interruptor de función, es un conmutador en tiempo de ejecución que decide si una ruta de código está activa, sin un redespliegue. Trata las banderas como un vocabulario tipado, porque sus vidas útiles difieren. Una bandera de lanzamiento oculta el trabajo en progreso y vive de días a semanas. Una bandera operacional (un interruptor de apagado) te permite deshabilitar un subsistema bajo carga y puede vivir indefinidamente. Una bandera de experimento divide el tráfico para una prueba controlada y vive por la duración del experimento. Una bandera de permiso bloquea una capacidad por plan o rol y es efectivamente permanente. Da a cada bandera un dueño, un tipo, un valor predeterminado, y una fecha de eliminación esperada. El valor predeterminado debería ser el seguro, para que una interrupción del servicio de banderas falle cerrado hacia el comportamiento conocido como bueno en lugar de abierto hacia rutas no probadas.

Elige un patrón de entrega progresiva por nivel de servicio

Ajusta el mecanismo de despliegue al radio de impacto, como argumenta el capítulo 8.1 para las estrategias de despliegue. Un lanzamiento canario enruta una pequeña porción de tráfico a la nueva versión y se expande solo si la salud se mantiene. Un despliegue azul-verde mantiene dos entornos de producción y cambia el tráfico entre ellos para un cambio y una reversión instantáneos. Un despliegue rodante reemplaza las instancias en lotes. Un despliegue basado en anillos se expande a través de audiencias nombradas: primero los usuarios internos, luego una cohorte beta, luego una pequeña región, luego todos. Los anillos son el encuadre más útil para las grandes organizaciones porque nombran quién está expuesto en cada paso, que es exactamente lo que tanto un auditor como un respondedor de incidentes quieren saber. Las plataformas de contenedores y la orquestación (capítulo 8.3) proveen las primitivas de conformación de tráfico que hacen baratos de ejecutar estos patrones.

Bloquea los despliegues con comprobaciones de salud y reversión automática

Define criterios de salud objetivos antes del lanzamiento, no durante el incidente. El análisis automatizado compara el canario contra la línea base en tasa de error, latencia, y saturación, y ya sea promueve o revierte sin esperar a que un humano lo note. Vincula la promoción a tu objetivo de nivel de servicio y presupuesto de error de la ingeniería de fiabilidad de sitios (capítulo 9.1): cuando el presupuesto está saludable lanzas libremente, y cuando está gastado el canal se niega a avanzar hasta que el servicio se estabilice. La reversión automática importa más porque elimina la vacilación que convierte una pequeña regresión en una interrupción mayor. La reversión rápida también es tu control de incidente más barato: una reversión que toma segundos reduce el radio de impacto antes de que tu proceso de incidentes (capítulo 9.3) siquiera se ponga en marcha por completo. La tasa de fallo de cambio y el tiempo de recuperación que mejoras de esta manera son las mismas señales de flujo y estabilidad que rastrea tu canal de entrega (capítulo 11.2).

Usa lanzamientos oscuros y tráfico sombra para reducir el riesgo

Algunos cambios son demasiado consecuentes para encontrarse primero con usuarios reales a exposición completa. El lanzamiento oscuro envía una función apagada, luego la ejercita internamente o contra una fracción de producción antes de que nadie la vea. El tráfico sombra copia las solicitudes en vivo a la nueva ruta de código y descarta las respuestas, así mides la carga real y la corrección con cero impacto de usuario. Estas técnicas te permiten validar una reescritura o una nueva dependencia bajo tráfico auténtico, que ningún entorno de staging reproduce fielmente. Empárejalas con el mismo análisis de salud que usas para los canarios.

Ejecuta experimentos controlados a través del mismo sistema de banderas

La bandera de experimento es donde la ingeniería de lanzamiento se encuentra con el aprendizaje de producto. Una división de prueba A/B sirve variantes a cohortes comparables y mide un resultado elegido, alimentando la práctica de analítica de producto del capítulo 7.4. Reutiliza un sistema de banderas y segmentación tanto para los despliegues de seguridad como para los experimentos, así tienes un único rastro de auditoría y un único interruptor de apagado en lugar de dos pilas de interruptores paralelas que discrepan sobre quién está en qué cubo.

Mantén la base de datos compatible hacia atrás con expandir y contraer

Los despliegues y las reversiones solo se mantienen seguros si el esquema tolera tanto el código antiguo como el nuevo a la vez, lo cual es inevitable durante cualquier despliegue gradual. Usa el patrón de expandir y contraer (cambio paralelo): primero expande añadiendo nuevas columnas o tablas en una migración compatible hacia atrás, luego despliega código que escribe tanto en la forma antigua como en la nueva, luego rellena retroactivamente, luego mueve las lecturas, y solo mucho después contrae eliminando la forma antigua una vez que ningún código en ejecución dependa de ella. Nunca combines una migración destructiva con el despliegue que la necesita. Esta disciplina es lo que te permite revertir el código sin una base de datos que ya haya avanzado, y se conecta directamente con tu estrategia de pruebas (capítulo 2.4), que debe cubrir la ventana de versión mixta.

Haz que la gestión de cambios registre en lugar de obstruir

Reconcilia la auditoría con el flujo preaprobando clases de cambio. Define tipos de cambio estándar y de bajo riesgo que fluyan a través del canal automáticamente, capturando quién aprobó, qué pruebas se ejecutaron, qué artefacto se desplegó, y qué audiencias estuvieron expuestas en cada anillo. Reserva la revisión humana de consejo asesor de cambios para los cambios genuinamente de alto riesgo. Una junta tradicional de control de cambios que inspecciona cada despliegue rutinario se convierte en un cuello de botella que empuja a los equipos hacia lotes más grandes y riesgosos, lo opuesto de lo que pretende. En el gobierno, una autoridad para operar y control de cambios formal pueden coexistir con la entrega progresiva cuando las herramientas de despliegue emiten la evidencia que el marco de control requiere, así que el registro basado en anillos es el artefacto de auditoría.

Ventajas y desventajas

Patrón	Ventajas	Desventajas	Mejor ajuste
Canario	Basado en datos, radio de impacto pequeño	Necesita buenas métricas y volumen de tráfico	Servicios de cara al usuario a gran escala
Azul-verde	Cambio y reversión instantáneos	Duplica el costo de entorno durante el cambio	Servicios críticos que necesitan revertir rápido
Rodante	Barato, simple, sin entorno extra	Reversión lenta, versiones mixtas en vivo	Servicios internos sin estado
Basado en anillos	Audiencias nombradas, rastro de auditoría claro	Despliegue completo más lento; más coordinación	Patrimonios regulados y multiservicio
Banderas de función	Desacopla el despliegue del lanzamiento; interruptor de apagado instantáneo	Deuda de banderas; la matriz de pruebas crece	Equipos que envían trabajo incompleto con seguridad
Trenes de lanzamiento	Cadencia predecible, coordinación fácil	Acopla muchos cambios; espera al tren	Muchos equipos compartiendo un lanzamiento
Lanzamiento a demanda	Lotes pequeños, retroalimentación rápida	Coordinación entre equipos más difícil	Equipos de entrega continua de alta confianza

La tensión central es entre coordinación e independencia. Los trenes de lanzamiento agrupan los cambios de muchos equipos en un calendario fijo, lo cual es fácil de razonar pero obliga a un cambio terminado a esperar y acopla trabajo no relacionado en un evento. El lanzamiento a demanda permite que cada equipo envíe cuando esté listo, lo cual es más rápido pero exige que los servicios se mantengan desplegables independientemente y compatibles hacia atrás. La resolución usualmente es desacoplar a nivel de artefacto y esquema para que los equipos puedan lanzar a demanda, luego usar banderas y anillos para coordinar el momento visible al usuario en que una función entre servicios realmente se enciende. De esa manera el lanzamiento técnico y el lanzamiento de producto son decisiones separadas, y ninguna bloquea a la otra.

Preguntas para discutir con tu equipo

Cuando un lanzamiento sale mal a las 2 de la madrugada, ¿cuántos segundos toma revertirlo, y quién o qué aprieta el gatillo? La respuesta honesta revela si realmente has separado el despliegue del lanzamiento o meramente has añadido banderas encima de un proceso acoplado. Una reversión que requiere reconstruir, una migración de base de datos que deshacer, o un humano de guardia que decida no es una reversión, es un segundo incidente. Trae el mecanismo real para tus tres servicios principales: la bandera o el cambio de tráfico que revierte la exposición, la señal de salud que la dispara automáticamente, y la garantía de esquema que hace segura la reversión. Para un patrimonio grande esto determina tu radio de impacto real, porque la reversión automática rápida es lo que evita que una regresión se convierta en una interrupción. Si la respuesta se mide en reuniones en lugar de segundos, esa es la primera cosa que arreglar.
¿Cuál es tu política para retirar banderas, y cuánta deuda de banderas estás cargando ahora mismo? Cada bandera de función es una bifurcación en tu código que multiplica el número de estados que debes razonar y probar, y una bandera que sobrevive a su propósito es pasivo puro. Decide la regla ahora: cada bandera de lanzamiento obtiene un dueño y una fecha de expiración, las banderas obsoletas aparecen en un tablero, y eliminarlas es trabajo planificado en lugar de limpieza algún día. Trae un conteo de banderas vivas, sus edades, y cuántas han pasado su fecha de eliminación prevista. En una base de código grande, las banderas descontroladas se convierten en complejidad condicional permanente que nadie se atreve a borrar, y el mecanismo de seguridad se convierte en una fuente de errores. La tolerancia del equipo a ese número es realmente una declaración de cuán en serio se toma la higiene operacional.
¿Tu proceso de aprobación de cambios hace los lanzamientos más seguros, o solo más lentos? Muchas organizaciones operan un consejo asesor de cambios que revisa cada despliegue, y la pregunta incómoda es si alguna vez realmente ha detenido un mal cambio o meramente ha añadido latencia. Trae datos: el retraso de aprobación mediano, la tasa de fallo de cambio para los cambios revisados por el consejo frente a los preaprobados, y con qué frecuencia la revisión agrupa cambios pequeños en otros más grandes y riesgosos. La meta es reservar la revisión humana para los cambios genuinamente de alto riesgo mientras dejas que los cambios estándar fluyan a través del canal con captura automática de evidencia. Para los contextos regulados y gubernamentales, verifica que las herramientas de despliegue produzcan el registro de auditoría que el marco de control necesita, así el control se convierte en un subproducto de enviar en lugar de una puerta delante de ello. Si la revisión añade retraso sin reducir los fallos, es teatro con disfraz de cumplimiento.
¿Qué señales de salud objetivas estás dispuesto a dejar que una máquina actúe sobre ellas, y cada servicio de nivel superior realmente tiene métricas lo bastante buenas para bloquear sobre ellas? El análisis automatizado de canario y el bloqueo por presupuesto de error solo funcionan si la tasa de error, la latencia, y la saturación se miden lo bastante limpiamente para confiar en una promoción o una reversión sin un humano en el ciclo, y muchos equipos descubren durante un incidente que sus señales son demasiado ruidosas o escasas para decidir. Para un patrimonio grande esto determina cuánto de tu volumen de lanzamiento puede fluir con seguridad sin niñera manual, que es la diferencia entre una plataforma que escala y una que necesita a una persona vigilando cada despliegue. Trae los tableros reales de tus tres servicios más críticos: las métricas sobre las que bloqueas, el volumen de tráfico que hace estadísticamente significativo a un canario, y la tasa de falsos positivos de tu análisis automatizado. En entornos regulados y gubernamentales, las mismas señales alimentan el registro auditable, así que la mala observabilidad es tanto una brecha de fiabilidad como una brecha de cumplimiento, y financiar la calidad de las métricas debería ser una línea nombrada en el plan en lugar de una capacidad asumida.
¿Realmente sobreviven tus cambios de esquema una reversión, y cómo pruebas que la ventana de versión mixta es segura antes de enviar? La entrega progresiva promete una marcha atrás rápida, pero una migración destructiva acoplada a una función silenciosamente anula esa promesa, porque revertir el código lo deja apuntando a una base de datos que ya ha avanzado. Para una organización grande donde muchos servicios comparten un esquema, el riesgo se compone: el paso de contracción de un equipo puede varar la reversión de otro equipo, así que la disciplina de expandir y contraer tiene que ser un estándar compartido en lugar de un hábito local. Trae tu manual de migración y la evidencia de que se sigue: cómo separas la expansión de la contracción, si la escritura dual y el relleno retroactivo se prueban bajo carga, y cómo tu suite de pruebas ejercita el código antiguo contra el esquema nuevo y el código nuevo contra el esquema antiguo. Para patrimonios empresariales y gubernamentales que cargan datos de larga vida y control de cambios formal, una migración irreversible no es solo un riesgo de interrupción, es una exposición de integridad de datos y auditoría que una ventana de mantenimiento programada no rescatará.
Cuando una función entre servicios abarca equipos que envían a velocidades distintas, ¿quién es dueño del momento en que se enciende, y cómo coordinas sin acoplar sus despliegues? Todo el punto de separar el despliegue del lanzamiento es que cada equipo puede enviar su artefacto independientemente mientras una única bandera controla el lanzamiento visible al usuario, pero eso solo se sostiene si alguien es dueño de la decisión de lanzamiento y la segmentación de la bandera a través de las fronteras de servicio. Para un equipo grande el modo de fallo es un tren de lanzamiento de facto que nadie eligió: un servicio lento fuerza a cada otro equipo a esperar, o un cambio de bandera no coordinado expone una función a medio conectar. Trae el mapa de dependencias para tu próximo lanzamiento multiservicio, el dueño de la bandera de lanzamiento, y las garantías de compatibilidad hacia atrás que permiten que cada servicio se despliegue en su propio reloj. En programas empresariales y gubernamentales con aprobaciones de lanzamiento formales, nombra quién aprueba el encendido entre servicios y qué evidencia ve, así el lanzamiento coordinado es una decisión deliberada y registrada en lugar de un accidente de quien fusionó al final.

Perspectiva sectorial

Startup. Separar el despliegue del lanzamiento vale la pena incluso con tres ingenieros, pero mantenlo barato. Envuelve el trabajo nuevo en una bandera de lanzamiento con valor predeterminado apagado, envía a la línea principal, y enciende las funciones para ti mismo antes que para los clientes, así un cambio inacabado nunca bloquea un despliegue. Salta las plataformas pesadas de análisis de canario que no puedes dotar de personal: un servicio de banderas alojado y un interruptor de apagado duro compran la mayor parte de la seguridad, y una persona a cargo de un ritual semanal de limpieza de banderas evita que la deuda se trague tu velocidad.

Pequeña empresa. Sin un ingeniero de lanzamiento y con un presupuesto ajustado, apóyate en cualquier entrega progresiva que tu plataforma existente ya te dé, en lugar de construir un sistema de despliegue. El alojamiento gestionado, un SaaS de banderas de función, o el despliegue por etapas incorporado de tu marco usualmente cubre el radio de impacto pequeño que necesitas. Trata la marcha atrás como lo que debes hacer bien: un cambio que puedes apagar en segundos importa mucho más que un análisis automatizado sofisticado que no tienes tiempo de ajustar.

Empresa. El problema es la consistencia entre muchos equipos y servicios: un vocabulario de banderas compartido con dueños, tipos, y expiración, despliegue basado en anillos estándar, y bloqueo por presupuesto de error aplicado de la misma manera en todas partes para que los grupos dejen de inventar pilas de interruptores rivales. Gobierna la deuda de banderas como una métrica de todo el patrimonio, estandariza las migraciones de expandir y contraer para que el cambio de esquema de un equipo nunca vare la reversión de otro, y haz que el registro auditable de despliegue sea un subproducto que cada servicio emite en la misma forma. Preaprueba los cambios estándar y reserva la revisión humana para los genuinamente de alto riesgo, así el control escala sin una junta en el camino crítico.

Gobierno. Las reglas de contratación pública, la transparencia, y la rendición de cuentas pública moldean cada lanzamiento. Haz que las herramientas de despliegue sean la fuente de evidencia de auditoría, así cada expansión de anillo registra la autoridad aprobadora, las pruebas que se ejecutaron, el hash del artefacto, y la población exacta expuesta, y una autoridad para operar coexiste con la entrega progresiva en lugar de luchar contra ella. Prefiere los patrones basados en anillos o azul-verde cuyas audiencias nombradas tanto un auditor como un respondedor de incidentes puedan leer, valida los cambios consecuentes con tráfico sombra contra casos en vivo antes de que se vea afectado cualquier ciudadano, y mantén el registro auditable como el artefacto que el marco de control acepta en lugar de una ventana de gran explosión programada.

Ejemplos

Startup. Una empresa SaaS de diez personas envía a la línea principal muchas veces al día y envuelve cada nueva capacidad en una bandera de lanzamiento con valor predeterminado apagado. Una nueva integración de facturación riesgosa se lanza oscura: ejecutan tráfico sombra contra ella durante una semana, observando cómo maneja formas de solicitud reales sin impacto en el cliente, luego la despliegan anillo por anillo, empezando con sus propias cuentas y un puñado de clientes beta amigables. Cuando las tasas de error se disparan en el anillo del cinco por ciento, una comprobación automatizada apaga la bandera en segundos, y depuran con calma el lunes. Un ingeniero es dueño de un ritual semanal de limpieza de banderas así los interruptores nunca se acumulan.

Empresa. Una empresa global de pagos coordina un cambio que abarca seis servicios y un esquema compartido. Cada equipo despliega su artefacto independientemente y de forma compatible hacia atrás usando expandir y contraer, así las nuevas columnas existen y se escriben doblemente mucho antes de que cualquier usuario vea la función. El lanzamiento visible al usuario es una única bandera de experimento, desplegada a través de anillos con clave en la salud del presupuesto de error: interno, luego un país pequeño, luego un porcentaje creciente, con análisis automatizado de canario promoviendo o revirtiendo en cada paso. Un servicio de gobernanza de banderas aplica dueños, tipos, y expiración a través del patrimonio, y los cambios estándar preaprobados fluyen sin una junta mientras solo el paso de contracción de esquema recibe revisión humana. Cada transición de anillo se registra, así el rastro de auditoría se escribe solo.

Gobierno. Una agencia nacional de beneficios opera bajo una autoridad para operar y control de cambios formal. En lugar de tratar la entrega progresiva como un riesgo de cumplimiento, hace que las herramientas de despliegue sean la fuente de evidencia de auditoría: cada expansión de anillo registra la autoridad aprobadora, las pruebas que se ejecutaron, el hash del artefacto, y la población exacta expuesta. Un nuevo cálculo de elegibilidad se lanza oscuro y se valida con tráfico sombra contra casos en vivo, luego se despliega región por región detrás de una bandera con cambio azul-verde para una reversión instantánea. Los cambios estándar se preclasifican así el trabajo rutinario no hace cola detrás de una junta, mientras los cambios de política de alto riesgo todavía reciben revisión formal. El registro auditable de despliegue satisface el marco de control más completamente de lo que jamás lo hizo el antiguo lanzamiento trimestral de gran explosión.

Caso de negocio: motivaciones, ROI y TCO

El retorno de la entrega progresiva está dominado por los incidentes evitados y su severidad reducida. Un cambio que alcanza al uno por ciento de los usuarios y revierte automáticamente cuesta un error de redondeo, donde el mismo defecto a exposición completa puede significar horas de interrupción, respuesta de emergencia, y daño reputacional. Desacoplar el despliegue del lanzamiento también convierte el lanzamiento mismo de un evento programado y de alto estrés en uno rutinario, lo cual reduce el impuesto de coordinación que crece de forma no lineal con el tamaño del equipo. Separar la decisión de lanzamiento del despliegue permite que producto e ingeniería se muevan en sus propios relojes, así una fecha de marketing nunca fuerza una congelación de código riesgosa.

El costo total de propiedad es real pero modesto frente a ese beneficio. Inviertes en una plataforma de banderas, herramientas de análisis de canario, métricas de salud lo bastante buenas para bloquear sobre ellas, y la disciplina de los cambios de esquema compatibles hacia atrás. El costo recurrente es la higiene de banderas y la matriz de pruebas más grande que crean las banderas, por lo cual un patrimonio de banderas sin gestionar es la manera principal en que esta práctica se vuelve costosa. El costo de no adoptarla se paga en radio de impacto: cada lanzamiento es todo o nada, las reversiones son lentas, y un único mal despliegue puede derribar a todos a la vez. Para las organizaciones reguladas, el dividendo de cumplimiento es decisivo, porque el mismo mecanismo que limita la exposición también genera la evidencia auditable que de otro modo se ensamblaría a mano.

Antipatrones y trampas

Despliegue igual a lanzamiento. Acoplar los dos hace que cada cambio de cara al usuario sea un evento riesgoso y de todo o nada sin marcha atrás.
Deuda de banderas. Los interruptores que sobreviven a su propósito se convierten en complejidad condicional permanente que nadie se atreve a borrar.
Banderas que fallan abiertas. Una interrupción del servicio de banderas que por defecto va a la ruta nueva y no probada convierte un parpadeo menor en una interrupción.
Reversión que necesita deshacer un esquema. Una migración destructiva enviada con su función te deja incapaz de revertir el código con seguridad.
Promoción manual por intuición. Avanzar un despliegue porque «se ve bien» en lugar de por criterios de salud definidos y presupuestos de error.
Despliegue sin plan de reversión. Diseñar cómo encender una función sin diseñar cómo apagarla.
Sellado de goma del consejo de cambios. Una revisión que nunca rechaza nada añade retraso sin añadir seguridad y empuja a los equipos hacia lotes grandes.
Banderas de experimento y seguridad en sistemas separados. Dos pilas de interruptores que discrepan sobre quién está en qué cubo, duplicando la superficie de auditoría.

Modelo de madurez

Nivel 1, Iniciar: El despliegue y el lanzamiento son el mismo evento. Los cambios salen todos de una vez, la reversión significa redesplegar una construcción antigua a mano, y las migraciones de esquema son destructivas y acopladas a las funciones. Cualquier exposición gradual es ad hoc, reactiva, y no documentada.
Nivel 2, Desarrollar: Las banderas de función existen para algunos equipos y ocultan trabajo inacabado, pero carecen de dueños, tipos, y expiración, y la deuda se acumula. El canario o azul-verde se usa para unos pocos servicios críticos, aplicado inconsistentemente equipo por equipo. La reversión está escrita como script pero es disparada por humanos, y los cambios de esquema solo a veces son compatibles hacia atrás.
Nivel 3, Estandarizar: El despliegue y el lanzamiento están separados por defecto en toda la organización. Las banderas están tipadas, tienen dueño, y expiran, con valores predeterminados seguros, siguiendo un estándar documentado y aplicado. La entrega progresiva con despliegue basado en anillos y análisis automatizado de canario es la norma, las migraciones de expandir y contraer son requeridas, y los cambios estándar fluyen a través del canal con captura automática de evidencia.
Nivel 4, Gestionar: El proceso de lanzamiento se mide y controla con datos. La tasa de fallo de cambio, el tiempo medio de restauración, la latencia de reversión, la edad y conteo de banderas, y la tasa de falsos positivos de canario se rastrean contra líneas base y presupuestos de error, y los despliegues se bloquean sobre esos SLO (capítulo 9.1) para que la promoción y la reversión actúen automáticamente sobre señales de salud definidas. La deuda de banderas se reporta como una métrica de todo el patrimonio y se retira según un calendario, y las desviaciones del estándar de despliegue aparecen en un tablero en lugar de en un postmortem.
Nivel 5, Orquestar: La entrega progresiva se mejora continuamente y se integra en toda la organización. Los lanzamientos oscuros y el tráfico sombra reducen el riesgo de los cambios importantes rutinariamente, los experimentos y los despliegues de seguridad comparten un sistema de banderas y un rastro de auditoría, y la política de lanzamiento se adapta al estado del presupuesto de error en tiempo real. El registro auditable de despliegue satisface el control de cambios (capítulo 9.3) como subproducto, y la organización ajusta sus anillos, puertas, y umbrales a partir de la evidencia a medida que cambian el patrimonio y el panorama de riesgo.

Ideas para el debate

Para tu servicio más crítico, ¿dónde está la frontera correcta entre una reversión automática bloqueada por salud y una decisión humana, y qué señal confiarías lo bastante para dejar que la máquina actúe sola?
¿Deberían las banderas de experimento y de lanzamiento compartir una plataforma y un interruptor de apagado, o combinarlas crea más riesgo del que elimina?
¿Cómo decides entre un tren de lanzamiento y un lanzamiento a demanda cuando una función abarca varios equipos que envían a velocidades distintas?
¿Cuál es la vida media honesta de una bandera de lanzamiento en tu base de código, y qué haría que eliminarla fuera tan rutinario como crearla?
¿Cómo debería el estado del presupuesto de error cambiar quién tiene permitido lanzar, y quién es dueño de la decisión de congelar los lanzamientos cuando el presupuesto se gasta?
En tu contexto regulado, ¿qué evidencia específica debe emitir un despliegue para que el marco de control acepte la entrega progresiva en lugar de una ventana de lanzamiento programada?

Puntos clave

Separa el despliegue del lanzamiento. Enviar código y exponer una función son decisiones distintas, y las banderas son lo que las desacopla.
Despliega progresivamente. Los patrones canario, azul-verde, rodante, y basado en anillos limitan el radio de impacto; elige por nivel de servicio según el riesgo.
Bloquea sobre la salud y los presupuestos de error. Deja que las señales definidas y los SLO (capítulo 9.1) impulsen la promoción y reversión automáticas, no los calendarios ni el optimismo.
Diseña primero la marcha atrás. La reversión rápida y segura reduce el radio de impacto antes de que tu proceso de incidentes (capítulo 9.3) se active por completo.
Tipa, asigna dueño, y expira cada bandera. Las banderas de lanzamiento, operacionales, de experimento, y de permiso tienen vidas útiles distintas; las banderas sin gestionar se convierten en deuda.
Haz los cambios de esquema compatibles hacia atrás. Usa expandir y contraer para que tanto el despliegue como la reversión se mantengan seguros a través de la ventana de versión mixta (capítulo 2.4).
Deja que las aprobaciones registren, no obstruyan. Preaprueba los cambios estándar y reserva la revisión humana para el alto riesgo, así el registro de despliegue es la evidencia de auditoría.

Referencias y lecturas adicionales

Jez Humble y David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, y Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, y John Willis, The DevOps Handbook.
Betsy Beyer, Chris Jones, Jennifer Petoff, y Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, «Feature Toggles (Feature Flags)» (ensayo en martinfowler.com).
Danilo Sato, «Canary Release» y Martin Fowler, «BlueGreenDeployment» (ensayos en martinfowler.com).
Sam Newman, Building Microservices: Designing Fine-Grained Systems (expandir-contraer y desplegabilidad independiente).
Pramod Sadalage y Scott Ambler, Refactoring Databases: Evolutionary Database Design (migraciones de esquema de cambio paralelo).
Ron Kohavi, Diane Tang, y Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing.
James Governor, «Progressive Delivery» (RedMonk, la acuñación del término).