El otro día escribí un post sobre cómo Trabajar con URLs de varios entornos en Microsoft Azure, con el fin de poder pasar entre entornos y que las referencias internas siempre apuntaran al sitio adecuado. En dicho post se resolvía parte del cometido, ya que con la configuración mencionada somos capaces de identificar cuándo estamos ejecutando la aplicación en local y cuándo en Azure… ¿Pero en qué slot? ¿En staging o en producción?

A día de hoy no es posible a través de código identificar cuál de los slots estamos utilizando de una manera sencilla (podemos hacer uso de la Api de Service Management y haciendo una consulta de los servicios que tenemos alojados, recuperar el servicio en cuestión y determinar si el Deployment ID que buscamos está en un slot o en otro, pero es posible que sea una tarea demasiado tediosa para nuestro propósito). Sin embargo, podemos complementar el post anterior con una simple tarea: modificar el archivo ServiceConfiguration.cscfg desde el portal para actualizar la variable que almacena la URL del entorno al que vamos a mover (swap) el despliegue.

Actualizar el archivo ServiceConfiguration.cscfg ya desplegado

Siguiendo el ejemplo anterior:

Si nuestra propiedad WebAPIURL apunta a producción o staging, podemos modificar el valor para que apunte al entorno contrario.
Para modificar este valor, una vez que hayamos hecho la primera subida al entorno que teníamos configurado para el despliegue, debemos acceder al apartado CONFIGURE de nuestro Cloud Service, localizar la configuración del role que queremos modificar y actualizar su valor:

Guardamos los cambios a través del botón SAVE en el menú inferior y automáticamente todos nuestros roles actualizarán su configuración.

En este caso se ha tomado como ejemplo la URL de un servicio, pero puede usarse para cualquier otro parámetro que tengamos definido: cuentas de Storage, Service Bus, cache, base de datos, etcétera. Es importante tener en cuenta que, por unos instantes, este cambio de configuración supone que la aplicación tomará como recurso otro diferente y que este debe ser compatible con la lógica implementada , para evitar inconsistencias durante el proceso. Normalmente el paso natural es de staging a producción, ya que las peticiones reales se están llevando a cabo en este último.

En este caso, el problema es que no es posible saber el Deployment ID hasta que el paquete ha sido desplegado, ya que el mismo cambia con cada nuevo despliegue a la plataforma. Para solucionarlo, el valor que deberíamos añadir en el archivo de configuración para WebAPIURL debería ser http://{0}.cloudapp.net/api/movimientos/ y modificar el código mostrado en el post anterior por el siguiente:

            string url = RoleEnvironment.GetConfigurationSettingValue("WebApiURL");
            if (!RoleEnvironment.IsEmulated)
                url = string.Format(url, RoleEnvironment.DeploymentId);

De esta manera, si el valor almacenado en la configuración tiene el formato anterior, el espacio reconocido por string.Format será reemplazado por el Deployment Id, recuperado a través de RoleEnvironment.DeploymentId.

Descargando los cambios

Por otro lado, es posible obtener una copia de los nuevos valores modificados en ServiceConfiguration.cscfg, utilizando el botón DOWNLOAD del menú inferior, en la sección CONFIGURE:

O incluso realizar los cambios en el archivo que tenemos alojado en nuestra solución, dentro del control de código fuente, y subirlo a través del botón UPLOAD.

Espero que sea de utilidad.

¡Saludos!