web.config und app.config maschinenspezifische Einstellungen in git

Question

Wir haben mehrere Teams von Entwicklern in verschiedenen Büros, und sie benötigen unterschiedliche Werte für eine Reihe von Konfigurationseinstellungen in unseren Projekten web.config und app.config Dateien.

Wir behalten diese Konfigurationsdateien gerne mit einem vernünftigen Satz von Standardwerten, damit Sie beim Auschecken des Stamm-/Hauptzweiges etwas arbeiten können, ohne nach Konfigurationsdateien suchen zu müssen.

Historisch haben wir Subversion, und speziell TortoiseSVN, verwendet, und dies bot eine einfache Möglichkeit, lokale Änderungen zu verwalten: Wir fügten diese Dateien einfach zu TortoiseSVNs automatischer Änderungsliste ignore-on-commit hinzu. Dies verhindert ein versehentliches Einchecken dieser Dateien, da Sie sie dann speziell auswählen müssen, um sie beim Einchecken einzuschließen (und Sie können sicherstellen, dass Sie wichtige Änderungen einchecken, nicht das lokale Konfigurationsrauschen). Der Hauptnachteil dieses Ansatzes besteht darin, dass die Konfigurationsdateien immer "geändert" aussehen. Daher ist es nicht möglich, auf einen Blick zu erkennen, ob Sie lokale Änderungen vorgenommen haben.

Wir suchen nach Git, und ich versuche, den besten Ansatz herauszufinden.

Zunächst einmal, was in anderen Antworten bereits Stackoverflow gibt es:

Option 1: Überprüfen Sie in xxx.sample Dateien und .gitignore die aktuellen Konfigurationsdateien: Dies wird empfohlen, zum Beispiel in this answer. Das Hauptproblem, das ich dabei sehe, ist, dass Änderungen an der Konfigurationsdatei leicht vergessen werden, an zwei verschiedenen Punkten: Der Committer kann leicht Änderungen verpassen, die sie der .sample Datei hinzufügen müssen, und Verbraucher (besonders Continuous Integration Server) können leicht Fehlende Änderungen, die sie aus der Datei .sample in ihre lokale Konfigurationsdatei einbinden müssen. Im Grunde scheint das keine gute Lösung zu sein.

Option 2: Haben Sie ein checkte in xxx.defaults-Datei und eine .gitignored xxx.local Konfigurationsdatei, die alle Einstellungen außer Kraft gesetzt definiert: Dies wird dargebracht, fr Beispiel here. Das Problem ist, dass wir mit Standardkonfigurationsanbietern von .Net arbeiten - ich möchte wirklich nicht, dass wir ein komplett neues Settings-Loading-Framework implementieren, wenn Mirosoft bereits die ganze Arbeit erledigt hat. Kennt jemand eine Möglichkeit, die Dateien app.config und web.config auf optionale lokale Überschreibungsdateien zu verweisen?

Option 3: Lassen Sie Entwickler lokale Niederlassungen halten, und dann haben sie immer Kirsch-Picks oder rebased Zweige in Master überprüfen, um die unerwünschten Commits in ihrer lokalen Niederlassung immer zu umgehen/vermeiden: Dies wird als möglich angeboten Workflow here, und während ich die Sauberkeit in Bezug auf Change-Tracking zu schätzen (alles eingecheckt), führt es eine erhebliche Menge von erforderlich Aufwand bei jedem einzelnen Check-in; Es ist ein großer Schmerz!

Option 4: Haben Konfigurationsdateien eingecheckt, aber haben sie mit --assume-unchanged markiert: Dies als möglicher Option angeboten wird here; soweit ich das beurteilen kann, ist es sehr ähnlich der ignore-on-commit Änderungsliste in TortoiseSVN, außer dass Sie keine Sichtbarkeit für diese "versteckten" geänderten Dateien in einem Commit-Prozess haben; TortoiseGit zum Beispiel zeigt die Datei mit einem "geänderten" Icon-Overlay, aber im Commit-Dialog wird die Datei überhaupt nicht angezeigt. Dies scheint ein wenig beängstigend, wieder sehr leicht zu vergessen, Änderungen zu überprüfen.

Angesichts dieser Optionen, die alle diejenigen sind, die ich gefunden habe, hoffe ich auf eine Möglichkeit, eine lokale Konfigurationsdatei in/über eine eingecheckte Datei app.config/web.config optional "einzuschließen" und gehen Sie mit Option 2; Weiß jemand einen Weg, dies zu tun, oder andere Optionen, die ich vermisse? (Ich bin leicht versucht, einen benutzerdefinierten Xml-Merging Pre-Build-Schritt in Betracht zu ziehen ...)

Ich hätte früher erwähnt werden müssen, wir sind immer noch auf VS2008, daher sind keine Konfigurationstransformationen verfügbar.

---

UPDATE: (gelöscht, war schlicht falsch)

UPDATE 2: ich meine letzte Aktualisierung und Antwort gelöscht habe, es war dumm/funktionierte nicht. Mir ist nicht aufgefallen, dass nach einem "Our" Merge der nächste Merge in die andere Richtung die "Original" Versionen dieser Dateien zurückbringt (überschreibt die lokalen Branch Changes); Wenn Sie interessiert sind, sehen Sie sich den Verlauf an. Diese Frage ist so offen wie immer.

Answer 1

