Cuatro módulos después, la plataforma de Contoso Airlines está completa: cómputo, datos, red, identidad y gobierno. Y sin embargo, cada despliegue sigue siendo un acto de fe. Marta Ríos abre una sesión de Cloud Shell un viernes por la noche, pega una tanda de comandos que guarda en un fichero de texto en su portátil, y espera. Diego Salas le ha enviado un ZIP por correo con la última versión de Contoso Reservas y un mensaje: «este es el bueno, el de ayer tenía un fallo». Nadie sabe con certeza qué versión hay en producción ahora mismo, y si algo se rompe a las once de la noche la única marcha atrás disponible es buscar el ZIP anterior en la bandeja de entrada.

Este módulo elimina esa escena. Azure DevOps es el conjunto de servicios que convierte la entrega de software en un proceso repetible, auditable y aburrido —que es exactamente lo que debe ser—. Pero antes de tocar ninguna herramienta hay que entender que DevOps no es un producto que se compra: es una forma de trabajar que la herramienta habilita, y confundir ambas cosas es la razón por la que tantas adopciones fracasan con las mejores herramientas instaladas.

1. DevOps es cultura antes que herramienta: los silos de Contoso
2. Medir la mejora de forma honesta: las métricas DORA
3. Qué es Azure DevOps Services y sus cinco servicios
4. Organización, proyecto y estructura
5. Azure Boards: hacer visible el trabajo
6. Usuarios, grupos de seguridad y niveles de acceso
7. Conexiones de servicio: el puente hacia Azure
8. Azure DevOps frente a GitHub
9. El flujo completo que Contoso va a montar
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Observa cómo trabaja hoy Contoso Airlines y verás un manual de todo lo que DevOps intenta corregir:

• Diego desarrolla en su portátil. Su objetivo, medido por su jefe, es entregar funcionalidad rápido. Cuando termina, «lo pasa a sistemas».
• Marta despliega los viernes por la noche. Su objetivo, medido por su jefe, es que la plataforma no se caiga. Cada despliegue es un riesgo, así que agrupa cambios de tres semanas en una sola ventana para minimizar el número de ventanas.
• Nadie es dueño del resultado. Si la web falla el sábado, Marta reinicia la aplicación y llama a Diego, que no tiene acceso a los registros de producción.

El resultado es un círculo vicioso perfectamente lógico: como desplegar duele, se despliega poco; como se despliega poco, cada entrega acumula muchos cambios; como cada entrega acumula muchos cambios, es más probable que falle y más difícil saber qué la rompió; como falla, desplegar duele más. Los incentivos de ambos equipos están enfrentados por diseño.

DevOps rompe ese círculo invirtiendo la intuición: desplegar más a menudo es más seguro, no menos, porque cada despliegue lleva menos cambios y su reversión es trivial. Culturalmente exige tres cosas que ninguna herramienta puede comprar por ti:

Si no se mide, «hemos adoptado DevOps» es una opinión. El programa de investigación DORA (DevOps Research and Assessment) identificó cuatro métricas que predicen el rendimiento de un equipo de entrega. Su virtud es que son difíciles de manipular y que se contrapesan entre sí: dos miden velocidad y dos, estabilidad.

Dos advertencias importantes. La primera: no se optimiza una sola. Desplegar cincuenta veces al día rompiendo la mitad no es mejorar; la pareja velocidad-estabilidad se lee junta. La segunda: son métricas de equipo, no de persona. En cuanto se usan para evaluar a Diego, Diego aprenderá a inflarlas y dejarán de significar nada.

Azure DevOps Services es la oferta SaaS de Microsoft para el ciclo de vida completo del software. Existe también Azure DevOps Server, la versión instalable en tu propio centro de datos —relevante solo si hay una restricción normativa que impida el SaaS—. En este curso usamos siempre Services.

No es un producto monolítico: son cinco servicios que se activan por separado y se pueden usar de forma independiente (es perfectamente válido guardar el código en GitHub y usar solo Azure Pipelines).

Azure Test Plans merece una nota: requiere una licencia adicional bastante cara por usuario y solo compensa cuando existe un equipo de QA que ejecuta planes de prueba manuales formales. Contoso no lo activará; sus pruebas serán automáticas y vivirán en el pipeline.

La jerarquía tiene tres niveles y conviene decidirla bien, porque mover cosas después es incómodo:

