Azure Artifacts, Estrategia de Paquetes y Pruebas

Azure Artifacts, GitHub Packages, la pirámide de pruebas y Quality Gate para el examen AZ-400.

El examen AZ-400 hace dos preguntas sobre paquetes y pruebas: qué versión de un paquete puede usar quién y cuándo, y con qué profundidad se validó el código antes del despliegue. Aunque los dos temas parecen independientes, comparten un único objetivo dentro del pipeline: garantizar automáticamente que los artefactos de compilación son confiables. Azure Artifacts y GitHub Packages cubren el lado del suministro; la pirámide de pruebas y Quality Gate cubren el lado de la verificación de calidad.

 

Azure Artifacts — Feed, Vistas y Fuentes Upstream

Imagina una biblioteca municipal donde los libros están dispersos en docenas de estanterías sin catálogo. Encontrar algo lleva una eternidad y nunca sabes si un libro está disponible o prestado. Azure Artifacts es la biblioteca de paquetes de tu equipo: un único lugar para alojar NuGet, npm, Maven, Python y Universal Packages, organizado con tres conceptos clave que controlan el ciclo de vida de los paquetes.

Un es el contenedor de paquetes con alcance de organización o de proyecto. Separar paquetes públicos de paquetes exclusivamente internos requiere dos feeds distintos; no es posible definir permisos por paquete dentro de un único feed.

Las (vistas) rastrean la madurez de los paquetes: , y . CI publica en ; la validación de QA promueve a ; la aprobación final promueve a . El movimiento entre vistas se realiza mediante , no mediante re-publicación. Compartir solo la URL de con consumidores externos garantiza que vean únicamente versiones estables.

Las redirigen mediante proxy los paquetes de registros públicos (npmjs.com, NuGet.org, Maven Central) a través del feed interno. Cuando un desarrollador ejecuta , las solicitudes pasan primero por el feed interno, centralizando la revisión de seguridad y el anclaje de versiones. Guardar un paquete upstream en el feed requiere al menos el rol ; un solo puede descargar paquetes ya cacheados.

GitHub Packages es el registro nativo de GitHub, autenticado con o un PAT. Azure Artifacts se integra de forma natural con Azure Pipelines; GitHub Packages se integra de forma nativa con GitHub Actions.

 

SemVer — Lo que Comunica el Número de Versión

Piensa en una receta médica sin dosis: solo el nombre del medicamento. Un número de versión es un mensaje que comunica a los consumidores qué tipo de cambio ocurrió. SemVer estandariza ese mensaje con tres dígitos: MAYOR.MENOR.PARCHE.

: solo corrección de errores, sin cambio de API. El código del consumidor funciona sin modificaciones. (ej., 3.5.2 → 3.5.3) : nueva funcionalidad, API existente preservada. PARCHE se reinicia a 0. Marcar algo como deprecado también es MENOR. (ej., 2.5.3 → 2.6.0) : cambio que rompe la compatibilidad con versiones anteriores. MENOR y PARCHE se reinician a 0. (ej., 3.4.9 → 4.0.0)

El examen contrasta con frecuencia deprecar frente a eliminar. Marcar un endpoint como deprecado sin eliminarlo no afecta a los consumidores: eso es MENOR. Eliminarlo o cambiar la firma del parámetro se convierte en MAYOR. Azure Artifacts aplica inmutabilidad: una versión publicada no puede volver a publicarse; cada corrección de errores necesita un nuevo número de versión.

 

La Pirámide de Pruebas — La Prueba Correcta en el Momento Correcto

Imagina una línea de ensamblaje de automóviles. Detectar una pieza defectuosa al inicio del proceso tiene un costo de corrección mínimo. Descubrirla después de que el auto ya está pintado y empacado para envío significa desarmarlo completamente. La pirámide de pruebas aplica esa misma lógica a los pipelines: cuanto más avanza un defecto hacia la derecha, más caro resulta corregirlo.

Las son la base de la pirámide. Corren en milisegundos aislando una función de todas sus dependencias externas mediante mocks o stubs. En .NET, genera archivos ; la tarea requiere . En PowerShell, es el estándar de facto; es una herramienta de análisis estático, no un framework de pruebas.

Las validan interacciones reales con bases de datos, APIs externas y pasarelas de pago. Son 10–100 veces más lentas que las unitarias y pertenecen después de la etapa de compilación pero antes del despliegue.

