El examen AZ-400 evalúa cómo diseñar la cadena completa de automatización desde el equipo del desarrollador hasta producción. Los temas centrales son las diferencias entre Azure Pipelines y GitHub Actions, la estructura YAML, el filtrado de disparadores, los mecanismos de reutilización y los criterios para elegir runners. Ambas plataformas pertenecen al ecosistema de Microsoft, pero tienen filosofías y fortalezas distintas, por eso el examen pregunta repetidamente cuál encaja mejor en cada situación. No hay una respuesta universal: la respuesta correcta está siempre dentro de las condiciones del escenario presentado.
CI y CD — Sensores en la línea de ensamblaje
Imagina una fábrica de automóviles donde las piezas avanzan sin control de calidad. Los defectos solo aparecen en la inspección final, cuando corregirlos es más costoso. Diez desarrolladores trabajan en paralelo y el lunes, al integrar los cambios, todo son conflictos. CI (Integración Continua) resuelve esto ejecutando automáticamente una compilación y pruebas cada vez que se fusiona código, detectando los problemas en el momento más temprano.
CD tiene dos formas. Continuous Delivery entrega automáticamente los artefactos validados hasta staging y mantiene una compuerta de aprobación manual antes de producción. Continuous Deployment elimina esa compuerta y despliega directamente a producción. La distinción del examen: si queda alguna aprobación manual antes de producción es Delivery; si nada se interpone entre el pipeline y producción es Deployment.
Azure Pipelines vs GitHub Actions — Cómo elegir
Imagina dos tiendas contiguas. Una es un gran almacén con sección especializada en DevOps (Azure Pipelines). La otra es una tienda de nicho con enorme variedad de componentes listos para usar (GitHub Actions). Cuál elegir depende casi por completo de lo que ya tienes.
Azure Pipelines forma parte de la plataforma Azure DevOps e integra estrechamente Azure Repos, Azure Boards y Azure Artifacts. Puede conectarse a Bitbucket, GitHub, GitHub Enterprise y Azure Repos como sistemas de origen, sin depender de un proveedor Git concreto. Grupos de despliegue, variable groups, service connections y pipelines de múltiples etapas son funciones integradas que facilitan la gestión empresarial.
GitHub Actions automatiza flujos de trabajo integrados directamente en los repositorios de GitHub. Los flujos se definen en archivos YAML en . Más de 15.000 Actions están disponibles en el Marketplace. Cualquier evento de GitHub (push, pull_request, schedule, workflow_dispatch) puede ser disparador, de modo que el código y el CI/CD conviven en la misma plataforma.
| Situación | Recomendación | |-----------|---------------| | Código en GitHub, entorno open-source | GitHub Actions | | Azure DevOps ya adoptado, independencia del proveedor Git | Azure Pipelines | | Fuente on-premises | Azure Pipelines | | Flujo de validación basado en PR | GitHub Actions |
!Azure Pipelines vs GitHub Actions
Estructura YAML y disparadores
Piensa en una cocina de restaurante. El pedido llega y trabaja la estación de entrantes, luego la de principales, luego la de postres. Dentro de cada estación los cocineros trabajan en paralelo. Los pipelines de CI/CD siguen el mismo modelo jerárquico.
El YAML de Azure Pipelines se estructura como . Un Stage es una fase lógica (Build, Test, Deploy). Un Job se ejecuta en un agente. Un Step es un Script o Task. GitHub Actions usa sin Stage; la dependencia entre Jobs se expresa con .
Disparadores: en Azure Pipelines, (push a rama), (Pull Request) y (cron) son claves separadas. En GitHub Actions los eventos se listan bajo . Los filtros de ruta () son clave en monorepos para que el pipeline solo se dispare cuando cambian archivos en un directorio concreto. En patrones glob, sí. coincide con , pero no. El examen vuelve repetidamente a esta diferencia.
Sin , los Jobs se ejecutan en paralelo por defecto. ejecuta aunque la etapa anterior falle; se salta solo en cancelación. Un paso que publica resultados de pruebas debe usar para que los resultados sean visibles aunque las pruebas fallen.
Reutilización — Plantillas, flujos reutilizables y environments
En lugar de escribir el membrete de la empresa en cada documento, se abre la plantilla compartida y se rellena solo el contenido único. La reutilización de pipelines funciona igual.
Las plantillas de Azure Pipelines son archivos YAML separados que definen Stages, Jobs, Steps o Variables, referenciados con . En un repositorio dedicado se referencia con y se fija la versión con o un SHA de commit. Apuntar a la rama principal deja que cambios no validados se propaguen a todos los pipelines de producción.
Los reusable workflows de GitHub Actions se invocan con , aceptando y , con hasta cuatro niveles de anidación. Una composite action empaqueta varios Steps en una única Action reutilizable.
Un environment representa un destino de despliegue. Un Job vinculado a un environment registra el historial y aplica compuertas: aprobaciones, verificación de plantilla requerida, permisos de pipeline y horario laboral, configurados de forma independiente por environment. Para restringir qué pipelines pueden desplegar a producción se usan los permisos de pipeline del environment, no la seguridad de la conexión de servicio. Un variable group vinculado a Azure Key Vault carga los secretos dinámicamente en tiempo de ejecución, sin texto plano en el YAML.
Selección de runner — Microsoft-hosted vs Self-hosted
Alquilar un coche (Microsoft-hosted runner) significa que la empresa de alquiler gestiona el mantenimiento. Pero si necesitas acceder a un aparcamiento privado que solo admite vehículos con tarjeta especial, necesitas tu propio coche (self-hosted runner). La elección depende de adónde necesitas ir.
Los runners de Microsoft aprovisionan una nueva VM para cada compilación y la eliminan al finalizar. Microsoft gestiona parches, actualizaciones y disponibilidad. Hay imágenes de Windows Server, Ubuntu y macOS disponibles con las herramientas de compilación más comunes preinstaladas. La limitación principal es que no pueden acceder a recursos de red interna que no estén expuestos a internet.
Los self-hosted runners se instalan en máquinas propias y acceden a recursos detrás de un firewall. El agente usa un modelo pull saliente por HTTPS 443 hacia Azure DevOps, sin necesidad de reglas de firewall de entrada, lo que simplifica la configuración de seguridad. Los agentes de scale set utilizan un VM Scale Set para ajustar automáticamente el número de agentes según la profundidad de la cola, conservando el acceso de red de los self-hosted. Los Container jobs ejecutan cada Job dentro de una imagen Docker especificada sobre un runner auto-alojado, aislando dependencias por servicio sin reemplazar la infraestructura subyacente.
Si las colas están saturadas y no se necesita acceso a recursos internos, adquirir parallel jobs adicionales tiene menor sobrecarga operativa que desplegar y mantener runners auto-alojados.
Resumen para el Examen
"Código en GitHub, entorno open-source" -- GitHub Actions "Azure DevOps ya adoptado, independencia del proveedor Git" -- Azure Pipelines vs -- solo en uno "Publicar resultados aunque las pruebas fallen" -- "Ejecutar sin depender de etapas anteriores" -- "Solo pipelines específicos pueden desplegar a producción" -- permisos de pipeline del environment (no la seguridad de la conexión de servicio) "No guardar secretos en el YAML" -- variable group vinculado a Azure Key Vault "Que los cambios en plantillas no lleguen a producción automáticamente" -- fijar con etiqueta o SHA de commit "Acceso a recursos de red interna" -- self-hosted runner "Mínima sobrecarga operativa con escalado automático" -- Microsoft-hosted runner o scale set agent "Disparador para invocar un flujo de trabajo reutilizable" -- evento CI = compilación y prueba automáticas en cada commit / CD Delivery = entrega automática a staging más aprobación manual / CD Deployment = automático hasta producción sin aprobación