Flujo de trabajo del desarrollador de principio a fin

Un flujo de trabajo moderno de desarrollo en Azure conecta el control de código fuente, CI/CD, la infraestructura de contenedores y la observabilidad en un ciclo interno fluido, desde la confirmación del código hasta una producción observable. Sus componentes principales son: GitHub (código fuente), GitHub Actions (canalización de compilación y implementación), Azure Container Registry (almacén de imágenes), Azure Container Apps (entorno de ejecución) y Application Insights (observabilidad). Cada cambio pasa automáticamente del portátil del desarrollador a producción en cuestión de minutos, con controles de calidad en cada paso.

Organice su código en un repositorio de GitHub utilizando una estrategia de desarrollo basado en tronco o de ramificación GitFlow. Para la mayoría de los microservicios, el desarrollo basado en tronco (ramas de funcionalidad de corta duración que se combinan diariamente con main) reduce los conflictos de integración y mantiene la canalización sencilla. Use reglas de protección de ramas en main para exigir revisiones de solicitudes de incorporación de cambios y comprobaciones de CI correctas antes de combinar los cambios. Un archivo CODEOWNERS garantiza que los cambios en servicios críticos requieran la aprobación de los ingenieros sénior del equipo correspondiente.

La canalización de CI se ejecuta en cada solicitud de incorporación de cambios. Un flujo de trabajo habitual es: extraer el código → restaurar las dependencias → ejecutar pruebas unitarias → ejecutar pruebas de integración → compilar la imagen de Docker → insertar la imagen en Azure Container Registry. La imagen se etiqueta con el SHA de la confirmación de git para facilitar la trazabilidad. Use autenticación basada en OIDC desde GitHub Actions a Azure (mediante identidad federada) para evitar almacenar secretos de entidades de servicio de Azure en GitHub; es el equivalente de una identidad administrada para las canalizaciones de CI.

Después de que la canalización de CI se complete correctamente al combinar cambios en main, la canalización de CD implementa automáticamente en el entorno de pruebas. La canalización actualiza la etiqueta de imagen de Container App con el SHA recién compilado, espera a que la nueva revisión esté en buen estado y ejecuta pruebas de humo en la URL del entorno de pruebas. Las pruebas de humo verifican que los puntos de conexión críticos de la API devuelvan las respuestas esperadas. Si las pruebas de humo fallan, la canalización revierte el cambio dirigiendo de nuevo el tráfico de entrada a la revisión anterior, sin intervención manual.

Después de validar el entorno de pruebas, la canalización de CD se detiene en una puerta de aprobación. Las protecciones de entorno de GitHub Actions permiten configurar revisores obligatorios para el entorno de production. La canalización envía una notificación de Slack al ingeniero de guardia, quien revisa los resultados de las pruebas del entorno de pruebas, las diferencias y cualquier incidente abierto antes de aprobar. Solo después de la aprobación, la canalización continúa para implementar en producción la misma imagen identificada por el SHA. Este paso con intervención humana es fundamental para servicios con mucho tráfico o regulados.

Una vez realizada la implementación en producción, Application Insights proporciona visibilidad en tiempo real. El SDK de App Insights (o la instrumentación automática para los entornos de ejecución compatibles) realiza un seguimiento de: tasas de solicitudes, tasas de errores y latencia (las tres señales doradas), llamadas a dependencias (a bases de datos, Service Bus y otras API) y excepciones con seguimientos de pila completos. El Mapa de aplicación visualiza cómo se llaman los servicios entre sí y resalta qué dependencias contribuyen más a los errores o a la latencia.

Use Application Insights Annotations para marcar los eventos de implementación en los gráficos de métricas. Cuando se crea una anotación de versión (mediante la acción azure/appinsights-annotation de GitHub Actions), aparece como una línea vertical en todos los gráficos de métricas de App Insights. Esto permite comprobar de inmediato si un aumento de la latencia o de la tasa de errores se correlaciona con una implementación reciente, lo que reduce considerablemente el tiempo medio de diagnóstico (MTTD) durante los incidentes.

Para las canalizaciones más resilientes, implemente una reversión automática. Después de la implementación en producción, la canalización espera 10 minutos y consulta Application Insights para obtener la tasa de errores. Si la tasa de errores supera un umbral configurable (por ejemplo, >5 %), la canalización revierte automáticamente el cambio actualizando el tráfico de entrada de Container App para dirigir el 100 % a la revisión anterior. Este patrón de entrega progresiva reduce el alcance de una implementación defectuosa y permite a los equipos implementar con confianza incluso cambios complejos o delicados.

Los desarrolladores deben poder ejecutar y probar localmente toda la pila sin conectarse a recursos de producción de Azure. Use Azure Storage Emulator (Azurite) para el almacenamiento local de blobs y colas, Cosmos DB Emulator para probar la base de datos local y Service Bus Emulator para la mensajería local. La variable de entorno AZURE_ENVIRONMENT=local puede cambiar DefaultAzureCredential para que use cadenas de conexión que apunten a los emuladores, mientras que el mismo código utiliza una identidad administrada en Azure. Docker Compose orquesta todas las dependencias locales mediante un único comando docker compose up.

Integre la seguridad en cada etapa del flujo de trabajo de desarrollo: Dependabot busca dependencias vulnerables en las solicitudes de incorporación de cambios; GitHub Advanced Security (análisis de código con CodeQL) detecta vulnerabilidades como la inyección de SQL y secretos codificados de forma fija; Microsoft Defender for DevOps se integra con GitHub para mostrar recomendaciones de seguridad de Azure junto a los cambios de código; y el análisis de vulnerabilidades de ACR Defender comprueba las imágenes de contenedor en busca de CVE del sistema operativo y de la capa de aplicación después de cada inserción. Los hallazgos de seguridad aparecen como comentarios en las solicitudes de incorporación de cambios, por lo que pueden abordarse antes de combinar los cambios.

El flujo de trabajo de desarrollo completo es un bucle de retroalimentación continua: un desarrollador confirma el código, CI compila y prueba la imagen del contenedor, la imagen se inserta en ACR con el SHA de la confirmación como etiqueta, CD implementa en el entorno de pruebas y ejecuta pruebas de humo, una persona aprueba la implementación en producción, la canalización implementa en producción y crea una anotación de versión, y Application Insights supervisa las tasas de errores con una reversión automática si se superan los umbrales. La infraestructura como código (Bicep o Terraform) en el mismo repositorio garantiza que la canalización, Container App y la configuración de supervisión estén controladas por versiones junto con el código de la aplicación.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que el flujo de trabajo de desarrollo de extremo a extremo conecta el control de código fuente de GitHub, CI/CD de GitHub Actions, Azure Container Registry, Container Apps y Application Insights; las anotaciones de versión correlacionan las implementaciones con los cambios en las métricas para diagnosticar más rápidamente los incidentes; y la reversión automática basada en consultas de la tasa de errores reduce el alcance de las implementaciones defectuosas. A continuación, pasaremos a la preparación del examen con un repaso completo de los conceptos de nube y la arquitectura de Azure.