Ich würde this answer for Managing complex Web.Config files between deployment environments von Dan für eine mögliche Lösung betrachten. Ich benutze mercurial und benutze denselben Prozess, um eine generische web.config Datei einzutragen und benutze die Web Transformationen, um den Speicherort von configSource zu ändern, um auf meine deployment-spezifischen Sachen zu verweisen.

Der Vorteil dieser Route liegt darin, dass sie vollständig in das Framework integriert ist, keinen zusätzlichen Code erfordert und mit der Webbereitstellung funktioniert.

in web.config Suche:

<?xml version="1.0"?> 
<configuration> 
    <connectionStrings 
     configSource="config/dev.connectionStrings.config" 
     xdt:Transform="Replace(configSource)" /> 
</configuration> 

ich ein config/connectionStrings.config geprüft mit Ausfällen in habe, aber der Entwicklungsserver config/dev.connectionStrings.config wird nicht geprüft, in:

<?xml version="1.0"?> 
<configuration> 
    <!-- snip --> 
    <connectionStrings configSource="config/connectionStrings.config" /> 
</configuration> 

in web.debug.config Checked und es wird bei einer neuen Bereitstellung nicht ersetzt.

Answer 2

Ich würde vorschlagen, dass Sie sich ConfigGen ansehen. Wir verwenden es in all unseren Projekten und es wirkt Wunder für alle Entwickler und auch für alle unsere Umgebungen. Im Grunde wird eine Kalkulationstabelle ausgeführt, die den Computernamen und die Konfigurationsdatei für die Ausgabe angibt. Anschließend wird die Vorlage "App.Config" oder "Web.Config" in Token umgewandelt, wobei Werte aus der Kalkulationstabelle in sie eingefügt werden. Fügen Sie Ihren Projekten einen einfachen Pre-Build-Schritt hinzu, um configgen auszuführen, und bevor der Build beginnt, haben Sie eine angepasste Konfigurationsdatei für Ihren Computer. Es unterstützt auch Standardeinstellungen.

Werfen Sie einen Blick auf die Seite und machen Sie Ihre eigene Meinung, aber ich kann definitiv dafür bürgen.

BEARBEITEN: Es ist erwähnenswert, dass Sie dann alle Ihre Web.config und App.config-Dateien (in Bezug auf. Git) ignorieren können. Sie müssen jedoch Ihre Vorlagen und Tabellen zum Repo hinzufügen. Ich bin mir auch sicher, dass es ein Update auf dem Weg gibt, das einen XML-Ersatz für die Tabellenkalkulation enthalten könnte, der einen eigenen Editor hat, was ihn für DVCSs besser geeignet macht.

Edit2: Siehe auch Daniels Beitrag hier: https://stackoverflow.com/a/8082937/186184. Er gibt ein sehr anschauliches Beispiel für die Vorlage und das Arbeitsblatt und zeigt, wie es in Ihrer Lösung funktioniert.

Answer 3

Wir sind bei unserer Firma in ein ähnliches Dilemma geraten. Wir haben am Ende separate Konfigurationszweige erstellt, die den Hauptzweig ergänzen. Wie zum Beispiel - develop-config, master-config, etc. Wir haben dann ein kleines Skript, das diese Zweige mit dem richtigen Quellzweig basierend auf der Implementierungsumgebung rebasen wird. Also zum Beispiel auf der Entwicklungsmaschine würden wir die Entwicklung-Konfiguration mit entwickeln. Wenn Sie auf einem lokalen Computer arbeiten, erhalten Sie die Standardkonfiguration (die von allen Entwicklern akzeptiert wird), die in den Hauptzweig eingecheckt wird (wie der lokale DB-Name, das Passwort usw.). Der Nachteil ist natürlich, dass Sie diese * -config-Filialen immer auf dem neuesten Stand halten oder zum Zeitpunkt der Bereitstellung auf den neuesten Stand bringen müssen.

Seit ich diesen Workflow implementiert habe, bin ich auf einige Implementierungstools wie whiskey_disk gestoßen, die einen ähnlichen Ansatz verfolgen. In der Tat mag ich ihre Lösung viel mehr, da sie viel sicherer und flexibler ist. Obwohl wahrscheinlich nicht gut für euch, da es mehr auf einen LAMP/RoR-Entwicklungs-Stack ausgerichtet ist.

Abgesehen davon, gibt es auch einige kommerzielle Lösungen gibt, die Sie einen Blick nehmen möchten vielleicht an wie Beanstalk

Answer 4

fanden Sie eine content filter driver?

Das heißt, daß auf jeden git checkout bedeuten würde, würde das wisch Skript basierend auf die aktuelle Konfigurationsdatei erzeugen:

• eine Config-Vorlagendatei (mit Config-Wert Platzhalter wie @@A_PARAM_VALUE@@)
• einer der Config-Wert-Datei (jeder Entwickler kann seine eigenen Konfigurationsdatei Werte versioniert halten)

Das Vermeiden von Merge-Problem und Gitignore-Einstellungen: jede "Config-Wert-Dateien" sind unterschiedlich und bleiben getrennt.
Dies ist auch kompatibel mit anderen Config Generation Lösung wie ConfigGen erwähnt in answer.

Answer 5

Ein bisschen hat sich seit 2012 geändert, und jetzt würde ich vorschlagen, dass Ihr Build/Deploy-Tool (VS Team Services, TeamCity, Octopus Deploy) umgebungsspezifische Konfigurationen verwaltet.

Wenn Sie in azur arbeiten, können Sie App-Einstellungen und Verbindungszeichenfolgen als Teil Ihrer App-Definition definieren.