Releasing vor Azure:Azure Web Rollenkonfigurationseinstellungen für Umgebungen
Vor Azure verwenden, würden wir nur haben, schreibgeschützte Dateien config in den verschiedenen Umgebungen (Test, Staging und Produktion, etc.) sitzen. Während einer Veröffentlichung wurden alle Anwendungsdateien (keine Konfigurationsdateien) in der betreffenden Umgebung bereitgestellt. Die Anwendungsdateien würden dann die Konfigurationsdatei der Umgebung für Verbindungszeichenfolgen und andere umgebungsspezifische Details lesen. Ich nehme an, dass dies ein ziemlich Standard-Setup ist?
Loslassen nach Azure:
Nun bewegen wir unsere Web-Anwendungen zu Azure Web Rollen. Webrollen verwenden ServiceConfiguration.Cloud.cscfg und ServiceConfiguration.Local.cscfg Dateien.
Bei der Veröffentlichung in einem Cloud-Dienst müssen die Verbindungszeichenfolgen bekannt sein. Wenn wir in einem Test-Cloud-Service veröffentlichen möchten, muss ServiceConfiguration.Cloud.cscfg entsprechend bearbeitet werden. Wenn wir in einem Staging- oder Produktiv-Cloud-Dienst veröffentlichen möchten, muss ServiceConfiguration.Cloud.cscfg weiter geändert werden.
Ich würde viel lieber die Entwickler AWAY von Verbindungszeichenfolgen abstrahieren, wenn sie ihre Bereitstellungen machen. Dies verhindert den Fehler, auf falsche Umgebungen zu zeigen (was große Auswirkungen haben könnte). Wie kann das gemacht werden?
Ich verstehe, dass diese Konfigurationseinstellungen im Azure Management Portal geändert werden können. Um diesen Schritt in den Freigabevorgang aufzunehmen, müssten Entwickler jedoch Zugriff auf das Verwaltungsportal haben, was keine ideale Situation darstellt Es gibt immer noch einen Spielraum für Fehler (plus "offenen" Zugriff auf Management Portal).
Update:
Ich fand, dass Sie Ihre Service-Konfigurationsdateien von mehr hinzugefügt (und Umbenennung) verwalten können:
Und dann durch den richtigen Cloud-Service (schwarz) wählen und die richtige Service-Konfiguration (roter Pfeil) zusammen, müssen die Entwickler die Konfigurationsdetails nicht kennen:
Es ist nach wie vor das Problem eines Entwicklers in der falsche Service-Konfiguration wählen, wenn an einen Cloud-Service-Bereitstellung (aber vielleicht in ein Skript automatisiert werden könnte, dies zu verhindern?)
Mein Haupt IRK ist der Umwelt-Typ (blauer Pfeil). Das nützt mir jetzt nichts.
müsste ich überprüfen aber ich denke, das ist nur erlaubt Ihnen, die Konfiguration und nicht die Service-Definition zu wählen. Es kann also zu Problemen kommen, wenn Sie unterschiedliche Endpunkte (http vs. https), unterschiedliche Vm-Größen oder andere Umgebungen wünschen. Die Lösung auf meiner Antwortseite führt dies aus. –
@Eoin: Oh ja, guter Punkt in Bezug auf die Service-Definition. Dies wäre ein Problem. Letzte Frage: Können Sie Ihren Code versionieren, ohne ein "Bereitstellungspaket" zu haben? Das Veröffentlichen direkt aus Visual Studio ist ein wenig beängstigend, da Sie nicht sicher wissen werden, ob sich der Code geändert hat oder nicht. – davenewza
Nun, in unserem Fall ist unser Quellcode auf GitHub gespeichert, das wir für die Quellcodeverwaltung verwenden, also haben wir unsere eigenen Prozesse, um einen Zweig zu machen, den Release-Inhalt zu sperren und dann mit der Entwicklung auf dem Master fortzufahren. Wenn es an der Zeit ist, eine Production-Version zu veröffentlichen, stellen wir sie einfach aus der Zweigstelle bereit, bei der wir uns angemeldet haben. –