Modelar un flujo de trabajo complejo con etapas paralelas y dependencias entre etapas.
→Utilice pipelines YAML multietapa. Use la palabra clave `dependsOn` para las dependencias de etapa y configure trabajos paralelos dentro de las etapas.
Por qué: YAML proporciona el enfoque más flexible y basado en código para la orquestación compleja, superior a los pipelines clásicos o la encadenación de pipelines separados.
Implementar un despliegue sin tiempo de inactividad, de bajo riesgo para una aplicación web con capacidad de reversión instantánea.
→Utilice slots de despliegue de Azure App Service. Despliegue en un slot de staging (verde), valide, luego realice un intercambio de slot con producción (azul).
Por qué: Un intercambio de slot es una operación atómica, casi instantánea que redirige el tráfico. La reversión es tan simple como volver a intercambiar.
Referencia↗
Minimizar la duplicación de pipelines para numerosos microservicios que comparten pasos comunes de construcción/despliegue pero requieren personalizaciones específicas.
→Cree plantillas YAML en un repositorio central. En cada pipeline específico del servicio, use la palabra clave `extends` y pase parámetros para la personalización.
Por qué: `extends` promueve los principios DRY y aplica estándares mientras permite flexibilidad a través de parámetros. Más potente que los grupos de tareas para estructuras completas de pipelines.
Restringir una etapa del pipeline (p. ej., despliegue de producción) para que se ejecute solo en fusiones a una rama específica (p. ej., main).
→Use una `condition` en la etapa o el trabajo. P. ej., `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.
Por qué: Las compilaciones de validación de PR utilizan una referencia de rama fuente diferente (p. ej., `refs/pull/...`), por lo que esta condición previene correctamente el despliegue durante el ciclo de vida de la PR.
Desplegar aplicaciones desde Azure DevOps a servidores locales detrás de un firewall corporativo.
→Instale agentes autohospedados en los servidores locales. Regístrelos en un grupo de agentes en Azure DevOps.
Por qué: Los agentes autohospedados inician comunicación saliente con Azure DevOps, por lo que no se necesitan reglas de firewall de entrada. Pueden acceder a recursos de red locales para el despliegue.
Requerir aprobación de varias personas para los despliegues de producción y restringirlos a ventanas de mantenimiento específicas.
→Defina un entorno de Azure DevOps para producción. Configure aprobaciones con los aprobadores requeridos. Agregue una verificación de "Horario Comercial" como una puerta para hacer cumplir la ventana de tiempo.
Por qué: Los entornos centralizan los controles de despliegue. Las aprobaciones y las puertas proporcionan una aplicación de políticas robusta y automatizada antes de que se ejecute una etapa.
Controlar la exposición de características a los usuarios sin volver a desplegar la aplicación, con actualizaciones casi en tiempo real.
→Utilice Azure App Configuration para la gestión de características. Instrumente la aplicación para leer flags y habilite sus capacidades de actualización dinámica.
Por qué: Desacopla los lanzamientos de características de los despliegues. App Configuration proporciona una interfaz de usuario centralizada y SDKs para actualizaciones dinámicas, evitando reinicios de aplicaciones.
Administrar el estado del clúster de Kubernetes de forma declarativa, donde Git es la única fuente de verdad y los cambios se aplican automáticamente.
→Despliegue un agente GitOps como Flux o ArgoCD en el clúster AKS. Configure el agente para monitorear un repositorio Git que contenga manifiestos de Kubernetes y sincronice automáticamente el estado del clúster.
Por qué: Este modelo basado en extracción permite la conciliación continua y la detección de desviaciones, que es fundamental para GitOps. Es más robusto que los pipelines `kubectl` basados en envío.
Administrar el estado de Terraform para la colaboración en equipo, garantizando la seguridad y previniendo modificaciones concurrentes.
→Configure el backend de Terraform para usar una cuenta de almacenamiento de Azure. Esto proporciona almacenamiento de estado remoto, con el bloqueo de estado gestionado a través de arrendamiento de Azure Blob.
Por qué: Evita la corrupción del archivo de estado por operaciones `apply` simultáneas y mantiene los datos de estado sensibles fuera del control de código fuente.
Referencia↗
En un monorepo, activar el pipeline CI de una aplicación solo cuando se modifican archivos en su directorio específico (o un directorio compartido).
→En el YAML del pipeline, use el filtro `trigger.paths.include` para especificar los directorios relevantes, p. ej., `include: ['/apps/frontend/**', '/apps/shared/**']`.
Por qué: Esto evita compilaciones innecesarias para cambios de código no relacionados, ahorrando tiempo de CI y recursos computacionales.
Optimizar una etapa de prueba con pruebas rápidas (unitarias) y lentas (de integración) para una retroalimentación más rápida.
→Ejecute pruebas unitarias y pruebas de integración en trabajos paralelos dentro de la misma etapa.
Por qué: La ejecución paralela proporciona resultados de pruebas unitarias mucho más rápido mientras las pruebas más lentas se ejecutan concurrentemente. La duración total de la etapa está determinada por el trabajo más largo, no por la suma.
Versionar automáticamente un paquete de biblioteca basado en el historial de commits para comunicar claramente el impacto de los cambios (rupturas, características, correcciones).
→Integre una herramienta como GitVersion en el pipeline CI. Analiza mensajes de commit, ramas y etiquetas para calcular automáticamente una versión SemVer (Mayor.Menor.Parche).
Por qué: SemVer proporciona un versionado significativo en el que los consumidores pueden confiar para la gestión de dependencias, a diferencia de los números de compilación o los hashes de commit.
Desplegar una aplicación en múltiples regiones geográficas una por una, con validación después de cada despliegue regional.
→Utilice un pipeline YAML multietapa con etapas secuenciales, una para cada región, usando `dependsOn` para forzar el orden. Use puertas de entorno entre etapas para la validación.
Por qué: Este modelo de despliegue basado en anillos contiene el radio de impacto de un despliegue defectuoso a una sola región, permitiendo la reversión antes de afectar a todos los usuarios.
Configurar un pipeline para soportar un modelo de desarrollo basado en tronco (trunk-based development), asegurando que la rama principal sea siempre desplegable.
→Configure un disparador CI en la rama `main`. Imponga PRs con una política de validación de compilación que ejecute pruebas rápidas y completas. Integre notificaciones rápidas (p. ej., a Teams/Slack) para fallos de compilación.
Por qué: La retroalimentación inmediata es crítica en el desarrollo basado en tronco. Esta combinación evita que se fusione código defectuoso y asegura una remediación rápida cuando ocurren problemas.
Pasar artefactos grandes (p. ej., modelos ML, >5GB) entre etapas del pipeline de manera eficiente.
→Suba el artefacto grande a Azure Blob Storage en la etapa productora. Pase el URI del blob a la etapa consumidora como una variable de salida.
Por qué: Azure Blob Storage es más rentable y de mayor rendimiento que los artefactos de pipeline incorporados para archivos de varios gigabytes.
Reducir los tiempos de compilación evitando la descarga repetida de dependencias (p. ej., NuGet, npm) en cada ejecución.
→Utilice la tarea `Cache@2`. Defina una clave basada en el archivo de bloqueo del paquete (p. ej., `packages.lock.json`). La tarea almacenará y restaurará la carpeta de dependencias.
Por qué: Puede ahorrar varios minutos por compilación restaurando desde una caché local rápida en lugar de obtener desde repositorios externos.
Compilar o desplegar el mismo código en paralelo contra múltiples destinos (p. ej., diferentes SO, regiones).
→Use una `strategy: matrix` en el trabajo del pipeline YAML. Defina variables para cada combinación, lo que generará un trabajo para cada entrada de la matriz.
Por qué: Una estrategia de matriz mantiene la definición del pipeline DRY, creando múltiples variaciones de trabajo a partir de una única definición y ejecutándolas en paralelo.
Implementar un despliegue canary en AKS que cambie automáticamente el tráfico y promocione o revierta basándose en métricas en tiempo real.
→Utilice un controlador de entrega progresiva como Flagger, integrado con una malla de servicios (p. ej., Istio) y un proveedor de métricas (p. ej., Prometheus).
Por qué: Flagger automatiza todo el proceso de análisis canary, proporcionando una entrega progresiva más segura y confiable que los scripts manuales.
Un pipeline de aplicación necesita activarse cuando el código cambia en su propio repositorio O en un repositorio de biblioteca compartida separado.
→En el YAML de la aplicación, defina la biblioteca compartida bajo `resources.repositories` y configure un bloque `trigger` en ese recurso.
Por qué: Crea una dependencia declarativa entre repositorios, asegurando que la aplicación siempre se reconstruya con los últimos componentes compartidos.
Un pipeline necesita crear infraestructura temporal para pruebas y asegurar que se destruya después, incluso si las pruebas fallan.
→Utilice un pipeline multietapa con etapas separadas de aplicación y destrucción para IaC (Terraform/Bicep). Configure la etapa de destrucción con `condition: always()` .
Por qué: La condición `always()` garantiza que la etapa de limpieza se ejecute independientemente del éxito o fracaso de las etapas anteriores, evitando recursos huérfanos.
Evitar que un despliegue de producción avance a menos que haya una solicitud de cambio aprobada en una herramienta ITSM como ServiceNow.
→Configure una puerta de Entorno que invoque la puerta "Query ServiceNow" para verificar el estado de la solicitud de cambio.
Por qué: Automatiza la integración con los procesos de gestión de cambios empresariales, asegurando el cumplimiento sin traspasos manuales.
Proporcionar un pool de agentes de compilación autohospedados que escala dinámicamente con la demanda para reducir los tiempos de cola y controlar los costos.
→Configure un pool de agentes de Azure DevOps utilizando un Conjunto de Escalado de Máquinas Virtuales de Azure (VMSS), configurado para escalar automáticamente según el número de trabajos pendientes.
Por qué: Los agentes VMSS combinan la personalización de los agentes autohospedados con la elasticidad de los agentes alojados en la nube, optimizando el rendimiento y el costo.
Desplegar cambios de esquema de base de datos de una manera que prevenga la pérdida de datos y soporte reversiones.
→Utilice una herramienta de migración (p. ej., Flyway, DbUp). Implemente el patrón expandir/contraer para cambios de esquema para mantener la compatibilidad hacia atrás.
Por qué: Las herramientas de migración proporcionan versionado y control. El patrón expandir/contraer desacopla las reversiones de la aplicación y la base de datos, permitiendo despliegues más seguros.
Los agentes autohospedados se están quedando sin espacio en disco debido a los artefactos de compilación acumulados.
→En el YAML del pipeline, a nivel de trabajo, configure `workspace: clean: all`.
Por qué: Esta configuración preventiva del pipeline resuelve la causa raíz sin requerir intervención manual o cambios continuos en la infraestructura.
Las pruebas de integración requieren una instancia de base de datos aislada para cada ejecución del pipeline.
→Defina un recurso de contenedor (p. ej., SQL Server, Postgres) como un servicio en el YAML del pipeline. El trabajo de prueba puede entonces conectarse a este servicio efímero.
Por qué: Proporciona dependencias rápidas, aisladas y limpiadas automáticamente para las pruebas, previniendo interferencias en las pruebas y simplificando la configuración.
Mejorar la confiabilidad y el rendimiento de la restauración de paquetes desde repositorios públicos (p. ej., npmjs, nuget.org).
→En Azure Artifacts, cree un feed y configure fuentes ascendentes apuntando a los repositorios públicos. Haga que los clientes consuman paquetes del feed de Azure Artifacts.
Por qué: El feed almacena en caché los paquetes de fuentes ascendentes, protegiendo contra interrupciones de repositorios públicos y acelerando las restauraciones de paquetes de uso frecuente.
Desplegar un chart de Helm en múltiples entornos (dev, prod) con diferentes valores de configuración.
→Utilice archivos `values-<env>.yaml` separados para cada entorno. En la tarea `HelmDeploy`, use la entrada `valueFile` para especificar el archivo apropiado y `overrideValues` para inyectar valores dinámicos como etiquetas de imagen.
Por qué: Este patrón separa la configuración estática del entorno de las variables dinámicas del pipeline, manteniendo los despliegues limpios y mantenibles.
