Momentan sind unsere Test- und Produktionsdatenbanken auf demselben Server, aber mit anderen Namen. Die Bereitstellung hat dazu geführt, Web.config zu bearbeiten, um alle Verbindungszeichenfolgen für die richtige Datenbank zu ändern. Ein Schritt, den ich allzu oft vergesse ...
Wir haben endlich einen neuen Datenbankserver zum Testen erstellt, und ich verschiebe die Datenbanken ... aber jetzt wird der Server anders sein und wir werden uns immer noch mit Verbindungsstringproblemen beschäftigen müssen.
Ich dachte daran, es über eine hosts-Datei zu verwalten, aber der Gedanke, das auf meinem Desktop-Rechner zu wechseln, wenn ich mit Produktionsdaten testen muss, erscheint bestenfalls umständlich.
Ich frage mich also, ob es einen besseren Weg gibt. Etwas, das mit einer "Produktions" -Webkonfiguration für die Bereitstellung erstellt würde, wäre ideal ...
Verwenden Sie ein Webbereitstellungsprojekt und aktualisieren Sie die wdproj-Datei (es ist nur eine MSBuild-Datei) mit einigen Post-Build-Aufgaben, um die richtige .config-Datei auszugeben. Ich behalte eine web.config und web.release.config dann verwenden Sie diese in der wdproj-Datei:
%Vor%Eine einfachere Lösung, die einige mögen, ist configSource-Eigenschaft von appSettings und connectionStrings und überschreibt diese Datei nie auf dem Produktionsserver.
Normalerweise habe ich drei verschiedene Webkonfigurationen: eine für meine Entwicklungsmaschine, eine für QA und eine für die Produktion. Die Entwicklung verbindet sich mit meiner lokalen SQL-Datenbank (die von außen Firewall ist) und es ist die Standard-web.config. Die anderen heißen web-prod.config und web-qa.config. Nach dem Veröffentlichen lösche ich die beiden, die ich nicht brauche, und benenne die richtige in web.config um. Wenn ich es vergesse, bricht die App beim ersten Mal, wenn sie versucht, auf die Datenbank zuzugreifen, weil die Standardkonfiguration auf eine verweist, zu der sie nicht gelangen kann.
Da IIS keine Datei mit dem Namen .config bereitstellt, vergewissere ich mich, dass alle Dateien in .config enden, anstatt web.config-prod oder web.config-qa zu sagen.
Hier ist eine andere Sache, die Sie versuchen können:
Erstellen Sie mit dem SQL Server-Konfigurations-Manager einen db Alias für Ihre Entwicklungsdatenbank, damit die Datei web.config sowohl in Ihrer Entwicklungsumgebung als auch auf dem Produktionsserver identisch sein kann.
Ich erstelle auf jedem Server einen Datenbankalias, der auf die Datenbank verweist. Ich verwende diesen Alias dann in meinen web.config-Dateien. Wenn ich ändern muss, auf welche Datenbank die Anwendung zeigt, dann ändere ich den Alias und nicht die web.config.
Wechseln Sie für SQL Server zum SQL Server-Konfigurationsmanager & gt; SQL Server Native Client-Konfiguration & gt; Aliase & gt; Erstelle neuen Alias.
Sie können dasselbe mit Oracle mit der Datei tnsnames machen.
haben Umgebungsordner mit separaten Konfigurationen für jede Umgebung
stelle das richtige für die Umgebung bereit
Ich war jetzt an einigen Stellen, wo sie in der Registrierung gespeichert sind.
Es gibt wahrscheinlich mehr ausgefeilte Wege, dies jetzt zu tun, aber eine Menge Code, an dem ich mit einem 1.0 / 1.1-Erbe gearbeitet habe, speichert die Strings in der Registry.
Die Registrierung hat einige Vorteile
Wir fahren unsere Bereitstellungen von unserem CI-Server. Wir haben normalerweise eine separate Datei für jeden Standort und lassen den CI-Server abhängig von den übergebenen Argumenten zur entsprechenden Konfiguration wechseln. Die gesamte Dateibearbeitung erfolgt in NAnt-Skripten, so dass Entwickler die auf ihrem Rechner erstellten Builds ausführen können, um ihre eigenen Einstellungen zu erhalten.
Ich werde meine Verbindungszeichenfolgen in die machine.config in unseren QA- und Production-Boxen setzen. Ich werde sie jedoch in der web.config auf meiner Dev-Box aufbewahren, um die Flexibilität zu erhöhen. Dann verwende ich ein Web-Implementierungsprojekt, um meine Dev-Verbindungszeichenfolgen mit nichts (keine Verbindungszeichenfolgen) zu überschreiben, wenn ich QA bereitstellen möchte. Daher stützt sich die QA-Site auf die Verbindungszeichenfolgen in machine.config. Ich stelle immer noch manuell auf Production um, um sicherzustellen, dass alles erfolgreich ist. Dazu kopiere ich alles manuell von QA (außer web.config) in die Produktion.
Diese Art von Aufgabe ist genau das, was Build-Ereignisse adressieren sollen. Denken Sie an Gebäude als Gebäude für ein bestimmtes Ziel, sollte dort eine zielspezifische Konfiguration vorgenommen werden. (mit der normalen Einschränkung, dass es immer einige Ausnahmen von der Regel gibt)
Ich habe mich in letzter Zeit auf die Konfig-Manipulation auf dem Continuous Integration Server konzentriert. Das liegt daran, dass wir Probleme mit mehreren web.config, web.qa.config, web.production.config hatten, wobei die 95% der Datei, die identisch sein sollte, synchron bleiben sollten.
Kurz gesagt: Es gibt nur die eine web.config in der Quellcodeverwaltung und es ist die Entwicklungskonfiguration (debug friendly, local db, etc.). Der Build-Server führt die Kompilierung durch, dann eine Bereitstellung an die Kanarienvogel-Site und dann das Paket für den Veröffentlichungskandidaten.
Wir verwenden nant, also ist es die .build-Datei, die xmlpoke gesetzt hat, um debug="false" zu setzen, Verbindungszeichenfolgen zu ändern und was auch immer in der kanarischen Kopie und der Verpackungskopie von web.config geändert werden muss.
Der Deploy der Erstellungsmaschine heißt "Kanarienvogel", weil er als erstes bei einem Problem stirbt.
Tags und Links asp.net deployment