El artefacto web-reservas existe: compilado una sola vez, probado y almacenado. Pero sigue quieto. Entre ese fichero y app-contoso-reservas-pro todavía está Marta Ríos pegando comandos un viernes por la noche, y mientras eso siga así las métricas DORA de Contoso no se moverán: el tiempo de entrega seguirá siendo de semanas y el de restauración, de horas.

Esta lección recorre ese último tramo, que es el que da miedo. Verás cómo los entornos convierten «creo que en producción está la versión de la semana pasada» en un dato exacto; cómo las comprobaciones y aprobaciones ponen una puerta consciente delante de producción sin volver al despliegue manual; y cómo el intercambio de ranuras que ya conoces del módulo 2 se convierte en un despliegue azul-verde real, con una reversión que tarda segundos. Al final, desplegar dejará de ser un acontecimiento.

1. Entrega continua frente a despliegue continuo
2. Entornos: qué versión hay en cada sitio
3. Comprobaciones y aprobaciones
4. El pipeline de varias etapas
5. Estrategias de despliegue y ranuras de App Service
6. La conexión de servicio restringida por entorno
7. Migraciones de base de datos: expandir y contraer
8. Verificación posterior al despliegue y reversión
9. Marcas de característica: desplegar no es activar
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Dos términos que se usan como sinónimos y no lo son:

Contoso se sitúa en entrega continua con una excepción: desarrollo y preproduccion se despliegan automáticamente en cada fusión a main, y produccion requiere una aprobación. No es falta de ambición, es proporcionalidad: un despliegue erróneo en la web de venta de billetes tiene consecuencias económicas inmediatas, y el equipo aún no tiene la telemetría del módulo 7 ni la reversión automática que justificarían quitar esa puerta. La aprobación es una decisión de riesgo revisable, no un dogma; cuando la tasa de fallo baje del 15 %, tendrá sentido replantearla.

Un entorno en Azure Pipelines es una entidad con nombre que representa un destino de despliegue —desarrollo, preproduccion, produccion— y que aporta tres cosas que un simple paso de despliegue no da:

• Trazabilidad: registra qué ejecución, qué artefacto y qué confirmaciones se desplegaron, y cuándo. Es la respuesta exacta a «¿qué versión hay en producción?».
• Recursos registrados: opcionalmente asocia máquinas virtuales o espacios de nombres de Kubernetes, con su estado.
• Comprobaciones: es el sitio donde se cuelgan las aprobaciones y las demás puertas. Un detalle importante: la protección vive en el entorno, no en el YAML, de modo que quien edita el pipeline no puede quitarla.

Contoso crea tres: desarrollo (despliegue automático, sin puertas), preproduccion (automático, con comprobación de rama) y produccion (aprobación humana, ventana de despliegue y comprobación de rama).

Una comprobación es una condición que debe cumplirse antes de que un trabajo pueda desplegar en el entorno. Las que usa Contoso:

La aprobación merece una precisión. No es un trámite burocrático: es el punto en el que una persona con contexto operativo mira qué va a entrar, comprueba que hay alguien disponible por si algo sale mal y decide. Por eso se limita a un grupo pequeño, tiene un tiempo de espera (Contoso pone 3 días, tras los cuales la ejecución se cancela) y permite dejar un comentario que queda registrado.

La ventana de despliegue codifica la regla que todo el mundo dice y nadie cumple. Antes era «intentemos no desplegar los viernes»; ahora la ejecución sencillamente espera hasta el lunes a las 08:00. Y en la semana de apertura de temporada, cuando el volumen de reservas se multiplica, se congela produccion desactivando temporalmente el despliegue automático hacia preproducción o añadiendo una segunda aprobación.

Este es contoso-reservas-cd, que toma el artefacto de 05-03 y lo lleva a los tres entornos:

Tres piezas merecen atención. resources.pipelines hace que este pipeline se dispare al terminar el de integración continua y pueda descargar su artefacto: no se recompila nada, se despliega exactamente el binario que se probó. deployment en lugar de job es lo que vincula el trabajo con el entorno y alimenta su historial. Y dependsOn más condition encadenan las etapas: producción no se intenta si preproducción falló.

Contoso usa azul-verde, y lo implementa con las ranuras de despliegue de App Service (02-03), que es donde estas estrategias dejan de ser teoría:

Lo que hace especial al intercambio de App Service es el calentamiento: antes de mover el tráfico, la plataforma arranca la aplicación de la ranura, le aplica los ajustes de producción y le pide su punto /salud hasta que responde correctamente. Solo entonces conmuta. Eso elimina el problema clásico del azul-verde casero, en el que los primeros usuarios pagan el arranque en frío. Y el intercambio es de enrutamiento interno, no de copia de ficheros: tarda segundos y es reversible con la misma operación.