• Organización: el contenedor de facturación y de usuarios, con su propia URL dev.azure.com/contoso-airlines. Se vincula a un inquilino de Microsoft Entra ID —el mismo del módulo 4— para que el acceso lo gobiernen las identidades corporativas y no cuentas personales sueltas.
• Proyecto: el límite de seguridad y de visibilidad. Todo lo que hay dentro se comparte; lo que hay en otro proyecto no se ve salvo permiso explícito.
• Repositorios, pipelines, feeds: los artefactos dentro del proyecto.

La duda habitual es un proyecto grande o muchos pequeños. La recomendación práctica —y la que sigue Contoso— es pocos proyectos grandes: un producto, un proyecto, con muchos repositorios dentro. Muchos proyectos pequeños fragmentan los paneles, obligan a duplicar configuración y complican compartir paquetes. Contoso crea contoso-reservas para la plataforma de venta y dejará contoso-millas (el proyecto de ejercicios, centro-coste=CC-2077) como segundo producto separado, porque tiene otro equipo, otro presupuesto y otro ciclo.

La creación se hace desde el portal (dev.azure.com), pero también con la extensión azure-devops de la CLI que ya dominas:

--visibility private es innegociable: public abre el proyecto a Internet sin autenticación, algo pensado para proyectos de código abierto. --process Agile elige la plantilla de trabajo que veremos ahora y no se puede cambiar libremente después, así que conviene pensarla.

Boards es donde vive el porqué de cada cambio. Sin él, dentro de seis meses nadie recordará por qué la API de Disponibilidad cachea las tarifas durante 90 segundos exactos.

Un elemento de trabajo es cualquier unidad rastreable: una funcionalidad, un error, una tarea. Se organizan en jerarquía, y en el proceso Agile la de Contoso queda así:

• Épica: un objetivo de negocio, de meses. «Venta de billetes en línea en Azure».
• Característica: una capacidad entregable, de semanas.
• Historia de usuario: valor para un usuario, de días. Se escribe en formato «Como rol quiero acción para beneficio» y lleva criterios de aceptación: la lista concreta de condiciones que deben cumplirse para darla por buena. Sin criterios de aceptación, «terminado» es una opinión.
• Tarea: trabajo técnico de horas, que es lo que se estima y se sigue a diario.
• Error: un defecto. Se puede tratar como historia (aparece en el backlog junto a ellas) o como tarea, según configuración.

Contoso elige Agile: tiene vocabulario reconocible, admite tanto sprints como flujo continuo y no impone la ceremonia de CMMI, que sería desproporcionada para un equipo de siete personas.

El panel (board) es la vista Kanban: columnas Nuevo → Activo → Resuelto → Cerrado que se arrastran. Dos ajustes lo hacen útil de verdad:

• Límites de trabajo en curso (WIP): un máximo de tarjetas por columna. Si «Activo» está lleno, nadie empieza nada nuevo hasta que algo avance. Es la herramienta más eficaz contra el equipo que tiene quince cosas empezadas y ninguna terminada.
• Definición de listo y de terminado: escritas en la propia columna, para que «resuelto» signifique lo mismo para Diego y para Marta.

Los sprints (iteraciones) agrupan trabajo en ventanas fijas —Contoso usa dos semanas— con su capacidad por persona y su gráfico de trabajo pendiente. Las consultas permiten preguntas del tipo «errores abiertos de prioridad 1 asignados a mi equipo» y alimentan los paneles de indicadores.

Aquí está el valor real de Boards, y es la razón por la que aparece en esta lección y no como nota al pie. Cuando Diego escribe en su confirmación de Git:

La referencia AB#1842 hace que Azure DevOps enlace automáticamente la confirmación con el elemento de trabajo 1842 y, si la palabra clave es Fixes, lo cierre al fusionar. A partir de ahí la cadena está completa:

elemento de trabajo → confirmación → solicitud de incorporación de cambios → compilación → versión desplegada → entorno

Eso significa que la pregunta «¿por qué está esta línea aquí?» y la pregunta «¿qué cambios entraron en el despliegue del martes?» tienen respuesta automática. Cuando en 05-02 configuremos la directiva de rama que exige vincular un elemento de trabajo para poder fusionar, esa cadena deja de depender de la disciplina de nadie.

Dos conceptos que se confunden constantemente y que conviene separar desde el principio:

• Nivel de acceso: qué servicios puede usar una persona. Es lo que se factura.
• Grupo de seguridad / permisos: qué puede hacer dentro de ellos. Es gratis.

