2010-12-19 7 views
7

Ich habe Visual Studio 2010 Lösung mit einer Azure Service und ASP.NET MVC 3 Lösung, die als Web Role für den Azure-Dienst dient. Keine anderen Rollen an den Dienst als diese.So beschleunigen Sie Azure-Bereitstellung von Visual Studio 2010

Jede Bereitstellung in der Azure-Stagingumgebung (oder in der Produktionsumgebung) dauert bis zu 20 Minuten, um den Moment zu erstellen, in dem ich in Visual Studio auf Veröffentlichen klicke, bis alle Instanzen (2) gestartet wurden.

Wie Sie sich vorstellen können, macht dies eine PITA oft zu veröffentlichen, oder einige Bugs schnell zu beheben. Gibt es eine Möglichkeit, den Prozess zu beschleunigen? Wäre es schneller, das Paket auf den Blob-Speicher hochzuladen und von dort zu aktualisieren? Wie würde ich das erreichen?

Ich fühle Online-Dokumente auf Azure lassen viel zu wünschen übrig. Vor allem, wenn es um die Fehlersuche geht.

Danke.

Antwort

7

Eine Idee zur Verringerung der Notwendigkeit (und Häufigkeit) für die erneute Bereitstellung ist die Verschiebung statischer Inhalte in Blob-Speicher außerhalb des Pakets. Zum Beispiel, bewegen Sie Ihre CSS und Javascript in Blob Speicher, zusammen mit Bildern. Sobald dies erledigt ist, müssen Sie nur neu kompilieren für.NET-Code ändert sich. Sie können aktualisiertes CSS jederzeit in den Blob-Speicher hochladen. Wenn Sie dies zuerst im Staging testen möchten, könnten Sie für den statischen Inhalt immer einen Namen für den Staging- und den Produktionscontainer angeben und diesen Containernamen in einer Konfigurationseinstellung speichern.

Dies ist nicht die Zeit, Bereitstellung ändern, wenn Sie Notwendigkeit, umschichten tun Sie können aber zumindest reduzieren, wie oft Sie diesen Prozess durchlaufen ...

+0

Ich fange an, Ihren Ansatz mehr und mehr zu mögen. Eine Frage jedoch: Behalten Sie dann alle Ihre js-Dateien, Bilder usw. getrennt von de Projekt (in VS, das ist) oder konfigurieren Sie sie einfach als nicht Teil des veröffentlichten Pakets? –

+0

Ich habe mich entschieden, mit dieser Antwort zu gehen, da es am praktischsten erscheint, wenn endlich akzeptiert wird, dass eine vollständige Bereitstellung ein langsamer Prozess sein wird, egal was passiert. –

+0

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

0

Das Hochladen selbst dauert meistens mehr als eine Minute. Das Starten der Instanzen nimmt die meiste Zeit in Anspruch.

Sie können Ihre Fixes zuerst auf die Bereitstellung bereitstellen (beachten Sie, dass es Geld kostet, also lassen Sie es nicht zu lange da sein). Der Wechsel vom Staging zur Produktion dauert nur ein paar Sekunden. Während also Ihre Anwendung noch läuft, können Sie die gepatchte Version hochladen, lassen Sie Ihre Tester dies beim Staging testen und wenn sie loslegen, dann tauschen Sie sie einfach gegen Produktion aus.

Ich habe Ihren möglichen alternativen Ansatz nicht getestet, indem ich zuerst den Blobspeicher hochgeladen habe. Aber ich denke, dass das Overhead ist, da es das Starten der Instanzen nicht beschleunigt.

+0

Dank, das ist, wie ich es zur Zeit, und in der Tat VIP-Swapping funktioniert super und es ist schnell und ohne Ausfallzeiten. Das Ausführen der Staging-Bereitstellung ist jedoch so unerträglich langsam, dass ich mir nicht vorstellen kann, dass es keinen besseren Weg gibt :) –

+1

Ich bin gerade von einem 2-tägigen Microsoft-Kurs zurück gekommen. Der Experte erwähnte es auch als zu schlecht. Wahrscheinlich wird Microsoft in die Zukunft investieren, um den Prozess zu beschleunigen. Aber wissen Sie, dass die Cloud auf durchschnittlicher Hardware läuft, um die Dinge billig und redundant zu halten. – XIII

1

Es ist eine gute Idee zu versuchen, dein Projekt zuerst auf den Blob-Speicher hochzuladen, aber das ist es, was Visual Studio sowieso hinter der Szene für dich tut. Wie bereits an anderer Stelle erwähnt, handelt es sich bei der Bereitstellung meist nicht um das Hochladen selbst, sondern um das Stoppen und Starten aller Aktualisierungsdomänen.

Wenn Sie diese Site nur in einer Entwicklungsumgebung ausführen, ist die einzige Möglichkeit, die Geschwindigkeit zu erhöhen, die Ausführung nur einer Instanz. Wenn das die Live-Umgebung ist, dann ... Entschuldigung, ich denke, du hast kein Glück.

Damit ich nicht in der Cloud bereitstellen muss, um geringfügige Änderungen zu testen, habe ich herausgefunden, dass die Website so entwickelt wird, dass sie wie jede andere MVC-Site im lokalen IIS ausgeführt wird.