Requisitos que hay que respetar: los ajustes que no deben viajar con el código —cadenas de conexión, referencias @Microsoft.KeyVault(...)— tienen que estar marcados como ajuste de ranura (slot setting) para que se queden anclados a su ranura, y el plan plan-contoso-reservas-pro debe ser Standard o superior (Contoso usa Premium v3 con redundancia de zona, así que cumple de sobra).

Las conexiones sc-contoso-dev y sc-contoso-pro de 05-01 no son intercambiables, y hay que impedir activamente que se usen mal:

• Ámbito y rol mínimos: sc-contoso-pro tiene Colaborador de sitio web sobre rg-contoso-reservas-pro. Puede desplegar e intercambiar ranuras; no puede tocar rg-contoso-red-pro ni borrar una base de datos.
• Sin acceso abierto: al desactivar «conceder permiso de acceso a todos los pipelines», un pipeline nuevo no hereda la capacidad de desplegar en producción. Autorizarlo es un acto explícito.
• Comprobación de conexión en el entorno: la comprobación Required template o la restricción de la propia conexión permiten exigir que solo se use desde una plantilla aprobada.
• Federación de identidad de carga de trabajo: sin secreto que caduque ni que se pueda exfiltrar.

El principio es el mismo del módulo 4 llevado a la entrega: la credencial que despliega la web no debería poder hacer nada más que desplegar la web.

Aquí está el punto donde más despliegues «sin interrupción» se rompen. Durante un intercambio azul-verde, y durante la ventana de reversión posterior, dos versiones del código conviven contra la misma base de datos db-reservas. Por tanto:

Toda migración de esquema debe ser compatible hacia atrás: la versión anterior del código tiene que seguir funcionando con el esquema nuevo.

El patrón que lo garantiza es expandir y contraer, en tres despliegues separados. Supón que Contoso necesita sustituir la columna nombre_pasajero por nombre y apellidos:

Reglas prácticas: nunca renombrar ni eliminar una columna en el mismo despliegue que introduce su sustituta; nunca añadir una columna NOT NULL sin valor por defecto, porque la versión antigua no la rellenará; y ejecutar las migraciones antes del intercambio, en un paso propio contra sql-contoso-reservas-pro desde un agente de pool-contoso-privado —el servidor solo es accesible por pe-sql-reservas— y con la identidad administrada que aprendiste en 04-02, no con contraseñas.

La consecuencia importante: una migración destructiva rompe la reversión. Si el despliegue elimina una columna y hay que volver atrás, la versión anterior encontrará un esquema que no entiende. Con expandir y contraer, el intercambio inverso siempre funciona.

Desplegar y marcar la ejecución en verde no significa que funcione. Contoso añade dos verificaciones:

• Comprobación de salud: curl -f https://www.contosoairlines.example/salud, que devuelve error si el punto no responde 200. El punto /salud debe comprobar dependencias reales —conexión a db-reservas, acceso a kv-contoso-pro— y no limitarse a devolver «OK».
• Pruebas de humo: un puñado de peticiones que ejercitan el camino crítico (buscar un vuelo, consultar disponibilidad) contra la ranura de preproducción antes del intercambio, no después.

Y cuando algo falla, la reversión. Hay dos formas y no son equivalentes:

El reintercambio es literalmente la misma tarea Swap Slots ejecutada otra vez, y por eso conviene tener un pipeline de reversión de un solo paso, listo para lanzar sin pensar. Esta es la razón por la que la métrica DORA de tiempo de restauración de Contoso puede pasar de horas a menos de un minuto: no porque el equipo sea más rápido arreglando, sino porque volver atrás ya no consiste en arreglar nada.

Una advertencia: la reversión revierte el código, no los datos. Si la versión nueva escribió registros con un formato que la anterior no entiende, o si ya se ejecutó la fase de contracción, el reintercambio no basta. De ahí la disciplina del apartado anterior.

El último paso para que desplegar deje de dar miedo es separar dos cosas que solemos confundir: desplegar (que el código esté en producción) y activar (que los usuarios lo usen). Una marca de característica es una condición en el código que enciende o apaga una funcionalidad sin desplegar nada:

Esto habilita tres cosas: que las ramas de característica sean cortas de verdad —el trabajo a medias se fusiona apagado—, que el despliegue canario se haga por porcentaje de usuarios sin infraestructura adicional, y que apagar una funcionalidad rota sea instantáneo y no requiera reversión. Azure App Configuration ofrece este servicio gestionado con su gestor de características, filtros por porcentaje y por grupo de usuarios, e integración directa con App Service.

El coste es real y hay que reconocerlo: cada marca es una bifurcación que multiplica los caminos posibles del código. Se gestionan como deuda —con propietario y fecha de retirada— y se eliminan en cuanto la funcionalidad está consolidada.

