El examen AZ-400 plantea una pregunta central en la sección de colaboración y comunicación: ¿qué herramienta conecta al equipo con el menor esfuerzo operativo posible? El código puede funcionar a la perfección, pero si no hay documentación, un nuevo integrante del equipo perderá días tratando de entender el entorno. Del mismo modo, un despliegue exitoso que nadie conoce retrasa la validación por parte de los interesados. El principio que guía todo este dominio es sencillo: utilizar primero las aplicaciones oficiales y escribir código personalizado solo cuando ninguna otra opción sea adecuada.
Elegir entre Project Wiki y Published Wiki
Imagina que entras a trabajar en una empresa donde no existe ningún documento de incorporación y cada pregunta sencilla requiere abrir un hilo en el chat del equipo. Azure DevOps Wiki existe precisamente para evitar esa situación, y el examen comprueba si sabes cuál de sus dos variantes elegir.
es el punto de partida más rápido porque Azure DevOps crea automáticamente un repositorio Git dedicado y puedes comenzar a editar de inmediato. , en cambio, requiere que primero confirmes archivos Markdown en un repositorio de Azure Repos ya existente antes de poder activarla. Ese paso previo es la trampa que aparece con más frecuencia en el examen.
| Atributo | Project Wiki | Published Wiki | |----------|-------------|----------------| | Repositorio | Repo Git dedicado creado automáticamente | Conectado a un repo de Repos existente | | Inicio | Inmediato | Los archivos Markdown deben confirmarse primero | | Modelo de contribución | Editor exclusivo de Wiki | Flujo de trabajo de PR estándar |
Cuando el escenario exige contribuciones basadas en PR y un historial completo de Git, elige Published Wiki y recuerda que confirmar los archivos Markdown es el primer paso obligatorio.
El orden de navegación en la barra lateral de la wiki se controla con archivos , uno por carpeta, que listan los nombres de las páginas en la secuencia deseada. Como este archivo vive en Git, un script de pipeline puede automatizarlo. El arrastre y colocación en la interfaz gráfica internamente reescribe ese mismo archivo.
Markdown y Mermaid — Control de versiones de documentos como texto
¿Qué ocurre cuando la documentación vive en archivos de Word? Git no puede generar un diff útil, y dos ediciones simultáneas producen un conflicto de fusión que nadie quiere resolver. Markdown soluciona esto porque es texto plano y el motor de diff y merge de Git puede rastrear cada cambio de línea. Tanto GitHub como Azure DevOps renderizan automáticamente los archivos como HTML con formato.
Los diagramas merecen el mismo tratamiento. Añadir un PNG o una exportación de Visio a un repositorio hace imposible ver qué cambió en la revisión de un pull request. Mermaid es una biblioteca de código abierto que expresa diagramas en sintaxis de texto y es renderizada de forma nativa tanto por GitHub como por Azure DevOps Wiki, sin necesidad de instalar ningún complemento. Un bloque de código delimitado dentro de un archivo es todo lo que se necesita.
Guía de selección de tipo de diagrama:
Flujo de proceso y ramas de decisión → Ordenación de mensajes entre sistemas → Transiciones de estado y estados compuestos → Estructura de clases y herencia →
Para publicar documentación Markdown como sitio web estático en GitHub Pages, Jekyll es la opción integrada. Viene incluido en GitHub Pages y solo necesita un archivo y archivos Markdown: un push activa la compilación y el despliegue automáticos. Hugo y Gatsby requieren un pipeline de GitHub Actions personalizado, por lo que cuando el escenario dice sin infraestructura adicional, son respuestas incorrectas.
Service Hooks y GitHub Webhooks — Enviar eventos a sistemas externos
Imagina que un despliegue falla a las dos de la madrugada y nadie se entera hasta la reunión de la mañana siguiente. Sin un mecanismo de entrega de eventos, eso es exactamente lo que sucede. Azure DevOps y GitHub ofrecen cada uno una forma de enviar eventos a sistemas externos en el momento en que ocurren.
es la función de entrega de eventos integrada en Azure DevOps, configurable íntegramente a través de la interfaz gráfica en Project Settings sin escribir ningún código. Admite más de treinta tipos de eventos y destinos, incluidos Jenkins, Slack, Teams y puntos de conexión HTTP genéricos.
| Escenario | Elección | |-----------|----------| | Azure Repos → activar compilación en Jenkins | Service Hook with Jenkins | | Azure DevOps → sistema interno personalizado | Service Hooks Web Hooks | | GitHub → servicio externo heredado, sin sondeo | GitHub Webhook |
entrega notificaciones por correo electrónico a personas. Los sistemas automatizados como Jenkins no pueden recibir solicitudes HTTP por correo, por lo que las suscripciones de correo electrónico nunca son la respuesta correcta para la integración con sistemas de compilación. Las preguntas del examen colocan frecuentemente Email Subscription junto a Service Hook como distractor.
Cuando una alerta de Azure Monitor debe llegar a un sistema externo de gestión de incidentes y la carga útil necesita transformación, el patrón sin código consiste en crear primero un Logic App y luego referenciar su punto de conexión desde un Action group. Logic App gestiona la transformación a través de su conector HTTP sin ningún código. Si el escenario implica lógica personalizada compleja, la respuesta es Function App.
Integración con Teams — Las aplicaciones oficiales primero
Supon que el equipo de ingeniería vive en Microsoft Teams pero debe abrir el portal de Azure DevOps cada vez que quiere comprobar el estado de un pipeline. Instalar la aplicación oficial correcta elimina esa fricción. Siempre que un escenario del examen combine con , una aplicación oficial es siempre la primera respuesta a considerar.
| Aplicación | Origen | Qué entrega | |------------|--------|-------------| | Azure DevOps for Teams | Eventos de Azure DevOps | Actualizaciones de PR y estado de elementos de trabajo por canal | | Azure Pipelines for Teams | Azure Pipelines | Suscripciones a éxitos y fallos de compilación y publicación | | Azure Boards app for Teams | Azure Boards | Notificaciones de cambio de estado de elementos de trabajo | | Microsoft Teams for GitHub | GitHub | PR, incidencias y resultados de ejecución de flujos en tiempo real |
Cuando todos los eventos de compilación inundan un solo canal y las alertas útiles se pierden entre el ruido, la acción correcta es añadir un filtro a la suscripción existente. La aplicación Azure Pipelines para Teams admite el comando para filtrar por Build status, Pipeline name o Branch name. El examen distingue entre — baja sobrecarga — y — alta sobrecarga y, por tanto, incorrecto.
Integración Boards–GitHub — El primer paso que todos olvidan
Imagina que un desarrollador fusiona un pull request en GitHub mientras el responsable de proyecto en Azure Boards no tiene idea de que el elemento de trabajo correspondiente está terminado. Alguien tiene que actualizar ambos sistemas manualmente. La integración Boards–GitHub elimina por completo ese trabajo de doble entrada.
La manera oficial de conectar un repositorio de GitHub con Azure Boards es , instalada desde GitHub Marketplace. Una vez conectada, escribir en un mensaje de confirmación o en la descripción de un pull request crea automáticamente un vínculo bidireccional. La autenticación es OAuth.
OAuth frente a métodos de autenticación alternativos:
OAuth → autorización delegada de aplicación web (Azure Boards ↔ GitHub) Clave SSH → acceso al repositorio remoto para git clone y push Identidad administrada → autenticación entre recursos de Azure, no puede vincularse directamente con GitHub
Las discusiones en pull requests y los flujos de revisión de código son en sí mismos herramientas de colaboración. En un modelo ChatOps, la plataforma de chat — Teams o Slack — se convierte en el plano de control donde los ingenieros escriben comandos para activar pipelines o comprobar el estado de los despliegues. Comandos como y representan el patrón ChatOps. El valor definitorio es que un operador completa una tarea operativa sin salir nunca de la ventana de chat.
Resumen para el Examen
Requisito previo de Published Wiki -- confirmar archivos Markdown en Azure Repos primero Automatización del orden de navegación de la Wiki -- editar el archivo PR de GitHub + documentación versionada con Git -- Markdown Diagramas basados en texto con renderizado nativo de GitHub -- Mermaid Visualización de estados compuestos -- Mermaid GitHub Pages + Markdown, sin infraestructura adicional -- Jekyll Azure Repos → activar compilación en Jenkins, sin código -- Service Hook with Jenkins Integración con sistema automatizado en lugar de correo electrónico -- Service Hooks (no Email Subscription) GitHub → notificaciones en Teams, sin código personalizado -- Microsoft Teams for GitHub app Fallos de Azure Pipelines → Teams -- Azure Pipelines for Teams Reducir el ruido de notificaciones en Teams -- añadir un Subscription filter Primer paso de PR de GitHub ↔ Azure Boards -- instalar Azure Boards app for GitHub (OAuth) Transformación de carga útil + webhook externo, sin código -- Logic App + Action group