Quatre mòduls després, la plataforma de Contoso Airlines està completa: còmput, dades, xarxa, identitat i governança. I tanmateix, cada desplegament continua sent un acte de fe. La Marta Ríos obre una sessió de Cloud Shell un divendres a la nit, hi enganxa una tanda d'ordres que guarda en un fitxer de text al portàtil, i espera. En Diego Salas li ha enviat un ZIP per correu amb la darrera versió de Contoso Reserves i un missatge: «aquest és el bo, el d'ahir tenia una errada». Ningú no sap del cert quina versió hi ha en producció ara mateix, i si alguna cosa es trenca a les onze de la nit l'única marxa enrere disponible és buscar el ZIP anterior a la safata d'entrada.

Aquest mòdul elimina aquesta escena. Azure DevOps és el conjunt de serveis que converteix el lliurament de programari en un procés repetible, auditable i avorrit —que és exactament el que ha de ser—. Però abans de tocar cap eina cal entendre que DevOps no és un producte que es compra: és una manera de treballar que l'eina habilita, i confondre les dues coses és la raó per la qual tantes adopcions fracassen amb les millors eines instal·lades.

1. DevOps és cultura abans que eina: els silos de Contoso
2. Mesurar la millora de manera honesta: les mètriques DORA
3. Què és Azure DevOps Services i els seus cinc serveis
4. Organització, projecte i estructura
5. Azure Boards: fer visible la feina
6. Usuaris, grups de seguretat i nivells d'accés
7. Connexions de servei: el pont cap a Azure
8. Azure DevOps davant de GitHub
9. El flux complet que Contoso muntarà
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Observa com treballa avui Contoso Airlines i hi veuràs un manual de tot allò que DevOps intenta corregir:

• En Diego desenvolupa al seu portàtil. El seu objectiu, mesurat pel seu cap, és lliurar funcionalitat de pressa. Quan acaba, «ho passa a sistemes».
• La Marta desplega els divendres a la nit. El seu objectiu, mesurat pel seu cap, és que la plataforma no caigui. Cada desplegament és un risc, així que agrupa canvis de tres setmanes en una sola finestra per minimitzar el nombre de finestres.
• Ningú no és amo del resultat. Si el web falla el dissabte, la Marta reinicia l'aplicació i truca al Diego, que no té accés als registres de producció.

El resultat és un cercle viciós perfectament lògic: com que desplegar fa mal, es desplega poc; com que es desplega poc, cada lliurament acumula molts canvis; com que cada lliurament acumula molts canvis, és més probable que falli i més difícil saber què l'ha trencat; com que falla, desplegar fa més mal. Els incentius dels dos equips estan enfrontats per disseny.

DevOps trenca aquest cercle invertint la intuïció: desplegar més sovint és més segur, no menys, perquè cada desplegament porta menys canvis i la seva reversió és trivial. Culturalment exigeix tres coses que cap eina no pot comprar per tu:

Si no es mesura, «hem adoptat DevOps» és una opinió. El programa de recerca DORA (DevOps Research and Assessment) va identificar quatre mètriques que prediuen el rendiment d'un equip de lliurament. La seva virtut és que són difícils de manipular i que es contrapesen entre elles: dues mesuren velocitat i dues, estabilitat.

Dos advertiments importants. El primer: no se n'optimitza una de sola. Desplegar cinquanta vegades al dia trencant-ne la meitat no és millorar; la parella velocitat-estabilitat es llegeix junta. El segon: són mètriques d'equip, no de persona. Tan bon punt es facin servir per avaluar el Diego, el Diego aprendrà a inflar-les i deixaran de significar res.

Azure DevOps Services és l'oferta SaaS de Microsoft per al cicle de vida complet del programari. També existeix Azure DevOps Server, la versió instal·lable al teu propi centre de dades —rellevant només si hi ha una restricció normativa que impedeixi el SaaS—. En aquest curs fem servir sempre Services.

No és un producte monolític: són cinc serveis que s'activen per separat i es poden fer servir de manera independent (és perfectament vàlid guardar el codi a GitHub i fer servir només Azure Pipelines).

Azure Test Plans mereix una nota: requereix una llicència addicional força cara per usuari i només compensa quan hi ha un equip de QA que executa plans de prova manuals formals. Contoso no l'activarà; les seves proves seran automàtiques i viuran a la canalització.

La jerarquia té tres nivells i convé decidir-la bé, perquè moure coses després és incòmode:

• Organització: el contenidor de facturació i d'usuaris, amb la seva pròpia URL dev.azure.com/contoso-airlines. Es vincula a un inquilí de Microsoft Entra ID —el mateix del mòdul 4— perquè l'accés el governin les identitats corporatives i no comptes personals solts.
• Projecte: el límit de seguretat i de visibilitat. Tot el que hi ha a dins es comparteix; el que hi ha en un altre projecte no es veu llevat de permís explícit.
• Repositoris, canalitzacions, feeds: els artefactes dins del projecte.

El dubte habitual és un projecte gran o molts de petits. La recomanació pràctica —i la que segueix Contoso— és pocs projectes grans: un producte, un projecte, amb molts repositoris a dins. Molts projectes petits fragmenten els taulers, obliguen a duplicar configuració i compliquen compartir paquets. Contoso crea contoso-reservas per a la plataforma de venda i deixarà contoso-millas (el projecte d'exercicis, centro-coste=CC-2077) com a segon producte separat, perquè té un altre equip, un altre pressupost i un altre cicle.

La creació es fa des del portal (dev.azure.com), però també amb l'extensió azure-devops de la CLI que ja domines:

--visibility private és innegociable: public obre el projecte a Internet sense autenticació, una cosa pensada per a projectes de codi obert. --process Agile tria la plantilla de treball que veurem ara i no es pot canviar lliurement després, així que convé pensar-la.

Boards és on viu el perquè de cada canvi. Sense ell, d'aquí a sis mesos ningú no recordarà per què l'API de Disponibilitat desa les tarifes a la memòria cau durant 90 segons exactes.

Un element de treball és qualsevol unitat rastrejable: una funcionalitat, un error, una tasca. S'organitzen en jerarquia, i en el procés Agile la de Contoso queda així:

• Èpica: un objectiu de negoci, de mesos. «Venda de bitllets en línia a Azure».
• Característica: una capacitat lliurable, de setmanes.
• Història d'usuari: valor per a un usuari, de dies. S'escriu en format «Com a rol vull acció per a benefici» i porta criteris d'acceptació: la llista concreta de condicions que s'han de complir per donar-la per bona. Sense criteris d'acceptació, «acabat» és una opinió.
• Tasca: feina tècnica d'hores, que és el que s'estima i se segueix diàriament.
• Error: un defecte. Es pot tractar com a història (apareix al backlog al costat d'elles) o com a tasca, segons la configuració.

Contoso tria Agile: té vocabulari reconeixible, admet tant sprints com flux continu i no imposa la cerimònia de CMMI, que seria desproporcionada per a un equip de set persones.

El tauler (board) és la vista Kanban: columnes Nou → Actiu → Resolt → Tancat que s'arrosseguen. Dos ajustos el fan útil de debò:

• Límits de treball en curs (WIP): un màxim de targetes per columna. Si «Actiu» és ple, ningú no comença res de nou fins que alguna cosa avanci. És l'eina més eficaç contra l'equip que té quinze coses començades i cap d'acabada.
• Definició de llest i d'acabat: escrites a la mateixa columna, perquè «resolt» signifiqui el mateix per al Diego i per a la Marta.

Els sprints (iteracions) agrupen feina en finestres fixes —Contoso fa servir dues setmanes— amb la seva capacitat per persona i el seu gràfic de treball pendent. Les consultes permeten preguntes del tipus «errors oberts de prioritat 1 assignats al meu equip» i alimenten els taulers d'indicadors.

Aquí hi ha el valor real de Boards, i és la raó per la qual apareix en aquesta lliçó i no com a nota al peu. Quan en Diego escriu a la seva confirmació de Git:

La referència AB#1842 fa que Azure DevOps enllaci automàticament la confirmació amb l'element de treball 1842 i, si la paraula clau és Fixes, el tanqui en fusionar. A partir d'aquí la cadena és completa:

element de treball → confirmació → sol·licitud d'incorporació de canvis → compilació → versió desplegada → entorn

Això vol dir que la pregunta «per què és aquí aquesta línia?» i la pregunta «quins canvis van entrar al desplegament de dimarts?» tenen resposta automàtica. Quan a 05-02 configurem la directiva de branca que exigeix vincular un element de treball per poder fusionar, aquesta cadena deixa de dependre de la disciplina de ningú.

Dos conceptes que es confonen constantment i que convé separar des del principi:

• Nivell d'accés: quins serveis pot fer servir una persona. És el que es factura.
• Grup de seguretat / permisos: què hi pot fer a dins. És gratis.

Avís de cost: els cinc usuaris Bàsics gratuïts són per organització, no per projecte. L'error clàssic és donar Bàsic a tothom: la Nuria Peña, de l'àrea financera, només necessita veure l'avenç i aprovar la despesa, així que amb Parts interessades en té prou i no costa res. Revisa els nivells d'accés trimestralment i allibera els de qui ja no hi participa; la facturació no ho fa sola.

Els grups de seguretat integrats a cada projecte són Readers, Contributors, Build Administrators i Project Administrators. Igual que amb RBAC al mòdul 4, la regla és assignar a grups, mai a persones, i —millor encara— fer que aquests grups d'Azure DevOps s'alimentin dels grups de Microsoft Entra ID que ja existeixen: Contoso-Desarrollo com a Contributors, Contoso-Infraestructura com a Project Administrators, Contoso-Operaciones com a aprovadors de producció. Una sola alta d'empleat a Entra ID li dóna el que necessita en els dos plans.

Aquest apartat és el més important de la lliçó per a la resta del mòdul. Una canalització que desplega a Azure necessita autenticar-se contra Azure. Una connexió de servei és aquesta credencial, guardada al projecte i referenciada pel nom des del YAML.

Hi ha dues maneres d'establir-la, i la diferència és de seguretat, no de comoditat:

La federació funciona amb el mateix principi que les identitats administrades de 04-02: en lloc de guardar una contrasenya, s'estableix una relació de confiança entre l'emissor de testimonis d'Azure DevOps i una aplicació de Microsoft Entra ID. Quan la canalització s'executa, Azure DevOps emet un testimoni de vida curta que acredita «sóc l'execució de la canalització X del projecte Y», Entra ID el valida contra la confiança configurada i retorna un testimoni d'accés a Azure. En cap punt no existeix un secret que es pugui filtrar ni caducar. És la mateixa idea de «sense claus ni contrasenyes» que va portar Contoso a desactivar allow-shared-key-access als seus comptes d'emmagatzematge, aplicada ara al desplegament.

Contoso crea dues connexions, i aquí el mínim privilegi del mòdul 4 s'aplica literalment:

Fixa't en dues decisions. Primer, l'àmbit és el grup de recursos, no la subscripció: la canalització de reserves no té cap motiu per poder tocar rg-contoso-red-pro ni rg-contoso-seguridad-pro. Segon, en producció el rol és Col·laborador de lloc web i no Col·laborador: la canalització necessita desplegar aplicacions, no crear bases de dades ni esborrar xarxes. Quan a 05-06 la canalització de Bicep necessiti crear infraestructura, tindrà la seva pròpia connexió amb més permisos i aprovacions més estrictes, en lloc d'ampliar aquesta.

A més, les connexions de servei es poden restringir a canalitzacions concretes (desactivant el permís d'accés obert a totes), de manera que una canalització nova creada per qualsevol no hereti automàticament la capacitat de desplegar en producció. Ho veurem a 05-04.

Microsoft és propietària de tots dos, cosa que genera confusió legítima. Cap dels dos no desapareixerà, però la inversió en producte és clarament a GitHub.

Quan triar cadascun, sense autoenganys:

• Azure DevOps si necessites seguiment de feina empresarial amb jerarquies i traçabilitat formal, si ja tens anys d'història a dins, o si el teu entorn regulat exigeix Azure DevOps Server autoallotjat.
• GitHub si comences de zero avui, si el teu equip ja hi viu, si el projecte és obert o si vols Advanced Security.
• Combinat, que és molt habitual: codi i Issues a GitHub, desplegament amb Azure Pipelines per la seva maduresa en entorns, aprovacions i agents dins de la xarxa virtual.

Contoso tria Azure DevOps complet per una raó concreta: necessita traçabilitat auditable entre requisit, canvi i desplegament per a la seva certificació PCI DSS (04-05), i Boards l'hi dóna sense feina extra. L'important és que els conceptes d'aquest mòdul es traslladen gairebé un a un a GitHub Actions: canvia la sintaxi, no la idea.

Aquest és el destí del mòdul. Tot el que ve després és implementar aquest diagrama.

Traduït a l'escena del principi: en Diego ja no envia cap ZIP; la Marta ja no enganxa ordres un divendres; i la pregunta «quina versió hi ha en producció» té una resposta exacta a la pantalla de l'entorn produccion.

• Creure que instal·lar l'eina és adoptar DevOps. Si en Diego continua «passant coses a sistemes» i la Marta continua sent l'única que pot desplegar, tindràs els mateixos silos amb una interfície més bonica. L'automatització sense canvi de responsabilitats només accelera el procés vell.
• Crear un projecte per microservei. Multiplica configuració, fragmenta els taulers i complica compartir paquets. Un producte, un projecte, molts repositoris.
• Donar nivell Bàsic a tothom. És la fuita de cost silenciosa més freqüent a Azure DevOps. Qui només consulta o aprova, amb Parts interessades en té prou i és gratis.
• Assignar permisos a persones. Igual que a RBAC: a grups, i si pot ser grups sincronitzats des de Microsoft Entra ID.
• Fer servir entitats de servei amb secret per costum. Caduquen, i sempre ho fan en el pitjor moment. Fes servir federació d'identitat de càrrega de treball des del primer dia.
• Donar Col·laborador de la subscripció a la connexió de servei «perquè no falli res». És l'equivalent a un sudo permanent per a qualsevol que pugui editar un YAML. Àmbit mínim i rol mínim.
• Fer servir les mètriques DORA per avaluar persones. Es converteixen en objectiu, deixen de mesurar la realitat i enverinen la cultura que pretenien millorar.
• Consell: activa només els serveis que faràs servir. Un projecte amb Boards, Repos, Pipelines i Artifacts actius i Test Plans desactivat és més net i evita llicències cares per accident.
• Consell: escriu la definició d'acabat a la mateixa columna del tauler abans de la primera setmana. Són cinc minuts de feina que estalvien mesos de discussions sobre què significa «resolt».

L'equip de Contoso Millas (projecte d'exercicis, centro-coste=CC-2077) mesura les seves quatre mètriques DORA i obté: freqüència de desplegament 1 vegada al mes, temps de lliurament 32 dies, temps de restauració 6 hores, taxa d'errada 40 %.

1. Què et diuen conjuntament aquests quatre números sobre la seva manera de treballar?
2. Quina atacaries primer i per què?
3. Quin servei d'Azure DevOps ataca cadascuna de les quatre?

Contoso Millas s'incorpora a l'organització contoso-airlines. El seu equip són quatre desenvolupadors, un responsable d'infraestructura i la Nuria Peña, que només vol veure l'avenç i aprovar la despesa. Desplegaran al grup de recursos rg-contoso-millas-dev.

1. Projecte nou o repositoris dins de contoso-reservas? Justifica-ho.
2. Assigna nivell d'accés a cada persona i calcula el cost mensual addicional aproximat, sabent que l'organització ja consumeix els seus cinc Bàsics gratuïts.
3. Defineix la connexió de servei: nom, tipus d'autenticació, àmbit i rol.

Auditoria de PCI DSS. L'auditor assenyala un canvi en el càlcul de tarifes desplegat en producció el 14 de març i pregunta quin requisit de negoci el va motivar, qui el va revisar i quina versió es va desplegar. L'equip només pot ensenyar una confirmació titulada «fix tarifes» sense més context.

1. Quines baules concretes falten a la cadena de traçabilitat?
2. Enumera els tres mecanismes d'Azure DevOps que haurien donat la resposta automàticament.
3. Quina configuració concreta impedeix que això torni a passar, i en quina lliçó del mòdul s'implementa?

Solució 1:

1. Que formen un cercle coherent: despleguen poc perquè desplegar és car i arriscat, així que cada lliurament acumula un mes de canvis, i per això quatre de cada deu fallen i recuperar-se costa sis hores —hi ha massa canvis sospitosos per revisar—. Les quatre mètriques són símptomes del mateix problema, no quatre problemes.
2. El temps de restauració, encara que sembli contraintuïtiu. Mentre recuperar-se costi sis hores, l'equip tindrà por de desplegar i tota la resta està bloquejada. Reduir-lo a minuts (reversió automàtica, intercanvi de ranura, 05-04) elimina la por, i amb la por eliminada la freqüència puja sola i la resta de números millora en cascada.
3. Freqüència i temps de lliurament: Pipelines (integració i desplegament continus) i Repos (branques curtes). Temps de restauració: Pipelines amb entorns i reversió, més el monitoratge del mòdul 7. Taxa d'errada: Pipelines amb proves automàtiques i Repos amb revisió obligatòria per directiva de branca.

Solució 2:

1. Projecte nou contoso-millas: un altre equip, un altre pressupost (CC-2077), un altre cicle de lliurament i la necessitat que el seu backlog no es barregi amb el de reserves. La regla de «pocs projectes grans» s'aplica dins d'un producte; aquí són dos productes diferents. Si compartissin equip i planificació, la resposta seria repositoris dins de contoso-reservas.
2. Els quatre desenvolupadors i el responsable d'infraestructura necessiten Bàsic (codi i canalitzacions): són cinc. La Nuria Peña, Parts interessades: veu la feina i pot aprovar desplegaments, sense accés al codi, i és gratuïta. Com que els cinc Bàsics gratuïts ja estan consumits, el cost addicional és 5 × ~6 $/mes ≈ 30 $/mes. Si a la Nuria se li donés Bàsic «per si de cas», serien 36 $ sense cap capacitat addicional que ella hagi de fer servir.
3. Nom sc-contoso-millas-dev; autenticació per federació d'identitat de càrrega de treball (sense secret que caduqui o es filtri); àmbit el grup de recursos rg-contoso-millas-dev, mai la subscripció; rol Col·laborador en desenvolupament, i una connexió diferent i més restringida per a producció quan arribi. A més, restringir la connexió a les canalitzacions concretes que l'hagin de fer servir.

Solució 3:

1. En falten tres: l'element de treball que explica el perquè del canvi (requisit, criteris d'acceptació, qui el va demanar); la revisió d'un segon parell d'ulls amb el seu registre de conversa; i la relació entre la versió desplegada i la confirmació, que permetria afirmar quin codi exacte hi havia en producció aquell dia.
2. (a) El vincle confirmació–element de treball mitjançant AB#<id> al missatge de la confirmació. (b) La sol·licitud d'incorporació de canvis, que registra revisors, comentaris i decisions. (c) L'entorn d'Azure Pipelines, que guarda quina execució i quin artefacte es van desplegar a produccion i quan, amb enllaç de tornada a les confirmacions incloses.
3. Una directiva de branca sobre main que exigeixi alhora element de treball vinculat, un mínim de revisors i compilació amb validació correcta; s'implementa a 05-02, i el registre del desplegament per entorn, a 05-04. La clau és que la traçabilitat deixa de dependre que algú se'n recordi: sense els tres requisits, la fusió senzillament no es permet.

Has vist que DevOps és abans que res una manera de treballar: els silos de Contoso —en Diego lliurant un ZIP, la Marta desplegant els divendres a la nit i ningú no sabent què hi ha en producció— no s'arreglen comprant una eina, sinó canviant responsabilitats, automatitzant el repetitiu i escurçant els bucles de realimentació. I has après a mesurar aquesta millora honestament amb les quatre mètriques DORA, llegint juntes velocitat i estabilitat, i sense fer-les servir mai per avaluar persones.

Sobre aquesta base has conegut Azure DevOps Services i els seus cinc serveis —Boards, Repos, Pipelines, Test Plans i Artifacts—, has creat l'organització contoso-airlines i el projecte contoso-reservas amb procés Agile, i has entrat a fons a Azure Boards: la jerarquia èpica → característica → història d'usuari → tasca amb els seus criteris d'acceptació, els taulers amb límits de treball en curs, els sprints i, sobretot, el vincle AB#1842 entre confirmació i element de treball que converteix la traçabilitat en una cosa automàtica. Has separat nivells d'accés (el que es factura) de permisos (el que és gratis), sabent que Parts interessades cobreix qui només consulta i aprova, i que els grups han de venir de Microsoft Entra ID. I has muntat el pont que sostindrà tot el mòdul: les connexions de servei sc-contoso-dev i sc-contoso-pro, amb federació d'identitat de càrrega de treball en lloc de secrets que caduquen, i amb l'àmbit i el rol mínims —la mateixa disciplina del mòdul 4 aplicada al lliurament—.

El flux està dibuixat, però encara no existeix. I la seva primera baula és la més bàsica i la que avui falta per complet a Contoso: un lloc únic i fiable on visqui el codi, amb història, amb revisió i amb regles que no depenguin de la bona voluntat. A la lliçó següent, Azure Repos, crearàs el repositori contoso-reservas, migraràs el repositori local d'en Diego conservant-ne l'historial, triaràs l'estratègia de ramificació de l'equip i —el més important— posaràs directives sobre la branca main perquè cap canvi no arribi a producció sense revisió, sense element de treball vinculat i sense haver compilat correctament. Aquí és on el ZIP per correu desapareix per sempre.