Qué se mide después de todo esto es materia del módulo 7: cada despliegue debe verse en Azure Monitor y en Application Insights, con las métricas de errores y latencia antes y después del intercambio. Sin esa realimentación, la aprobación de Marta sigue siendo una decisión a ciegas.

• Recompilar en cada entorno. Rompe la garantía de que lo probado es lo desplegado. El pipeline de despliegue consume el artefacto, nunca lo regenera.
• Poner las aprobaciones en el YAML. Quien edite el fichero podría quitarlas. Las comprobaciones viven en el entorno, que tiene sus propios permisos.
• Migraciones destructivas en el mismo despliegue. Rompen la reversión justo cuando la necesitas. Expandir y contraer, siempre, en despliegues separados.
• Un punto /salud que solo devuelve «OK». No comprueba nada. Debe verificar las dependencias reales: base de datos, almacén de secretos, servicios externos críticos.
• Ranuras sin ajustes de ranura marcados. La cadena de conexión de producción viaja a preproducción o al revés, y acabas escribiendo en la base de datos equivocada.
• Aprobar por costumbre. Una aprobación que siempre se concede en dos segundos no es una puerta, es un clic. Si nadie mira qué entra, es mejor automatizar y dedicar el esfuerzo a la telemetría.
• Consejo: guarda un pipeline de reversión de un solo paso, y ensáyalo. Una reversión que nunca se ha probado no es una reversión.
• Consejo: etiqueta automáticamente el repositorio al desplegar en producción; así la correspondencia entre etiqueta, artefacto y entorno no depende de nadie.

Contoso Millas (centro-coste=CC-2077) va a montar su despliegue continuo. Su equipo son cuatro desarrolladores y un responsable de infraestructura. Su web tiene mucho menos tráfico que la de reservas y su ventana de mayor uso es los lunes por la mañana.

1. ¿Qué entornos crearías y qué comprobación pondrías en cada uno?
2. ¿Recomendarías entrega continua o despliegue continuo? Justifícalo con las diferencias respecto a Contoso Reservas.
3. ¿Dónde se configuran esas comprobaciones y por qué no en el YAML?

Contoso despliega la versión 2.6.0, que incluye una migración que renombra la columna codigo_reserva a localizador en db-reservas. A los diez minutos aparece un fallo grave en el cálculo de tarifas y Marta lanza el reintercambio de ranura. La web vuelve a la versión 2.5.0 y empieza a fallar con errores de columna inexistente.

1. ¿Qué ha ocurrido exactamente y por qué el reintercambio no ha bastado?
2. Reescribe el cambio con expandir y contraer, indicando qué hace cada despliegue.
3. ¿Desde qué agente debe ejecutarse la migración contra sql-contoso-reservas-pro y con qué credencial?

Contoso quiere probar un algoritmo nuevo de precios en la API de Disponibilidad, que corre en vmss-api-disponibilidad-pro detrás de lb-api-disponibilidad-pro. El riesgo es alto: un error de precios tiene impacto económico directo. El equipo quiere exponerlo primero a una fracción del tráfico.

1. ¿Qué estrategia de despliegue corresponde y por qué no azul-verde puro?
2. ¿Cómo la combinarías con una marca de característica?
3. Si el algoritmo falla con el 5 % del tráfico, ¿cuál es la vía de reversión más rápida y por qué?

Solución 1:

1. millas-desarrollo sin comprobaciones, con despliegue automático; millas-produccion con comprobación de rama (solo main) y aprobación del responsable de infraestructura. La ventana de despliegue debería excluir el lunes por la mañana, que es su pico. Un entorno de preproducción es opcional dado el tamaño del equipo, aunque si usan ranuras de App Service el patrón sale casi gratis y conviene mantenerlo.
2. Entrega continua al principio, por la misma razón que Contoso Reservas: todavía no hay telemetría ni reversión automática que justifiquen quitar la puerta humana. Con menos tráfico y menor impacto económico, sin embargo, es un candidato razonable a despliegue continuo una vez que sus pruebas automáticas sean sólidas y tengan alertas; el criterio no es el tamaño del equipo, es la capacidad de detectar y revertir rápido.
3. En el entorno de Azure Pipelines, no en el YAML, porque el YAML lo puede modificar cualquiera con permiso sobre el repositorio: bastaría con enviar una solicitud de cambios que borre la aprobación. Las comprobaciones del entorno tienen sus propios permisos y son independientes del código.

Solución 2:

