Conectar Azure DevOps con Azure Static Web Apps te permite publicar una aplicación React de forma automática cada vez que se genere un nuevo paquete. Ese flujo, conocido como continuous deployment, cierra el ciclo entre integración y publicación sin pasos manuales.

Antes de avanzar necesitas una cuenta y suscripción activa de Azure. El servicio Static Web Apps que vamos a usar es gratuito y la conexión con Azure DevOps tampoco genera costo. Si aún no tienes la cuenta, Azure regala 200 dólares iniciales para explorar la plataforma [3:20].

¿Cómo se crea un sitio en Azure Static Web Apps?

Desde el portal de Azure creas un nuevo recurso de Static Web App, le asignas un nombre, en este caso Reapp Platzi App, y lo agrupas en un resource group dedicado. Eliges el plan Free, suficiente para demos y proyectos personales [4:50].

Un detalle clave: el asistente ofrece configurar integración continua automática desde GitHub o Azure Repos, pero como vamos a manejar el despliegue desde Azure DevOps, seleccionas la opción Other. Así evitas que Azure genere su propio workflow y mantienes el control desde los releases que ya construiste.

¿Qué es Azure Static Web Apps? Es un servicio de Azure pensado para publicar aplicaciones SPA hechas en React, Angular, Vue o Blazor. Incluye hosting global, certificados SSL y un plan gratuito.

¿Para qué sirve el deploy token?

Una vez creado el sitio, Azure genera un deploy token, una credencial que identifica a qué recurso debe publicarse la aplicación. Lo copias desde el portal y lo llevas a Azure DevOps. Ese token es el puente de autenticación entre ambos servicios [6:30].

¿Cómo configurar la tarea de Static Web App en el release?

Dentro del release de Azure DevOps editas el job que extrae el archivo .zip y agregas una nueva tarea: Azure Static Web App (en preview, pero estable para uso real). Aquí defines tres parámetros importantes:

• Working directory: la carpeta donde se descomprimió el zip, en este caso Reapp App. Recuerda que dentro del zip viene una carpeta build que contiene el compilado real.
• App location: la raíz de esa carpeta, sin subdirectorio adicional, porque ahí está toda la aplicación lista.
• Skip app build, API build y static export: activas estas opciones porque la compilación ya se hizo en el pipeline anterior. No tiene sentido repetirla.

La idea es que esta tarea solo se encargue de tomar los archivos ya compilados y subirlos, no de volver a buildear.

¿Cómo guardar el deploy token de forma segura?

Podrías pegar el token directamente en la tarea, pero es mala práctica por seguridad y mantenibilidad. Las opciones recomendadas son:

1. Guardarlo en Azure Key Vault, el servicio de Azure dedicado a secretos.
2. Usar una extensión de Azure DevOps especializada en gestión de secretos.
3. Crear una variable personalizada en el pipeline, marcándola como secreta.

Para el demo creas una variable llamada SWA_TOKEN (de Static Web App Token) y le asignas el valor copiado desde Azure [9:40].

¿Cómo se referencia una variable en Azure DevOps? Con la sintaxis $(NOMBRE_VARIABLE) dentro del campo de la tarea. En la pestaña Variables solo escribes el nombre, sin símbolos.

¿Por qué fallaba el deployment token?

En la primera ejecución el pipeline marcó error con el mensaje deployment token no es válido. La causa: al definir la variable se incluyó el símbolo $ y los paréntesis dentro del nombre, cuando esa sintaxis solo se usa al invocar la variable, no al declararla [12:15].

La corrección es simple. En la sección Variables dejas únicamente el nombre SWA_TOKEN y el valor del token. En la tarea de Static Web App referencias $(SWA_TOKEN). Tras guardar y crear un nuevo release, la ejecución termina satisfactoria y el sitio queda publicado en la URL que Azure asignó al recurso.

¿Qué es continuous deployment y por qué importa?

Lo que acabas de configurar se llama continuous deployment: cada vez que el pipeline genera un paquete nuevo, ese artefacto se publica automáticamente en Azure sin intervención humana. Combinado con la integración continua previa, cierras un ciclo completo de DevOps.

¿Cuál es la diferencia entre integración continua y despliegue continuo? La integración continua compila y prueba el código en cada cambio. El despliegue continuo toma ese paquete validado y lo publica automáticamente en producción o staging.

Antes de herramientas como Azure DevOps, este proceso era lento, manual y propenso a errores. Hoy puedes automatizar el empaquetado, la verificación y la publicación de una aplicación React en minutos. Si llegaste hasta aquí siguiendo todos los pasos, felicítate: dominaste uno de los procesos más complejos del desarrollo de software moderno.

¿Qué aplicación vas a publicar primero con esta configuración? Cuéntame en los comentarios.