Ich möchte wissen, wie andere ihre web.config-Dateien für bereitgestellte Anwendungen verwalten. (Angenommen, es gibt keinen automatisierten Bereitstellungsmechanismus - das liegt außerhalb des Bereichs dieser Frage)
Einige Entwickler verwenden daher während der Entwicklung web.config-Transformationen, erstellen / veröffentlichen ihre Projekte (Debug / Release, Test / Live-Konfigurationen), stellen dann alle veröffentlichten Artefakte auf einem Webserver bereit und richten IIS ein. Einige Entwickler erstellen / veröffentlichen ihre Projekte, stellen veröffentlichte Artefakte auf einem Webserver bereit, richten IIS ein und aktualisieren dann manuell die web.configs für die spezifische Umgebung (test / live usw.), in der sie bereitgestellt werden.
Sobald die Erstbereitstellung abgeschlossen ist und die Anwendung produktiv ist (entweder in einer Live- oder einer Testumgebung), wie gehen Sie bei der Pflege von web.config-Dateien über die Zeit vor, wenn eine Datenbankverbindungszeichenfolge oder eine App-Einstellungsschlüssel geändert werden muss ?
Verwenden Sie web.config-Transformationen, machen Sie Ihre Änderungen an VS, veröffentlichen Sie die Anwendung neu und kopieren Sie dann die gesamte App oder vielleicht nur die neue web.config auf den Server?
Müssen Sie nur die Datei web.config auf dem Server manuell ändern?
Steuern Sie die Änderungen in der web.config-Datei in der Versionsverwaltung, wenn sich beispielsweise Verbindungszeichenfolgen, Anwendungsschlüssel usw. (nicht Struktur) ändern?
Ich bin interessiert zu wissen, wie andere sich diesem nähern.
Derzeit nehmen wir Änderungen an der web.config in der Produktion vor. Wenn wir neue Funktionen oder Fehlerkorrekturen implementieren, kontrollieren wir diese Änderungen und alle Änderungen an der web.config wie neue App-Schlüssel usw. Wenn wir eine neue Version der Anwendung bereitstellen müssen, sichern wir die aktuelle Version in der Produktion Server, löschen Sie alle Dateien Ausnahme Konfigurationsdateien, dann kopieren Sie die neue Version ohne die Konfigurationsdateien auf den Produktionsserver, die bestehende Konfiguration beibehalten. Vergleichen Sie dann die vorhandene Konfiguration mit der in der Quellcodeverwaltung, um Änderungen im Schema zu berücksichtigen.
Wir versuchen, dies zu überarbeiten, weil wir ein Verfahren wünschen, das reproduzierbar und nicht anfällig für menschliche Fehler ist. Ich bin nicht davon überzeugt, dass die Lösung 100% web.config transformiert. Selbst wenn Sie Transformationen verwenden, scheint es dennoch, dass bei der Bereitstellung ein menschlicher Eingriff erforderlich ist, da sich möglicherweise ein Wert in der Produktionskonfigurationsdatei geändert und nicht in der Quellcodeverwaltung aktualisiert wurde. Wie gehen andere damit um?
Wir verwenden web.config-Transformationen mit VS 2010.
Sie können eine primäre web.config-Datei angeben und Transformationen verwenden, um sie für verschiedene Umgebungen zu ändern (z. B. Ändern von Datenbankverbindungszeichenfolgen). Diese Transformationen werden automatisch beim Bereitstellen / Veröffentlichen von Projekten dargestellt.
Es hängt auch davon ab, welche Art von Änderung implementiert werden muss. Obwohl unsere Bereitstellungseinstellung normalerweise nur Dateien ersetzt, die aktualisiert wurden. Wenn wir also nur die Umwandlung von web.config.production geändert haben, ist das alles, was wir implementiert haben.
Und ja, wir behalten alle web.config-Dateien und ihre Transformationen unter der Quellcodeverwaltung, da sie Teil von Anwendungen sind, die sich auf sie verlassen.
Es gibt auch bestimmte Umgebungen, die wir anderen Teams / Entwicklern öffnen, ihnen aber nicht erlauben, die Einstellungen von web.config zu ändern, damit ihre Einstellungen für die Bereitstellung / Veröffentlichung die Datei web.config überspringt. Obwohl im Allgemeinen keine Dateien auf dem Server direkt berührt, . Wir aktualisieren Dateien immer lokal, sodass Änderungen über die Quellcodeverwaltung verfolgt und ordnungsgemäß bereitgestellt werden können.
Quellcodeverwaltung für uns ist der Hauptspeicher. Alles, was geändert werden muss HAS um darauf einzugehen. Entwickler, die versuchen, dies zu umgehen, indem sie Konfigurationseinstellungen auf PROD- oder STAGE-Sites ändern, werden gesperrt. Wenn etwas schief geht, sind sie für die Behebung von Problemen verantwortlich. Normalerweise machen sie es nach dem ersten Nachtessen nicht mehr. Die Versionskontrollkonfigurationsdateien werden dann in die Dateien web.config und settings.config mit xml / xslt
integriertIn meinem aktuellen Projekt verwende ich eine web.config, die in allen Umgebungen identisch ist, und verwende configSource, um serverspezifische Einstellungen zu übernehmen
%Vor%Jede Umgebung hat ihre eigene Einstellungsdatei
Das Paketfreigabeskript, das wir haben, nimmt die Einstellungsdatei, die es benötigt, und benennt es in appsettings.config um, dann wird das gesamte Release hochgeladen. Die Freigabe kann dann in der Quellcodeverwaltung markiert werden.