2010-12-19 22 views
7

Tengo Visual Studio 2010 solución con Azure Service y una solución ASP.NET MVC 3 que sirve como Web Role para el servicio de Azure. No hay otras funciones asociadas al servicio aparte de eso.Cómo acelerar el despliegue de Azure desde Visual Studio 2010

Cada implementación en el entorno de almacenamiento en Azure (o producción, para el caso) tarda hasta 20 minutos en completarse, desde el momento en que hago clic en publicar en Visual Studio hasta que se inician todas las instancias (2).

Como se puede imaginar, esto lo convierte en un PITA para publicar a menudo, o para corregir algunos errores. ¿Hay alguna manera de acelerar el proceso? ¿Sería más rápido subir el paquete al almacenamiento de Blob y actualizar desde ahí? ¿Cómo voy a lograr eso?

Siento que los documentos en línea en Azure dejan mucho que desear. Particularmente cuando se trata de solucionar problemas por cierto.

Gracias.

Respuesta

7

Una idea para reducir la necesidad (y frecuencia) para volver a implementar es mover contenido estático en almacenamiento blob, externo al paquete. Por ejemplo, mueva su css y javascript para blob storage, junto con imágenes. Una vez hecho esto, solo tendrías que recompilar/redesplegar.Cambios en el código NETO Puede cargar CSS actualizado, en cualquier momento, para bloquear el almacenamiento. Si primero desea probar esto en etapas, siempre puede tener un nombre de contenedor de transición frente a producción para su contenido estático y almacenar ese nombre de contenedor en una configuración.

Esto no cambia el tiempo de despliegue cuando se hace necesidad de volver a implementar, pero al menos se puede reducir la frecuencia con que pasar por ese proceso ...

+0

Estoy empezando a gustarme su enfoque cada vez más. Sin embargo, una pregunta: ¿guarda usted todos sus archivos js, imágenes, etc. separados de de project (en VS, eso es) o simplemente los configura como no formando parte del paquete publicado? –

+0

He decidido seguir con esta respuesta, ya que parece ser la más práctica cuando finalmente acepto que un despliegue completo será un proceso lento sin importar nada. –

+0

http://blogs.msdn.com/b/jnak/archive/2010/10/29/rapid-developer-deploy-to-azure.aspx –

0

La carga en sí misma lleva un poco más de un minuto la mayor parte del tiempo. Es la puesta en marcha de las instancias lo que ocupa la mayor parte del tiempo.

Lo que puede hacer es implementar primero sus soluciones para la puesta en escena (tenga en cuenta que cuesta dinero, así que no lo deje demasiado tiempo). El intercambio de etapas a la producción solo toma un par de segundos. Por lo tanto, mientras su aplicación todavía esté ejecutándose, puede cargar la versión parcheada, dejar que los probadores la prueben en etapas y, cuando lo hagan, simplemente cambiarla a producción.

No he probado su posible enfoque alternativo cargando primero al almacenamiento de blob primero. Pero creo que eso es sobrecargado, ya que no acelera el inicio de las instancias.

+0

gracias, así es como lo hago actualmente, y el intercambio de hecho VIP funciona muy bien y es rápido y sin tiempo de inactividad. Pero poner en marcha el despliegue provisional es tan terriblemente lento que no puedo imaginar que no haya una mejor manera :) –

+1

Acabo de regresar de un curso de Microsoft de 2 días. El experto lo mencionó como demasiado malo también. Es probable que Microsoft invierta en el futuro para acelerar el proceso. Pero sepa que la nube funciona con hardware promedio para mantener las cosas baratas y redundantes. – XIII

1

Es una buena idea intentar subir su proyecto primero al almacenamiento de blob, pero desafortunadamente esto es lo que Visual Studio está haciendo por usted detrás de la escena de todos modos. Como se ha señalado en otro lugar, la mayor parte del tiempo en la implementación no es la carga en sí, sino la detención y el inicio de todos sus dominios de actualización.

Si solo está ejecutando este sitio en un entorno de desarrollo, entonces la única forma que conozco de acelerarlo es ejecutar solo una instancia. Si este es el ambiente en vivo, entonces ... lo siento, creo que no tienes suerte.

Para no tener que implementar en la nube para probar cambios menores, lo que he encontrado funciona bastante bien es diseñar el sitio para que funcione cuando se ejecuta en IIS local al igual que cualquier otro sitio de MVC.

La mayor barrera para este funcionamiento es la configuración que tiene en la configuración de la nube. La forma en que solucionamos esto es hacer una copia de todas las configuraciones en su configuración de nube y ponerlas en su web.config en la configuración de la aplicación. Luego, en lugar de utilizar RoleEnvironment.GetConfigurationSettingValue(), cree una clase contenedora a la que llame en su lugar. Esta clase contenedora marca RoleEnvironment.IsAvailable para ver si se está ejecutando en el tejido Azure, si es así, llama a la función de configuración habitual anterior, si no, llama al WebConfigurationManager.AppSettings[].

Hay algunas otras cosas que usted querrá hacer en torno a conseguir los eventos de cambio de ajuste de configuración que se espera se puede averiguar a partir del código a continuación:

public class SmartConfigurationManager 
{ 
    private static bool _addConfigChangeEvents; 
    private static string _configName; 

    private static Func<string, bool> _configSetter; 