Aviso de coste: los cinco usuarios Básicos gratuitos son por organización, no por proyecto. El error clásico es dar Básico a todo el mundo: Nuria Peña, del área financiera, solo necesita ver el avance y aprobar el gasto, así que Partes interesadas le basta y no cuesta nada. Revisa los niveles de acceso trimestralmente y libera los de quien ya no participa; la facturación no lo hace sola.

Los grupos de seguridad integrados en cada proyecto son Readers, Contributors, Build Administrators y Project Administrators. Igual que con RBAC en el módulo 4, la regla es asignar a grupos, nunca a personas, y —mejor aún— hacer que esos grupos de Azure DevOps se alimenten de los grupos de Microsoft Entra ID que ya existen: Contoso-Desarrollo como Contributors, Contoso-Infraestructura como Project Administrators, Contoso-Operaciones como aprobadores de producción. Una sola alta de empleado en Entra ID le da lo que necesita en los dos planos.

Este apartado es el más importante de la lección para el resto del módulo. Un pipeline que despliega en Azure necesita autenticarse contra Azure. Una conexión de servicio es esa credencial, guardada en el proyecto y referenciada por nombre desde el YAML.

Hay dos formas de establecerla, y la diferencia es de seguridad, no de comodidad:

La federación funciona con el mismo principio que las identidades administradas de 04-02: en lugar de guardar una contraseña, se establece una relación de confianza entre el emisor de tokens de Azure DevOps y una aplicación de Microsoft Entra ID. Cuando el pipeline se ejecuta, Azure DevOps emite un token de corta vida que acredita «soy la ejecución del pipeline X del proyecto Y», Entra ID lo valida contra la confianza configurada y devuelve un token de acceso a Azure. En ningún punto existe un secreto que pueda filtrarse ni caducar. Es la misma idea de «sin claves ni contraseñas» que llevó a Contoso a desactivar allow-shared-key-access en sus cuentas de almacenamiento, aplicada ahora al despliegue.

Contoso crea dos conexiones, y aquí el mínimo privilegio del módulo 4 se aplica literalmente:

Fíjate en dos decisiones. Primero, el ámbito es el grupo de recursos, no la suscripción: el pipeline de reservas no tiene ningún motivo para poder tocar rg-contoso-red-pro ni rg-contoso-seguridad-pro. Segundo, en producción el rol es Colaborador de sitio web y no Colaborador: el pipeline necesita desplegar aplicaciones, no crear bases de datos ni borrar redes. Cuando en 05-06 el pipeline de Bicep necesite crear infraestructura, tendrá su propia conexión con más permisos y aprobaciones más estrictas, en lugar de ampliar esta.

Además, las conexiones de servicio pueden restringirse a pipelines concretos (desactivando el permiso de acceso abierto a todos), de modo que un pipeline nuevo creado por cualquiera no herede automáticamente la capacidad de desplegar en producción. Lo veremos en 05-04.

Microsoft es dueña de ambos, lo que genera confusión legítima. Ninguno va a desaparecer, pero la inversión en producto está claramente en GitHub.

Cuándo elegir cada uno, sin autoengaños:

• Azure DevOps si necesitas seguimiento de trabajo empresarial con jerarquías y trazabilidad formal, si ya tienes años de historia dentro, o si tu entorno regulado exige Azure DevOps Server autoalojado.
• GitHub si empiezas de cero hoy, si tu equipo ya vive allí, si el proyecto es abierto o si quieres Advanced Security.
• Combinado, que es muy habitual: código e Issues en GitHub, despliegue con Azure Pipelines por su madurez en entornos, aprobaciones y agentes dentro de la red virtual.

Contoso elige Azure DevOps completo por una razón concreta: necesita trazabilidad auditable entre requisito, cambio y despliegue para su certificación PCI DSS (04-05), y Boards se la da sin trabajo extra. Lo importante es que los conceptos de este módulo se trasladan casi uno a uno a GitHub Actions: cambia la sintaxis, no la idea.

Este es el destino del módulo. Todo lo que viene después es implementar este diagrama.

Traducido a la escena del principio: Diego ya no envía ZIP alguno; Marta ya no pega comandos un viernes; y la pregunta «qué versión hay en producción» tiene una respuesta exacta en la pantalla del entorno produccion.