1. La migración renombró la columna, es decir, la eliminó y creó otra. El esquema quedó incompatible con la versión 2.5.0, que sigue consultando codigo_reserva. El reintercambio revierte el código, pero no revierte el esquema ni los datos: por eso no bastó. La reversión solo funciona si toda migración es compatible hacia atrás.
2. Despliegue 1 (expandir): añadir la columna localizador admitiendo nulos, conservando codigo_reserva; el código escribe en ambas y lee de codigo_reserva. Proceso de migración: rellenar localizador en las filas históricas. Despliegue 2: el código lee de localizador y sigue escribiendo en ambas —aquí ya se puede revertir sin daño—. Despliegue 3 (contraer): el código deja de escribir en codigo_reserva y, solo tras confirmar que ninguna versión anterior sigue viva, se elimina la columna.
3. Desde un agente autohospedado del grupo pool-contoso-privado, situado en snet-gestion dentro de vnet-contoso-pro, porque sql-contoso-reservas-pro solo es accesible a través de pe-sql-reservas y un agente hospedado por Microsoft no tiene ruta hasta él. La credencial debe ser la identidad administrada del agente con permisos de Entra ID sobre la base de datos, nunca una contraseña de administrador de SQL. Y el paso va antes del intercambio.

Solución 3:

1. Canario. El azul-verde puro conmuta el 100 % del tráfico de golpe: si el algoritmo calcula mal, todos los clientes ven precios erróneos durante el tiempo que se tarde en detectarlo. El canario limita la exposición a una fracción y permite comparar métricas entre las dos versiones antes de continuar. En vmss-api-disponibilidad-pro se implementa desplegando la versión nueva en un subconjunto de instancias y ponderando el reparto en lb-api-disponibilidad-pro, o publicando un grupo de instancias nuevo y trasladando tráfico progresivamente.
2. Con una marca de característica por porcentaje de usuarios: se despliega el código nuevo en todas las instancias pero apagado, y se enciende para un 5 % desde Azure App Configuration. Esto es mejor que el canario de infraestructura porque el reparto se controla sin tocar el balanceador, se puede segmentar por tipo de cliente y todas las instancias ejecutan el mismo binario, lo que elimina las diferencias de configuración.
3. Apagar la marca de característica: es instantáneo, no requiere despliegue, no requiere intercambio y no toca la infraestructura. Solo si el fallo estuviera fuera de la marca —en código común— habría que recurrir al reintercambio de ranura o a retirar las instancias canario del balanceador. Es exactamente la ventaja de separar el despliegue de la activación: la vía de reversión más rápida deja de ser un despliegue.

El artefacto ya no espera: viaja solo. Sabes distinguir la entrega continua del despliegue continuo y por qué Contoso se sitúa en la primera con una puerta humana delante de producción, no por dogma sino porque aún le falta la telemetría y la reversión automática que justificarían quitarla. Has creado los entornos desarrollo, preproduccion y produccion, que aportan lo que un simple paso de despliegue no da: el registro exacto de qué versión hay en cada sitio y un lugar para colgar las protecciones fuera del YAML, de modo que quien edita el pipeline no pueda quitarlas.

Sobre esos entornos has puesto comprobaciones con sentido: la aprobación de Marta Ríos con su tiempo de espera, la ventana de despliegue que convierte «intentemos no desplegar los viernes» en una regla que se cumple sola, la comprobación de rama y las puertas que consultan si hay una incidencia abierta antes de dejar pasar nada. Has escrito el pipeline contoso-reservas-cd de tres etapas encadenadas con dependsOn y condition, que consume el artefacto de 05-03 sin recompilar y que en producción no copia ficheros sino que intercambia la ranura preproduccion con su calentamiento previo contra /salud: el azul-verde real de Contoso, comparado en tabla con la recreación, la actualización gradual y el canario. Sabes restringir sc-contoso-pro al rol y al ámbito mínimos y a los pipelines autorizados; sabes que toda migración debe ser compatible hacia atrás con el patrón expandir y contraer, porque una columna eliminada rompe la reversión justo cuando la necesitas; y sabes que revertir de verdad es un reintercambio de segundos, no un redespliegue de minutos —el motivo por el que el tiempo de restauración de Contoso puede caer de horas a menos de un minuto—. Y con las marcas de característica has separado desplegar de activar, dejando la vía de reversión más rápida de todas: un interruptor.

Queda un cabo que este módulo arrastra desde el principio. Los cuatro repositorios de Contoso comparten una biblioteca de modelos de reserva que está copiada y pegada en tres de ellos, y ya hay tres versiones distintas circulando: cuando Diego corrige la validación del localizador en la web, la API sigue con la versión vieja y las dos discrepan en producción. Las plantillas de pipeline resolvieron esto para el YAML; falta resolverlo para el código. En la próxima lección, Azure Artifacts, montarás el feed contoso-paquetes, publicarás contoso.reservas.modelos como paquete versionado desde un pipeline, promocionarás versiones entre las vistas @local, @prerelease y @release, y configurarás los orígenes ascendentes que protegen a Contoso de que un paquete público desaparezca y, sobre todo, del ataque de confusión de dependencias.