    public static bool AddConfigChangeEvents 
    { 
     get { return _addConfigChangeEvents; } 
     set 
     { 
      _addConfigChangeEvents = value; 

      if (value) 
      { 
       RoleEnvironment.Changing += RoleEnvironmentChanging; 
      } 
      else 
      { 
       RoleEnvironment.Changing -= RoleEnvironmentChanging; 
      } 
     } 
    } 

    public static string Setting(string configName) 
    { 
     if (RoleEnvironment.IsAvailable) 
     { 
      return RoleEnvironment.GetConfigurationSettingValue(configName); 
     } 
     return WebConfigurationManager.AppSettings[configName]; 
    } 

    public static Action<string, Func<string, bool>> GetConfigurationSettingPublisher() 
    { 
     if (RoleEnvironment.IsAvailable) 
     { 
      return AzureSettingsGet; 
     } 
     return WebAppSettingsGet; 
    } 

    public static void WebAppSettingsGet(string configName, Func<string, bool> configSetter) 
    { 
     configSetter(WebConfigurationManager.AppSettings[configName]); 
    } 

    public static void AzureSettingsGet(string configName, Func<string, bool> configSetter) 
    { 
     // We have to store these to be used in the RoleEnvironment Changed handler 
     _configName = configName; 
     _configSetter = configSetter; 

     // Provide the configSetter with the initial value 
     configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)); 

     if (AddConfigChangeEvents) 
     { 
      RoleEnvironment.Changed += RoleEnvironmentChanged; 
     } 
    } 


    private static void RoleEnvironmentChanged(object anotherSender, RoleEnvironmentChangedEventArgs arg) 
    { 

     if ((arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>().Any(change => change.ConfigurationSettingName == _configName))) 
     { 
      if ((_configSetter(RoleEnvironment.GetConfigurationSettingValue(_configName)))) 
      { 
       RoleEnvironment.RequestRecycle(); 
      } 
     } 
    } 


    private static void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e) 
    { 
     // If a configuration setting is changing 
     if ((e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))) 
     { 
      // Set e.Cancel to true to restart this role instance 
      e.Cancel = true; 
     } 
    } 
} 
+0

Hola caballero, gracias por tu respuesta. Me puede estar perdiendo el sentido de su respuesta aquí, pero para comprobar si los pequeños cambios (css, javascript, buigfixes, ect) woirk puedo simplemente configurar el proyecto MVC como proyecto de inicio y ver si todo funciona. ¡Mi problema surge cuando me aseguro de que mis cambios funcionan y realmente quiero subirlos a la nube! :) –

+0

Sí, tienes razón. Pero a veces el sitio web se vincula con lo que está en la configuración de la nube, por lo que puede evitar que solo lo ejecute localmente. Mi respuesta aborda ese problema. Desde que dejé de usar el almacenamiento de desarrollo, estoy teniendo dificultades para resolver un problema que ocurrió en la nube, que no ocurrió localmente que no estuviera relacionado con la configuración. También he ampliado la introducción a mi pregunta para abordar su problema en particular. – knightpfhor

3

Mi solución a este problema es sólo para empujar un nuevo paquete cuando estoy cambiando el código en RoleEntryPoint o con la definición del servicio. En Azure 1.3, ahora puede utilizar la Conexión a Escritorio remoto. Usando RDC, compilaré mi código localmente y usaré copiar/pegar para ubicarlo en el servidor de Azure en el directorio apropiado. Una vez que el código de producción se está ejecutando correctamente, puedo empujar la versión completamente probada a la puesta en escena y luego hacer un intercambio VIP. Esto limita la cantidad de veces que tengo que implementar un paquete.

En realidad, tiene una ventana bastante larga en la que puede seguir modificando su código en Azure antes de tener que publicar un nuevo paquete. El nuevo paquete solo es realmente necesario para aquellos casos en que Azure tiene que cerrar/reiniciar su instancia de rol.

+0

Gracias a su respuesta me actualicé a Azure 1.3, que de alguna manera había manejado perderse Probaré RDP, gracias. :) –

+0

El uso de RDP y copiar/pegar los archivos .dll fue un gran ahorro de tiempo para mí al realizar ajustes de rendimiento, cargar y verificar el rendimiento. ENORME. GRACIAS. – pettys

+6

¿No se perderían sus cambios si reiniciara esa función de trabajador? También estoy bastante seguro de que no podrá escalar porque las nuevas funciones de trabajador no tendrán sus cambios –

4

Debe habilitar Web Deploy en su proyecto de Azure. Funciona de esta manera:

1/Cree una cuenta RDP (no olvide, debe cargar un certificado con su clave privada para que Azure pueda descifrar la contraseña). Está oculto en el cuadro de diálogo Implementar para su proyecto de implementación de Azure.

2/permitir el despliegue Web - mismo lugar

Una vez que ha publicado la aplicación de esa manera, haga clic en la aplicación web (no el proyecto de implementación azul) y seleccione Publicar. La ventana emergente tiene todo definido, excepto la contraseña, ingrese eso también y cargará sus cambios a Azure en cuestión de segundos.

CAVEAT: esto es para aplicaciones web de una sola instancia, definitivamente no es el camino a seguir para una estrategia de actualización de producción, y la respuesta de almacenamiento Blob ya mencionada es la mejor opción en ese caso.

Pierre