Las ejercitan escenarios completos de usuario en un navegador real. controla Chromium, Firefox y WebKit mediante una única API con auto-wait integrado. ofrece el soporte más amplio para navegadores heredados. solo funciona en Chromium sin soporte para WebKit, por lo que queda eliminado ante cualquier requisito de pruebas en múltiples navegadores.

Las mediante Azure Load Testing (basado en JMeter) miden tiempo de respuesta, rendimiento y tasa de errores. Las pruebas de carga validan el comportamiento dentro del tráfico máximo esperado; las pruebas de estrés superan deliberadamente esa capacidad para observar la degradación del sistema.

En las , OWASP ZAP ofrece dos modos. El solo ejecuta Passive Scan y es seguro en producción. El añade Active Scan con payloads de ataque reales: solo para staging, nunca en producción.

!La pirámide de pruebas

Quality Gate — Automatizando la Decisión de Despliegue

Un almacén que depende de un inspector humano para cada envío saliente crea un cuello de botella a medida que el volumen crece. Una línea de inspección automatizada que solo deja pasar paquetes conformes es más confiable y escala sin límite. Quality Gate y Release Gate aplican ese mismo principio a los despliegues de software.

y analizan calidad de código, code smells, vulnerabilidades de seguridad (SAST) y cobertura según umbrales configurables de Quality Gate. Para proyectos Java con Maven se usa ; con Gradle, . Las herramientas de cobertura varían por lenguaje: Java usa , .NET/Cusa , JavaScript/Node.js usa .

Los ejecutan comprobaciones automatizadas antes y después de las etapas de despliegue en Azure Pipelines:

: ejecuta una consulta en Azure Boards y bloquea el despliegue mientras existan errores activos por encima de un umbral. : consulta métricas o logs de Azure Monitor con KQL y bloquea si la tasa de errores o el tiempo de respuesta no supera el valor base. : gate de propósito general para verificar cualquier sistema externo con lógica personalizada.

Los verifican condiciones antes de que comience una etapa. Los comprueban el estado después de que se completa. Gate (automático, basado en condiciones) frente a Manual approval (una persona debe aprobar) es una distinción que el examen prueba con frecuencia.

 

Selección de Runner — Self-Hosted vs Microsoft-Hosted

Piensa en el autobús de empresa frente a un taxi. El autobús sigue una ruta fija pero puede acceder al campus privado de la empresa. Un taxi puede ir a cualquier parte, pero no puede entrar en las instalaciones seguras. La elección del runner en las pruebas sigue el mismo compromiso.

Los runners de Microsoft-hosted proporcionan un entorno virtual limpio para cada job sin necesidad de mantenimiento. Sin embargo, no pueden acceder a recursos dentro de una red privada, como una base de datos interna o un servidor de API local. Cuando las pruebas de integración o de carga requieren sistemas internos, los runners de Microsoft-hosted por sí solos son insuficientes.

Los runners self-hosted corren en máquinas gestionadas por el equipo, con acceso total a la red privada. Para feeds NuGet de Azure Artifacts desde un agente self-hosted, instala en la máquina agente, que es la recomendación oficial de Microsoft para gestionar credenciales automáticamente.

 

Resumen para el Examen

'Gestionar madurez de paquetes sin re-publicar' -- Release views ( / / ) + promote 'Proxy de registros públicos externos a través del feed interno' -- upstream source 'Rol mínimo para guardar paquetes upstream' -- Collaborator 'Rol mínimo para publicar paquetes directamente' -- Contributor 'Marcar como deprecado, no eliminar' -- SemVer MINOR 'Eliminar endpoint o cambiar firma del parámetro' -- SemVer MAJOR 'Soporte WebKit + auto-wait' -- Playwright 'Sin soporte WebKit, eliminado en pruebas de múltiples navegadores' -- Cypress 'Solo Passive Scan, seguro en producción' -- OWASP ZAP Baseline Scan 'Active Scan incluido, solo para staging' -- OWASP ZAP Full Scan 'Verificación automática antes de iniciar la siguiente etapa' -- Pre-deployment gate 'Verificación automática tras completar el despliegue' -- Post-deployment gate

Azure Artifacts = cadena de suministro de paquetes con control de versiones, pirámide de pruebas = aseguramiento de calidad por capas, Quality Gate = decisión de despliegue automatizada.

Volver a la lista del blog