Das größte Hindernis für diese Arbeit sind Einstellungen, die Sie in der Cloud-Konfiguration haben. Um dies zu umgehen, kopieren Sie alle Einstellungen in Ihrer Cloud-Konfiguration und legen sie in Ihrer web.config in den appSettings ab. Erstellen Sie dann statt RoleEnvironment.GetConfigurationSettingValue() eine Wrapper-Klasse, die Sie stattdessen aufrufen. Diese Wrapperklasse überprüft RoleEnvironment.IsAvailable, um festzustellen, ob sie in der Azure-Fabric ausgeführt wird. Wenn dies der Fall ist, ruft sie die oben übliche Konfigurationsfunktion auf, andernfalls ruft sie auf.

Es gibt ein paar andere Dinge, die Sie rund um tun wollen werden die Konfigurationseinstellung ändern, Ereignisse, die hoffentlich Sie aus dem folgenden Code herausfinden können:

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

Hey Ritterpfhor, danke für deine Antwort. Ich könnte den Punkt Ihrer Antwort hier vermissen, aber um zu überprüfen, ob kleine Änderungen (CSS, Javascript, Bugfixes, ect) funktioniert, kann ich einfach das MVC-Projekt als Startup-Projekt festlegen und sehen, ob alles funktioniert. Mein Problem kommt, wenn ich festgestellt habe, dass meine Änderungen funktionieren und sie wirklich in die Cloud bringen wollen! :) –

+0

Ja, du hast Recht. Aber manchmal wird die Website mit dem verbunden, was sich in der Cloud-Konfiguration befindet. Das kann Sie daran hindern, es nur lokal auszuführen. Meine Antwort adressiert dieses Problem. Da ich den Entwicklungsspeicher nicht mehr verwende, habe ich Schwierigkeiten, ein Problem zu lösen, das in der Cloud passiert ist, das nicht lokal passiert ist und nicht mit der Konfiguration in Verbindung stand. Ich habe auch die Einführung zu meiner Frage erweitert, um hoffentlich auf Ihr spezielles Problem einzugehen. – knightpfhor

3

für dieses Problem Meine Lösung ist nur Push ein neues Paket, wenn ich Code im RoleEntryPoint oder mit der Service Definition ändere. In Azure 1.3 haben Sie jetzt die Möglichkeit, die Remotedesktopverbindung zu verwenden. Unter Verwendung von RDC kompiliere ich meinen Code lokal und verwende copy/paste, um ihn auf dem Azure-Server im entsprechenden Verzeichnis zu platzieren. Sobald der Produktionscode korrekt ausgeführt wird, kann ich die vollständig getestete Version auf die Staging-Version übertragen und anschließend einen VIP-Austausch durchführen. Dies begrenzt die Anzahl der Male, die ich tatsächlich ein Paket bereitstellen muss.

Sie haben tatsächlich ein recht langes Fenster, in dem Sie Ihren Code in Azure ändern können, bevor Sie ein neues Paket veröffentlichen müssen. Das neue Paket wird nur für Fälle benötigt, in denen Azure die Rolleninstanz herunterfahren/neu starten muss.

+0

Dank Ihrer Antwort habe ich auf Azure 1.3 aktualisiert, was ich irgendwie geschafft hatte vermissen. Ich werde RDP versuchen, danke. :) –

+0

Die Verwendung von RDP und das Kopieren/Einfügen der .dll-Dateien war für mich ein RIESIGER Zeitsaver, wenn es darum ging, die Leistung zu optimieren, hochzuladen und die Leistung zu überprüfen. ENORM. DANKE. – pettys

+6

Würden Ihre Änderungen nicht verloren gehen, wenn Sie diese Arbeitsrolle neu starten? Ich bin auch ziemlich sicher, dass Sie nicht in der Lage sein würden, zu vergrößern, weil die neuen Arbeiterrollen Ihre Änderungen nicht haben würden. –

4

Sie sollten Web Deploy in Ihrem Azure-Projekt aktivieren. Es funktioniert folgendermaßen:

1/Erstellen Sie ein RDP-Konto (vergessen Sie nicht, Sie müssen ein Zertifikat mit seinem privaten Schlüssel hochladen, damit Azure das Kennwort entschlüsseln kann). Dies ist im Dialogfeld "Bereitstellen" für Ihr Azure-Bereitstellungsprojekt verborgen.

2/Aktivieren Web Deployment - selben Ort

Sobald Sie die App veröffentlicht haben, die Art und Weise, mit der rechten Maustaste in der Webapplikation (nicht das azur Bereitstellung-Projekt) und wählen Sie Veröffentlichen. Im Popup-Fenster ist alles außer dem Passwort definiert. Geben Sie auch das Passwort ein und Sie werden Ihre Änderungen innerhalb weniger Sekunden in Azure hochladen.

CAVEAT: Dies ist für Single-Instance-Web-Anwendungen gedacht, definitiv nicht der Weg für eine Produktions-Upgrade-Strategie, und die Blob-Speicher-Antwort ist die beste Option in diesem Fall.

Pierre