• Creer que instalar la herramienta es adoptar DevOps. Si Diego sigue «pasando cosas a sistemas» y Marta sigue siendo la única que puede desplegar, tendrás los mismos silos con una interfaz más bonita. La automatización sin cambio de responsabilidades solo acelera el proceso viejo.
• Crear un proyecto por microservicio. Multiplica configuración, fragmenta los paneles y complica compartir paquetes. Un producto, un proyecto, muchos repositorios.
• Dar nivel Básico a todo el mundo. Es la fuga de coste silenciosa más frecuente en Azure DevOps. Quien solo consulta o aprueba, con Partes interesadas basta y es gratis.
• Asignar permisos a personas. Igual que en RBAC: a grupos, y a ser posible grupos sincronizados desde Microsoft Entra ID.
• Usar entidades de servicio con secreto por costumbre. Caducan, y siempre lo hacen en el peor momento. Usa federación de identidad de carga de trabajo desde el primer día.
• Dar Colaborador de la suscripción a la conexión de servicio «para que no falle nada». Es el equivalente a un sudo permanente para cualquiera que pueda editar un YAML. Ámbito mínimo y rol mínimo.
• Usar las métricas DORA para evaluar personas. Se convierten en objetivo, dejan de medir la realidad y envenenan la cultura que pretendían mejorar.
• Consejo: activa solo los servicios que vayas a usar. Un proyecto con Boards, Repos, Pipelines y Artifacts activos y Test Plans desactivado es más limpio y evita licencias caras por accidente.
• Consejo: escribe la definición de terminado en la propia columna del panel antes de la primera semana. Es cinco minutos de trabajo que ahorra meses de discusiones sobre qué significa «resuelto».

El equipo de Contoso Millas (proyecto de ejercicios, centro-coste=CC-2077) mide sus cuatro métricas DORA y obtiene: frecuencia de despliegue 1 vez al mes, tiempo de entrega 32 días, tiempo de restauración 6 horas, tasa de fallo 40 %.

1. ¿Qué te dicen conjuntamente estos cuatro números sobre su forma de trabajar?
2. ¿Cuál atacarías primero y por qué?
3. ¿Qué servicio de Azure DevOps ataca cada una de las cuatro?

Contoso Millas se incorpora a la organización contoso-airlines. Su equipo son cuatro desarrolladores, un responsable de infraestructura y Nuria Peña, que solo quiere ver el avance y aprobar el gasto. Desplegarán en el grupo de recursos rg-contoso-millas-dev.

1. ¿Proyecto nuevo o repositorios dentro de contoso-reservas? Justifícalo.
2. Asigna nivel de acceso a cada persona y calcula el coste mensual adicional aproximado, sabiendo que la organización ya consume sus cinco Básicos gratuitos.
3. Define la conexión de servicio: nombre, tipo de autenticación, ámbito y rol.

Auditoría de PCI DSS. El auditor señala un cambio en el cálculo de tarifas desplegado en producción el 14 de marzo y pregunta qué requisito de negocio lo motivó, quién lo revisó y qué versión se desplegó. El equipo solo puede enseñar una confirmación titulada «fix tarifas» sin más contexto.

1. ¿Qué eslabones concretos faltan en la cadena de trazabilidad?
2. Enumera los tres mecanismos de Azure DevOps que habrían dado la respuesta automáticamente.
3. ¿Qué configuración concreta impide que esto vuelva a ocurrir, y en qué lección del módulo se implementa?

Solución 1:

1. Que forman un círculo coherente: despliegan poco porque desplegar es caro y arriesgado, así que cada entrega acumula un mes de cambios, y por eso cuatro de cada diez fallan y recuperarse cuesta seis horas —hay demasiados cambios sospechosos que revisar—. Las cuatro métricas son síntomas del mismo problema, no cuatro problemas.
2. El tiempo de restauración, aunque parezca contraintuitivo. Mientras recuperarse cueste seis horas, el equipo tendrá miedo a desplegar y todo lo demás está bloqueado. Reducirlo a minutos (reversión automática, intercambio de ranura, 05-04) elimina el miedo, y con el miedo eliminado la frecuencia sube sola y el resto de números mejora en cascada.
3. Frecuencia y tiempo de entrega: Pipelines (integración y despliegue continuos) y Repos (ramas cortas). Tiempo de restauración: Pipelines con entornos y reversión, más la monitorización del módulo 7. Tasa de fallo: Pipelines con pruebas automáticas y Repos con revisión obligatoria por directiva de rama.

Solución 2:

1. Proyecto nuevo contoso-millas: otro equipo, otro presupuesto (CC-2077), otro ciclo de entrega y necesidad de que su backlog no se mezcle con el de reservas. La regla de «pocos proyectos grandes» se aplica dentro de un producto; aquí son dos productos distintos. Si compartieran equipo y planificación, la respuesta sería repositorios dentro de contoso-reservas.
2. Los cuatro desarrolladores y el responsable de infraestructura necesitan Básico (código y pipelines): son cinco. Nuria Peña, Partes interesadas: ve el trabajo y puede aprobar despliegues, sin acceso al código, y es gratuita. Como los cinco Básicos gratuitos ya están consumidos, el coste adicional es 5 × ~6 $/mes ≈ 30 $/mes. Si a Nuria se le diera Básico «por si acaso», serían 36 $ sin ninguna capacidad adicional que ella vaya a usar.
3. Nombre sc-contoso-millas-dev; autenticación por federación de identidad de carga de trabajo (sin secreto que caduque o se filtre); ámbito el grupo de recursos rg-contoso-millas-dev, nunca la suscripción; rol Colaborador en desarrollo, y una conexión distinta y más restringida para producción cuando llegue. Además, restringir la conexión a los pipelines concretos que deban usarla.

Solución 3:

1. Faltan tres: el elemento de trabajo que explica el porqué del cambio (requisito, criterios de aceptación, quién lo pidió); la revisión de un segundo par de ojos con su registro de conversación; y la relación entre la versión desplegada y la confirmación, que permitiría afirmar qué código exacto había en producción ese día.
2. (a) El vínculo confirmación–elemento de trabajo mediante AB#<id> en el mensaje de la confirmación. (b) La solicitud de incorporación de cambios, que registra revisores, comentarios y decisiones. (c) El entorno de Azure Pipelines, que guarda qué ejecución y qué artefacto se desplegaron en produccion y cuándo, con enlace de vuelta a las confirmaciones incluidas.
3. Una directiva de rama sobre main que exija a la vez elemento de trabajo vinculado, un mínimo de revisores y compilación con validación correcta; se implementa en 05-02, y el registro del despliegue por entorno, en 05-04. La clave es que la trazabilidad deja de depender de que alguien se acuerde: sin los tres requisitos, la fusión sencillamente no se permite.

Has visto que DevOps es antes que nada una forma de trabajar: los silos de Contoso —Diego entregando un ZIP, Marta desplegando los viernes por la noche y nadie sabiendo qué hay en producción— no se arreglan comprando una herramienta, sino cambiando responsabilidades, automatizando lo repetitivo y acortando los bucles de realimentación. Y has aprendido a medir esa mejora honestamente con las cuatro métricas DORA, leyendo juntas velocidad y estabilidad, y sin usarlas jamás para evaluar personas.

Sobre esa base has conocido Azure DevOps Services y sus cinco servicios —Boards, Repos, Pipelines, Test Plans y Artifacts—, has creado la organización contoso-airlines y el proyecto contoso-reservas con proceso Agile, y has entrado a fondo en Azure Boards: la jerarquía épica → característica → historia de usuario → tarea con sus criterios de aceptación, los paneles con límites de trabajo en curso, los sprints y, sobre todo, el vínculo AB#1842 entre confirmación y elemento de trabajo que convierte la trazabilidad en algo automático. Has separado niveles de acceso (lo que se factura) de permisos (lo que es gratis), sabiendo que Partes interesadas cubre a quien solo consulta y aprueba, y que los grupos deben venir de Microsoft Entra ID. Y has montado el puente que sostendrá todo el módulo: las conexiones de servicio sc-contoso-dev y sc-contoso-pro, con federación de identidad de carga de trabajo en lugar de secretos que caducan, y con el ámbito y el rol mínimos —la misma disciplina del módulo 4 aplicada a la entrega—.

El flujo está dibujado, pero todavía no existe. Y su primer eslabón es el más básico y el que hoy falta por completo en Contoso: un lugar único y fiable donde viva el código, con historia, con revisión y con reglas que no dependan de la buena voluntad. En la próxima lección, Azure Repos, crearás el repositorio contoso-reservas, migrarás el repositorio local de Diego conservando su historial, elegirás la estrategia de ramificación del equipo y —lo más importante— pondrás directivas sobre la rama main para que ningún cambio llegue a producción sin revisión, sin elemento de trabajo vinculado y sin haber compilado correctamente. Ahí es donde el ZIP por correo desaparece para siempre.