L'artefacte web-reservas existeix: compilat una sola vegada, provat i emmagatzemat. Però continua quiet. Entre aquest fitxer i app-contoso-reservas-pro encara hi ha la Marta Ríos enganxant ordres un divendres a la nit, i mentre això continuï així les mètriques DORA de Contoso no es mouran: el temps de lliurament continuarà sent de setmanes i el de restauració, d'hores.

Aquesta lliçó recorre aquest últim tram, que és el que fa por. Veuràs com els entorns converteixen «em sembla que en producció hi ha la versió de la setmana passada» en una dada exacta; com les comprovacions i aprovacions posen una porta conscient davant de producció sense tornar al desplegament manual; i com l'intercanvi de ranures que ja coneixes del mòdul 2 es converteix en un desplegament blau-verd real, amb una reversió que triga segons. Al final, desplegar deixarà de ser un esdeveniment.

1. Lliurament continu davant de desplegament continu
2. Entorns: quina versió hi ha a cada lloc
3. Comprovacions i aprovacions
4. La canalització de diverses etapes
5. Estratègies de desplegament i ranures d'App Service
6. La connexió de servei restringida per entorn
7. Migracions de base de dades: expandir i contraure
8. Verificació posterior al desplegament i reversió
9. Marques de característica: desplegar no és activar
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Dos termes que es fan servir com a sinònims i no ho són:

Contoso se situa en lliurament continu amb una excepció: desarrollo i preproduccion es despleguen automàticament a cada fusió a main, i produccion requereix una aprovació. No és falta d'ambició, és proporcionalitat: un desplegament erroni al web de venda de bitllets té conseqüències econòmiques immediates, i l'equip encara no té la telemetria del mòdul 7 ni la reversió automàtica que justificarien treure aquesta porta. L'aprovació és una decisió de risc revisable, no un dogma; quan la taxa d'errada baixi del 15 %, tindrà sentit replantejar-la.

Un entorn a Azure Pipelines és una entitat amb nom que representa una destinació de desplegament —desarrollo, preproduccion, produccion— i que aporta tres coses que un simple pas de desplegament no dóna:

• Traçabilitat: registra quina execució, quin artefacte i quines confirmacions es van desplegar, i quan. És la resposta exacta a «quina versió hi ha en producció?».
• Recursos registrats: opcionalment associa màquines virtuals o espais de noms de Kubernetes, amb el seu estat.
• Comprovacions: és el lloc on es pengen les aprovacions i les altres portes. Un detall important: la protecció viu a l'entorn, no al YAML, de manera que qui edita la canalització no la pot treure.

Contoso en crea tres: desarrollo (desplegament automàtic, sense portes), preproduccion (automàtic, amb comprovació de branca) i produccion (aprovació humana, finestra de desplegament i comprovació de branca).

Una comprovació és una condició que s'ha de complir abans que un treball pugui desplegar a l'entorn. Les que fa servir Contoso:

L'aprovació mereix una precisió. No és un tràmit burocràtic: és el punt en què una persona amb context operatiu mira què entrarà, comprova que hi ha algú disponible per si alguna cosa surt malament i decideix. Per això es limita a un grup petit, té un temps d'espera (Contoso hi posa 3 dies, després dels quals l'execució es cancel·la) i permet deixar un comentari que queda registrat.

La finestra de desplegament codifica la regla que tothom diu i ningú no compleix. Abans era «intentem no desplegar els divendres»; ara l'execució senzillament espera fins dilluns a les 08:00. I la setmana d'obertura de temporada, quan el volum de reserves es multiplica, es congela produccion desactivant temporalment el desplegament automàtic cap a preproducció o afegint una segona aprovació.

Aquesta és contoso-reservas-cd, que pren l'artefacte de 05-03 i el porta als tres entorns:

Tres peces mereixen atenció. resources.pipelines fa que aquesta canalització es dispari en acabar la d'integració contínua i pugui descarregar-ne l'artefacte: no es recompila res, es desplega exactament el binari que es va provar. deployment en lloc de job és el que vincula el treball amb l'entorn i alimenta el seu historial. I dependsOn més condition encadenen les etapes: producció no s'intenta si preproducció ha fallat.

Contoso fa servir blau-verd, i l'implementa amb les ranures de desplegament d'App Service (02-03), que és on aquestes estratègies deixen de ser teoria:

El que fa especial l'intercanvi d'App Service és l'escalfament: abans de moure el trànsit, la plataforma engega l'aplicació de la ranura, li aplica els ajustos de producció i li demana el seu punt /salud fins que respon correctament. Només aleshores commuta. Això elimina el problema clàssic del blau-verd casolà, en què els primers usuaris paguen l'arrencada en fred. I l'intercanvi és d'encaminament intern, no de còpia de fitxers: triga segons i és reversible amb la mateixa operació.

Requisits que cal respectar: els ajustos que no han de viatjar amb el codi —cadenes de connexió, referències @Microsoft.KeyVault(...)— han d'estar marcats com a ajust de ranura (slot setting) perquè quedin ancorats a la seva ranura, i el pla plan-contoso-reservas-pro ha de ser Standard o superior (Contoso fa servir Premium v3 amb redundància de zona, així que compleix de sobres).

Les connexions sc-contoso-dev i sc-contoso-pro de 05-01 no són intercanviables, i cal impedir activament que es facin servir malament:

• Àmbit i rol mínims: sc-contoso-pro té Col·laborador de lloc web sobre rg-contoso-reservas-pro. Pot desplegar i intercanviar ranures; no pot tocar rg-contoso-red-pro ni esborrar una base de dades.
• Sense accés obert: en desactivar «concedir permís d'accés a totes les canalitzacions», una canalització nova no hereta la capacitat de desplegar en producció. Autoritzar-la és un acte explícit.
• Comprovació de connexió a l'entorn: la comprovació Required template o la restricció de la mateixa connexió permeten exigir que només es faci servir des d'una plantilla aprovada.
• Federació d'identitat de càrrega de treball: sense secret que caduqui ni que es pugui exfiltrar.

El principi és el mateix del mòdul 4 portat al lliurament: la credencial que desplega el web no hauria de poder fer res més que desplegar el web.

Aquí hi ha el punt on més desplegaments «sense interrupció» es trenquen. Durant un intercanvi blau-verd, i durant la finestra de reversió posterior, dues versions del codi conviuen contra la mateixa base de dades db-reservas. Per tant:

Tota migració d'esquema ha de ser compatible cap enrere: la versió anterior del codi ha de continuar funcionant amb l'esquema nou.

El patró que ho garanteix és expandir i contraure, en tres desplegaments separats. Suposa que Contoso necessita substituir la columna nombre_pasajero per nombre i apellidos:

Regles pràctiques: no reanomenar ni eliminar mai una columna al mateix desplegament que introdueix la seva substituta; no afegir mai una columna NOT NULL sense valor per defecte, perquè la versió antiga no l'omplirà; i executar les migracions abans de l'intercanvi, en un pas propi contra sql-contoso-reservas-pro des d'un agent de pool-contoso-privado —el servidor només és accessible per pe-sql-reservas— i amb la identitat administrada que vas aprendre a 04-02, no amb contrasenyes.

La conseqüència important: una migració destructiva trenca la reversió. Si el desplegament elimina una columna i cal tornar enrere, la versió anterior es trobarà un esquema que no entén. Amb expandir i contraure, l'intercanvi invers sempre funciona.

Desplegar i marcar l'execució en verd no vol dir que funcioni. Contoso hi afegeix dues verificacions:

• Comprovació de salut: curl -f https://www.contosoairlines.example/salud, que retorna error si el punt no respon 200. El punt /salud ha de comprovar dependències reals —connexió a db-reservas, accés a kv-contoso-pro— i no limitar-se a retornar «OK».
• Proves de fum: un grapat de peticions que exerciten el camí crític (buscar un vol, consultar disponibilitat) contra la ranura de preproducció abans de l'intercanvi, no després.

I quan alguna cosa falla, la reversió. Hi ha dues formes i no són equivalents:

El reintercanvi és literalment la mateixa tasca Swap Slots executada un altre cop, i per això convé tenir una canalització de reversió d'un sol pas, a punt per llançar sense pensar. Aquesta és la raó per la qual la mètrica DORA de temps de restauració de Contoso pot passar d'hores a menys d'un minut: no perquè l'equip sigui més ràpid arreglant, sinó perquè tornar enrere ja no consisteix a arreglar res.

Un advertiment: la reversió reverteix el codi, no les dades. Si la versió nova va escriure registres amb un format que l'anterior no entén, o si ja s'ha executat la fase de contracció, el reintercanvi no n'hi ha prou. D'aquí la disciplina de l'apartat anterior.

L'últim pas perquè desplegar deixi de fer por és separar dues coses que solem confondre: desplegar (que el codi sigui en producció) i activar (que els usuaris el facin servir). Una marca de característica és una condició al codi que encén o apaga una funcionalitat sense desplegar res:

Això habilita tres coses: que les branques de característica siguin curtes de debò —la feina a mitges es fusiona apagada—, que el desplegament canari es faci per percentatge d'usuaris sense infraestructura addicional, i que apagar una funcionalitat trencada sigui instantani i no requereixi reversió. Azure App Configuration ofereix aquest servei gestionat amb el seu gestor de característiques, filtres per percentatge i per grup d'usuaris, i integració directa amb App Service.

El cost és real i cal reconèixer-lo: cada marca és una bifurcació que multiplica els camins possibles del codi. Es gestionen com a deute —amb propietari i data de retirada— i s'eliminen tan bon punt la funcionalitat està consolidada.

Què es mesura després de tot això és matèria del mòdul 7: cada desplegament s'ha de veure a Azure Monitor i a Application Insights, amb les mètriques d'errors i latència abans i després de l'intercanvi. Sense aquesta realimentació, l'aprovació de la Marta continua sent una decisió a cegues.

• Recompilar a cada entorn. Trenca la garantia que el que s'ha provat és el que es desplega. La canalització de desplegament consumeix l'artefacte, mai el regenera.
• Posar les aprovacions al YAML. Qui editi el fitxer les podria treure. Les comprovacions viuen a l'entorn, que té els seus propis permisos.
• Migracions destructives al mateix desplegament. Trenquen la reversió justament quan la necessites. Expandir i contraure, sempre, en desplegaments separats.
• Un punt /salud que només retorna «OK». No comprova res. Ha de verificar les dependències reals: base de dades, magatzem de secrets, serveis externs crítics.
• Ranures sense ajustos de ranura marcats. La cadena de connexió de producció viatja a preproducció o a l'inrevés, i acabes escrivint a la base de dades equivocada.
• Aprovar per costum. Una aprovació que sempre es concedeix en dos segons no és una porta, és un clic. Si ningú no mira què entra, val més automatitzar i dedicar l'esforç a la telemetria.
• Consell: guarda una canalització de reversió d'un sol pas, i assaja-la. Una reversió que no s'ha provat mai no és una reversió.
• Consell: etiqueta automàticament el repositori en desplegar en producció; així la correspondència entre etiqueta, artefacte i entorn no depèn de ningú.

Contoso Millas (centro-coste=CC-2077) muntarà el seu desplegament continu. El seu equip són quatre desenvolupadors i un responsable d'infraestructura. El seu web té molt menys trànsit que el de reserves i la seva finestra de més ús és els dilluns al matí.

1. Quins entorns crearies i quina comprovació posaries a cadascun?
2. Recomanaries lliurament continu o desplegament continu? Justifica-ho amb les diferències respecte a Contoso Reserves.
3. On es configuren aquestes comprovacions i per què no al YAML?

Contoso desplega la versió 2.6.0, que inclou una migració que reanomena la columna codigo_reserva a localizador a db-reservas. Al cap de deu minuts apareix una errada greu al càlcul de tarifes i la Marta llança el reintercanvi de ranura. El web torna a la versió 2.5.0 i comença a fallar amb errors de columna inexistent.

1. Què ha passat exactament i per què el reintercanvi no ha bastat?
2. Reescriu el canvi amb expandir i contraure, indicant què fa cada desplegament.
3. Des de quin agent s'ha d'executar la migració contra sql-contoso-reservas-pro i amb quina credencial?

Contoso vol provar un algorisme nou de preus a l'API de Disponibilitat, que corre a vmss-api-disponibilidad-pro darrere de lb-api-disponibilidad-pro. El risc és alt: un error de preus té impacte econòmic directe. L'equip vol exposar-lo primer a una fracció del trànsit.

1. Quina estratègia de desplegament correspon i per què no blau-verd pur?
2. Com la combinaries amb una marca de característica?
3. Si l'algorisme falla amb el 5 % del trànsit, quina és la via de reversió més ràpida i per què?

Solució 1:

1. millas-desarrollo sense comprovacions, amb desplegament automàtic; millas-produccion amb comprovació de branca (només main) i aprovació del responsable d'infraestructura. La finestra de desplegament hauria d'excloure el dilluns al matí, que és el seu pic. Un entorn de preproducció és opcional atesa la mida de l'equip, encara que si fan servir ranures d'App Service el patró surt gairebé de franc i convé mantenir-lo.
2. Lliurament continu al principi, per la mateixa raó que Contoso Reserves: encara no hi ha telemetria ni reversió automàtica que justifiquin treure la porta humana. Amb menys trànsit i menor impacte econòmic, però, és un candidat raonable a desplegament continu un cop les seves proves automàtiques siguin sòlides i tinguin alertes; el criteri no és la mida de l'equip, és la capacitat de detectar i revertir de pressa.
3. A l'entorn d'Azure Pipelines, no al YAML, perquè el YAML el pot modificar qualsevol amb permís sobre el repositori: n'hi hauria prou d'enviar una sol·licitud de canvis que esborri l'aprovació. Les comprovacions de l'entorn tenen els seus propis permisos i són independents del codi.

Solució 2:

1. La migració va reanomenar la columna, és a dir, la va eliminar i en va crear una altra. L'esquema va quedar incompatible amb la versió 2.5.0, que continua consultant codigo_reserva. El reintercanvi reverteix el codi, però no reverteix l'esquema ni les dades: per això no va bastar. La reversió només funciona si tota migració és compatible cap enrere.
2. Desplegament 1 (expandir): afegir la columna localizador admetent nuls, conservant codigo_reserva; el codi escriu a totes dues i llegeix de codigo_reserva. Procés de migració: omplir localizador a les files històriques. Desplegament 2: el codi llegeix de localizador i continua escrivint a totes dues —aquí ja es pot revertir sense dany—. Desplegament 3 (contraure): el codi deixa d'escriure a codigo_reserva i, només després de confirmar que cap versió anterior no continua viva, s'elimina la columna.
3. Des d'un agent autoallotjat del grup pool-contoso-privado, situat a snet-gestion dins de vnet-contoso-pro, perquè sql-contoso-reservas-pro només és accessible a través de pe-sql-reservas i un agent allotjat per Microsoft no hi té ruta. La credencial ha de ser la identitat administrada de l'agent amb permisos d'Entra ID sobre la base de dades, mai una contrasenya d'administrador de SQL. I el pas va abans de l'intercanvi.

Solució 3:

1. Canari. El blau-verd pur commuta el 100 % del trànsit de cop: si l'algorisme calcula malament, tots els clients veuen preus erronis durant el temps que es trigui a detectar-ho. El canari limita l'exposició a una fracció i permet comparar mètriques entre les dues versions abans de continuar. A vmss-api-disponibilidad-pro s'implementa desplegant la versió nova en un subconjunt d'instàncies i ponderant el repartiment a lb-api-disponibilidad-pro, o publicant un grup d'instàncies nou i traslladant trànsit progressivament.
2. Amb una marca de característica per percentatge d'usuaris: es desplega el codi nou a totes les instàncies però apagat, i s'encén per a un 5 % des d'Azure App Configuration. Això és millor que el canari d'infraestructura perquè el repartiment es controla sense tocar el balancejador, es pot segmentar per tipus de client i totes les instàncies executen el mateix binari, cosa que elimina les diferències de configuració.
3. Apagar la marca de característica: és instantani, no requereix desplegament, no requereix intercanvi i no toca la infraestructura. Només si l'errada fos fora de la marca —en codi comú— caldria recórrer al reintercanvi de ranura o a retirar les instàncies canari del balancejador. És exactament l'avantatge de separar el desplegament de l'activació: la via de reversió més ràpida deixa de ser un desplegament.

L'artefacte ja no espera: viatja sol. Saps distingir el lliurament continu del desplegament continu i per què Contoso se situa en el primer amb una porta humana davant de producció, no per dogma sinó perquè encara li falta la telemetria i la reversió automàtica que justificarien treure-la. Has creat els entorns desarrollo, preproduccion i produccion, que aporten el que un simple pas de desplegament no dóna: el registre exacte de quina versió hi ha a cada lloc i un lloc on penjar les proteccions fora del YAML, de manera que qui edita la canalització no les pugui treure.

Sobre aquests entorns hi has posat comprovacions amb sentit: l'aprovació de la Marta Ríos amb el seu temps d'espera, la finestra de desplegament que converteix «intentem no desplegar els divendres» en una regla que es compleix sola, la comprovació de branca i les portes que consulten si hi ha una incidència oberta abans de deixar passar res. Has escrit la canalització contoso-reservas-cd de tres etapes encadenades amb dependsOn i condition, que consumeix l'artefacte de 05-03 sense recompilar i que en producció no copia fitxers sinó que intercanvia la ranura preproduccion amb el seu escalfament previ contra /salud: el blau-verd real de Contoso, comparat en taula amb la recreació, l'actualització gradual i el canari. Saps restringir sc-contoso-pro al rol i a l'àmbit mínims i a les canalitzacions autoritzades; saps que tota migració ha de ser compatible cap enrere amb el patró expandir i contraure, perquè una columna eliminada trenca la reversió justament quan la necessites; i saps que revertir de debò és un reintercanvi de segons, no un redesplegament de minuts —el motiu pel qual el temps de restauració de Contoso pot caure d'hores a menys d'un minut—. I amb les marques de característica has separat desplegar d'activar, deixant la via de reversió més ràpida de totes: un interruptor.

Queda un cap que aquest mòdul arrossega des del principi. Els quatre repositoris de Contoso comparteixen una biblioteca de models de reserva que està copiada i enganxada en tres d'ells, i ja hi ha tres versions diferents circulant: quan en Diego corregeix la validació del localitzador al web, l'API continua amb la versió vella i totes dues discrepen en producció. Les plantilles de canalització van resoldre això per al YAML; falta resoldre-ho per al codi. A la lliçó següent, Azure Artifacts, muntaràs el feed contoso-paquetes, publicaràs contoso.reservas.modelos com a paquet versionat des d'una canalització, promocionaràs versions entre les vistes @local, @prerelease i @release, i configuraràs els orígens ascendents que protegeixen Contoso que un paquet públic desaparegui i, sobretot, de l'atac de confusió de dependències.