Implementación continua en Azure

La implementación continua (CD) publica automáticamente en producción cada cambio que supera las pruebas de CI, sin intervención manual. La entrega continua es una variante más flexible: automatiza la implementación hasta un entorno de staging y requiere la aprobación de una persona antes de pasar a producción. Ambas prácticas se basan en la misma infraestructura de canalización. En Azure Pipelines, la CD se implementa agregando fases de implementación después de la fase de CI, dirigidas a entornos de Azure con puertas de aprobación cuando sea necesario.

Una canalización de CI/CD completa tiene al menos tres fases: Build (compilar, probar y publicar el artefacto), Deploy to Staging (implementar el artefacto en un slot que no sea de producción) y Deploy to Production (intercambiar el slot o implementar después de la aprobación). Las fases transfieren el artefacto mediante el almacenamiento de artefactos de la canalización. La fase de staging ejecuta automáticamente pruebas de integración o de humo; la fase de producción espera la aprobación manual antes de continuar.

Utilice trabajos deployment (no job normales) para las fases de implementación. Los trabajos de implementación admiten estrategias de implementación (runOnce, rolling y canary), realizan un seguimiento del historial de implementaciones por entorno y deben hacer referencia a los Entornos de Azure DevOps. Un entorno registra qué ejecuciones de canalización se han implementado en él, qué versión está activa actualmente y proporciona puertas de aprobación, comprobaciones y el estado de salud de los recursos en un único panel.

La tarea AzureWebApp@1 implementa una aplicación web en Azure App Service. Admite la implementación en un slot específico (por ejemplo, staging), así como de paquetes ZIP, imágenes de Docker o archivos JAR/WAR. Después de implementar en un slot de staging, utilice la tarea AzureAppServiceManage@0 para intercambiar el slot de staging con el de producción; este es el patrón de implementación preferido sin tiempo de inactividad para App Service.

Después de implementar en staging, ejecute pruebas de humo: un conjunto mínimo de pruebas que verifica que la implementación se realizó correctamente y que la aplicación responde de forma adecuada. Normalmente, las pruebas de humo llaman a puntos de conexión de API clave y verifican los códigos de estado y el contenido de respuesta esperados. Si las pruebas de humo fallan, la canalización se detiene antes de intercambiar el slot con producción o solicitar aprobación, lo que evita que una versión defectuosa llegue a los usuarios.

Agregue puertas de aprobación a los entornos de Azure DevOps para exigir una aprobación manual antes de continuar con las implementaciones. Vaya a la configuración del entorno y agregue aprobaciones; especifique los usuarios o grupos que deben aprobar. Cuando la canalización llega a un trabajo de implementación dirigido a ese entorno, se pausa y envía una notificación por correo electrónico. Los aprobadores pueden consultar los detalles de la implementación y aprobarla o rechazarla en el portal de Azure DevOps o mediante el vínculo del correo de notificación.

Implemente aplicaciones contenedorizadas en AKS mediante la tarea KubernetesManifest@0. Esta tarea aplica manifiestos YAML de Kubernetes al clúster e incluye compatibilidad integrada con imagePullSecrets e implementaciones canary. Conéctese al clúster de AKS mediante una conexión de servicio de Kubernetes configurada en Azure DevOps. Internamente, la tarea utiliza kubectl apply y espera a que finalice el despliegue antes de marcar el paso como correcto.

Etiquete las imágenes de contenedor con el identificador de compilación ($(Build.BuildId)) o el SHA de la confirmación de Git ($(Build.SourceVersion)) para poder rastrear siempre un contenedor en ejecución hasta la revisión exacta del código con la que se compiló. Evite utilizar la etiqueta latest en producción: Kubernetes la almacena en caché y es posible que no descargue la nueva versión. Almacene la etiqueta específica de la imagen como variable de canalización e inyéctela en los manifiestos de Kubernetes durante la implementación mediante envsubst o sed.

Defina una estrategia de reversión para las implementaciones en producción, de modo que pueda recuperarse rápidamente de una versión defectuosa. En App Service, la reversión consiste en volver a intercambiar el slot de producción con la versión de staging anterior. En AKS, use kubectl rollout undo. Cree un pipeline de reversión dedicado o agregue un trabajo de reversión manual que pueda activarse desde el portal de Azure DevOps. Documente el procedimiento de reversión y practíquelo con regularidad: una reversión que no se ha probado no es una reversión.

Después de cada implementación en producción, ejecute automáticamente una comprobación de supervisión para confirmar que la nueva versión funciona correctamente. Use la comprobación de pipeline AzureMonitor@1 para consultar las métricas de Azure Monitor. Si las tasas de error aumentan después de la implementación, bloquee la progresión del pipeline y active una reversión. Envíe notificaciones de implementación a Microsoft Teams o Slack mediante tareas de webhook, para que el equipo sepa cuándo finaliza una implementación y qué versión está activa.

Siga estos procedimientos recomendados de implementación continua: implemente con frecuencia (los lotes pequeños reducen el riesgo), use indicadores de características para desacoplar la implementación de la publicación, automatice todas las puertas de calidad antes de producción, practique con un entorno de staging similar a producción para que las diferencias no oculten errores, supervise las ventanas de implementación mediante comprobaciones de estado automatizadas y tenga siempre un plan de reversión probado. Un pipeline de CD maduro convierte la implementación en un evento rutinario, en lugar de una operación de alta tensión.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que los pipelines YAML de varias etapas encadenan las etapas de compilación, staging y producción mediante el intercambio de artefactos; los trabajos de implementación con Environments permiten establecer puertas de aprobación y realizar un seguimiento de las implementaciones; y las pruebas de humo después de la implementación en staging evitan que versiones defectuosas lleguen a producción. A continuación, exploraremos GitHub Actions en Azure.