Wie gehen Sie mit Konfigurationsdateien in der Quellcodeverwaltung um?

StackOverflow https://stackoverflow.com/questions/6009

  •  08-06-2019
  •  | 
  •  

Frage

Nehmen wir an, Sie haben eine typische Web-App und eine Dateikonfiguration.was auch immer.Jeder Entwickler, der an dem Projekt arbeitet, wird eine Version für seine Entwicklungsboxen haben, es wird eine Entwicklungs-, Produkt- und Bühnenversion geben.Wie gehen Sie damit in der Quellcodeverwaltung um?Diese Datei überhaupt nicht einchecken, mit anderen Namen prüfen oder etwas ganz Besonderes tun?

War es hilfreich?

Lösung

Was ich in der Vergangenheit getan habe, ist, eine Standardkonfigurationsdatei zu haben, die in die Quellcodeverwaltung eingecheckt wird.Dann hat jeder Entwickler seine eigene Override-Konfigurationsdatei, die von der Quellcodeverwaltung ausgeschlossen ist.Die App lädt zuerst die Standarddatei. Wenn dann die Überschreibungsdatei vorhanden ist, lädt sie diese und verwendet alle Einstellungen aus der Überschreibung anstelle der Standarddatei.

Im Allgemeinen gilt: Je kleiner die Überschreibungsdatei, desto besser, sie kann jedoch immer mehr Einstellungen für einen Entwickler mit einer sehr vom Standard abweichenden Umgebung enthalten.

Andere Tipps

Versionieren Sie diese Datei nicht.Versionieren Sie eine Vorlage oder so.

Aufbau Ist Code, und Sie sollten ihn versionieren.Wir basieren unsere Konfigurationsdateien auf Benutzernamen;Sowohl unter UNIX/Mac als auch unter Windows können Sie auf den Anmeldenamen des Benutzers zugreifen, und solange dieser für das Projekt eindeutig ist, ist alles in Ordnung.Sie können dies sogar in der Umgebung überschreiben, aber Sie sollen Versionskontrolle für alles.

Dadurch können Sie auch die Konfigurationen anderer untersuchen, was bei der Diagnose von Build- und Plattformproblemen hilfreich sein kann.

Mein Team verwaltet separate Versionen der Konfigurationsdateien für jede Umgebung (web.config.dev, web.config.test, web.config.prod).Unsere Bereitstellungsskripte kopieren die richtige Version und benennen sie in web.config um.Auf diese Weise haben wir die vollständige Versionskontrolle der Konfigurationsdateien für jede Umgebung, können problemlos einen Vergleich durchführen usw.

Derzeit habe ich die Konfigurationsdatei „template“ mit einer hinzugefügten Erweiterung, zum Beispiel:

web.config.rename

Allerdings sehe ich bei dieser Methode ein Problem, wenn sich kritische Änderungen geändert haben.

Die von uns verwendete Lösung besteht darin, nur die einzige Konfigurationsdatei (web.config/app.config) zu haben, aber wir fügen der Datei einen speziellen Abschnitt hinzu, der Einstellungen für alle Umgebungen enthält.

Da ist ein LOKAL, ENTWICKLUNG, QS, PRODUKTION Abschnitte, die jeweils die für diese Umgebung relevanten Konfigurationsschlüssel in unseren Konfigurationsdateien enthalten.

Was dafür sorgt, dass das alles funktioniert, ist eine Assembly mit dem Namen xxx.Umgebung auf den in allen unseren Anwendungen (Winforms und Webforms) verwiesen wird und der Anwendung mitteilt, in welcher Umgebung sie ausgeführt wird.

Die xxx.Environment-Assembly liest eine einzelne Informationszeile aus dem machine.config der jeweiligen Maschine, die ihr mitteilt, dass sie sich auf DEV, QA usw. befindet.Dieser Eintrag ist auf allen unseren Workstations und Servern vorhanden.

Hoffe das hilft.

+1 für den Vorlagenansatz.

Da diese Frage jedoch Tag Git hat, findet der verteilte Alternative an, in dem Anpassungen in einer privaten Testabteilung aufbewahrt werden:

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

In diesem Schema enthält die Mainline eine generische "Vorlage" -Konfigurationsdatei, die die minimale Menge an Anpassungen erfordert, um funktionsfähig zu werden.

Entwickler/Tester können nun die Konfigurationsdatei in den Inhalt ihres Herzens optimieren und diese Änderungen nur lokal auf einer privaten Testabteilung (z.B' = B + Anpassungen).Jedes Mal, wenn die Hauptstufe vorangetrieben, werden sie mühelos in Tests verschmilzt, was zu Merge -Commits wie D '(= D + Fusioned Version der Anpassungen von B) führt.

Dieses Schema kommt besonders gut zur Geltung, wenn die Konfigurationsdatei „template“ aktualisiert wird:Die Änderungen von beiden Seiten werden zusammengeführt und führen äußerst wahrscheinlich zu Konflikten (oder Testfehlern), wenn sie nicht kompatibel sind!

Ich habe die Vorlage schon einmal verwendet, d.h.web.dev.config, web.prod.config usw., bevorzugen aber jetzt die Technik „Datei überschreiben“.Die Datei web.config enthält die meisten Einstellungen, eine externe Datei enthält jedoch umgebungsspezifische Werte wie Datenbankverbindungen.Gute Erklärung dazu Paul Wilsons Blog.

Ich denke, dass dies die Menge an Duplikaten zwischen den Konfigurationsdateien reduziert, die beim Hinzufügen neuer Werte/Attribute zu Problemen führen können.

Ich habe immer alle Versionen der Konfigurationsdateien in der Quellcodeverwaltung gespeichert, im selben Ordner wie die Datei web.config.

Zum Beispiel

web.config
web.qa.config
web.staging.config
web.production.config

Ich bevorzuge diese Namenskonvention (im Gegensatz zu web.config.produktion oder produktion.web.config), weil

  • Es hält die Dateien zusammen, wenn Sie nach Dateinamen sortieren
  • Es hält die Dateien zusammen, wenn Sie sie nach Dateierweiterung sortieren
  • Wenn die Datei versehentlich in die Produktion übertragen wird, können Sie den Inhalt nicht über http sehen, da IIS die Bereitstellung von *.config-Dateien verhindert

Die Standardkonfigurationsdatei sollte so konfiguriert sein, dass Sie die Anwendung lokal auf Ihrem eigenen Computer ausführen können.

Am wichtigsten ist, dass diese Dateien in jeder Hinsicht, sogar in der Formatierung, nahezu 100 % identisch sind.Sie sollten in einer Version keine Tabulatoren und in einer anderen keine Leerzeichen zum Einrücken verwenden.Sie sollten in der Lage sein, ein Diff-Tool für die Dateien auszuführen, um genau zu sehen, was sich zwischen ihnen unterscheidet.Ich bevorzuge die Verwendung von WinMerge zum Vergleichen der Dateien.

Wenn Ihr Build-Prozess die Binärdateien erstellt, sollte es eine Aufgabe geben, die die web.config mit der für diese Umgebung geeigneten Konfigurationsdatei überschreibt.Wenn die Dateien gezippt sind, sollten die nicht relevanten Dateien aus diesem Build gelöscht werden.

@Grant hat recht.

Ich bin in einem Team mit fast 100 anderen Entwicklern und unsere Konfigurationsdateien werden nicht in die Quellcodeverwaltung eingecheckt.Wir haben Versionen der Dateien im Repository, die bei jedem Auschecken abgerufen werden, sich aber nicht ändern.

Bei uns hat es ganz gut geklappt.

Ich kontrolliere die Version, schiebe es aber nie auf die anderen Server.Wenn der Produktionsserver eine Änderung erfordert, nehme ich diese Änderung direkt an der Konfigurationsdatei vor.

Es ist vielleicht nicht schön, aber es funktioniert ganz gut.

Die eingecheckte Plain-Vanilla-Version von app/web.config sollte generisch genug sein, um auf allen Entwicklercomputern zu funktionieren, und bei allen neuen Einstellungsänderungen usw. auf dem neuesten Stand gehalten werden.Wenn Sie einen bestimmten Satz von Einstellungen für Entwicklungs-/Test-/Produktionseinstellungen benötigen, checken Sie separate Dateien mit diesen Einstellungen ein, wie GateKiller angegeben hat, mit einer Art Namenskonvention, obwohl ich normalerweise „web.prod.config“ verwende, da dies nicht der Fall ist um die Dateierweiterung zu ändern.

Wir verwenden eine Vorlagenkonfigurationsdatei, die in die Versionskontrolle eingecheckt wird, und anschließend einen Schritt in unserem automatisierten Build, um bestimmte Einträge in der Vorlagendatei durch umgebungsspezifische Einstellungen zu ersetzen.Die umgebungsspezifischen Einstellungen werden in einer separaten XML-Datei gespeichert, die ebenfalls der Versionskontrolle unterliegt.

Wir verwenden MSBuild in unserem automatisierten Build, daher verwenden wir die XmlUpdate-Aufgabe von MSBuild-Community-Aufgaben um die Werte zu aktualisieren.

Lange Zeit habe ich genau das getan, was bcwood getan hat.Ich behalte Kopien von web.dev.config, web.test.config, web.prod.config usw.unter Quellcodeverwaltung, und mein Build-/Bereitstellungssystem benennt sie dann automatisch um, wenn es in verschiedenen Umgebungen bereitgestellt wird.Man erhält ein gewisses Maß an Redundanz zwischen den Dateien (besonders mit all dem asp.net-Zeug darin), aber im Allgemeinen funktioniert es wirklich gut.Sie müssen auch sicherstellen, dass jeder im Team daran denkt, Updates durchzuführen alle die Dateien, wenn sie eine Änderung vornehmen.

Übrigens behalte ich gerne „.config“ am Ende als Erweiterung bei, damit Dateizuordnungen nicht kaputt gehen.

Was lokale Entwicklerversionen der Konfigurationsdatei betrifft, versuche ich immer mein Bestes, die Leute zu ermutigen, so oft wie möglich dieselben lokalen Einstellungen zu verwenden, sodass keine Notwendigkeit besteht, eine eigene Version zu haben.Es funktioniert nicht immer bei jedem. In diesem Fall ersetzen die Leute es normalerweise einfach vor Ort nach Bedarf und gehen von dort aus weiter.Es ist nicht zu schmerzhaft oder so.

In unserem Projekt haben wir die Konfiguration in Dateien mit einem Präfix gespeichert, dann ruft unser Build-System die entsprechende Konfiguration basierend auf dem Hostnamen des aktuellen Systems ab.Dies funktioniert gut für uns in einem relativ kleinen Team und ermöglicht es uns, Konfigurationsänderungen auf die Dateien anderer Personen anzuwenden, wenn wir ein neues Konfigurationselement hinzufügen.Offensichtlich ist dies definitiv nicht auf Open-Source-Projekte mit einer unbegrenzten Anzahl von Entwicklern anwendbar.

Wir haben hier zwei Probleme.

  • Zuerst müssen wir die Konfigurationsdatei kontrollieren, die mit der Software geliefert wird.

    Für einen Entwickler ist es leicht, unerwünschte Änderungen an der Master-Konfigurationsdatei einzuchecken, wenn er dieselbe Datei in der Entwicklungsumgebung verwendet.

    Wenn Sie andererseits über eine separate Konfigurationsdatei verfügen, die vom Installationsprogramm eingebunden wird, kann es sehr leicht passieren, dass Sie vergessen, ihr eine neue Einstellung hinzuzufügen, oder dass die darin enthaltenen Kommentare nicht mehr mit den Kommentaren in der Entwicklung synchron sind Konfigurationsdatei.

  • Dann haben wir das Problem, dass Entwickler ihre Kopie der Konfigurationsdatei auf dem neuesten Stand halten müssen, wenn andere Entwickler neue Konfigurationseinstellungen hinzufügen.Allerdings sind einige Einstellungen wie Datenbankverbindungszeichenfolgen für jeden Entwickler unterschiedlich.

  • Es gibt ein drittes Problem, das in den Fragen/Antworten nicht behandelt wird. Wie integrieren Sie die Änderungen, die ein Kunde an Ihrer Konfigurationsdatei vorgenommen hat, wenn Sie eine neue Version Ihrer Software installieren?

Ich habe noch keine guten Lösungen gesehen, die in allen Fällen gut funktionieren, aber ich habe einige gesehen Teillösungen(Dies kann nach Bedarf in verschiedenen Kombinationen kombiniert werden), was das Problem stark verringert.

  • Reduzieren Sie zunächst die Anzahl der Konfigurationselemente in Ihrer Hauptkonfigurationsdatei.

    Wenn Sie nicht zulassen müssen, dass Ihre Kunden Ihre Zuordnungen ändern, verwenden Sie Fluent NHibernate (oder anders), um die Konfiguration in Code zu verschieben.

    Ebenso für die Einrichtung der Abhängigkeitsinjektion.

  • Teilen Sie die Konfigurationsdatei nach Möglichkeit auf, z. B.Verwenden Sie eine separate Datei, um zu konfigurieren, was Log4Net protokolliert.

  • Wiederholen Sie keine Elemente zwischen vielen Konfigurationsdateien, z. B.Wenn Sie vier Webanwendungen haben, die alle auf demselben Computer installiert sind, verfügen Sie über eine Gesamtkonfigurationsdatei, auf die die Datei web.config in jeder Anwendung verweist.

    (Standardmäßig wird ein relativer Pfad verwendet, sodass es selten vorkommt, dass die Datei web.config geändert werden muss.)

  • Verarbeiten Sie die Entwicklungskonfigurationsdatei, um die Versandkonfigurationsdatei zu erhalten.

    Dies könnte durch Vorgabewerte in den XML-Kommentaren erfolgen, die dann in der Konfigurationsdatei festgelegt werden, wenn ein Build abgeschlossen ist.Oder Abschnitte, die im Rahmen der Erstellung des Installationsprogramms gelöscht werden.

  • Anstatt nur eine Datenbankverbindungszeichenfolge zu haben, sollten Sie eine pro Entwickler haben.

    Suchen Sie zum Beispiel zuerst zur Laufzeit in der Konfigurationsdatei nach „database_ianr“ (wobei ianr mein Benutzername oder Maschinenname ist). Wenn es nicht gefunden wird, suchen Sie nach „database“.

    Habe ein 2. Level „z.B.-oracle oder -sqlserver“ ermöglichen Entwicklern einen schnelleren Zugriff auf beide Datenbanksysteme.

    Dies ist natürlich auch für jeden anderen Konfigurationswert möglich.

    Dann können alle Werte, die auf „_userName“ enden, vor dem Versand der Konfigurationsdatei entfernt werden.

Am Ende ist Sie jedoch ein „Eigentümer der Konfigurationsdatei“, mit dem die Konfigurationsdatei (n) wie oben oder auf andere Weise verwaltet werden.Er/sie sollte vor jeder Sendung auch eine Differenz für die Konfigurationsdatei der Kundenfazings durchführen.

Man kann bei so einem Problem nicht auf eine fürsorgliche Person verzichten.

Ich glaube nicht, dass es eine einzige Lösung gibt, die für alle Fälle funktioniert, da dies möglicherweise von der Sensibilität der Daten in den Konfigurationsdateien oder der von Ihnen verwendeten Programmiersprache und vielen anderen Faktoren abhängt.Aber ich denke, es ist wichtig, die Konfigurationsdateien für alle Umgebungen unter Quellcodeverwaltung zu halten, damit Sie immer wissen, wann und von wem sie geändert wurden, und, was noch wichtiger ist, sie wiederherstellen können, wenn etwas schief geht.Und das werden sie.

Also hier ist, wie ich es mache.Dies gilt normalerweise für NodeJS-Projekte, aber ich denke, dass es auch für andere Frameworks und Sprachen funktioniert.

Ich erstelle eine configs Verzeichnis im Stammverzeichnis des Projekts und bewahren Sie unter diesem Verzeichnis mehrere Dateien für alle Umgebungen (und manchmal auch separate Dateien für die Umgebung jedes Entwicklers) auf, die alle in der Quellcodeverwaltung verfolgt werden.Und es gibt die eigentliche Datei, die der Code mit dem Namen verwendet config an der Wurzel des Projekts.Dies ist die einzige Datei, die nicht verfolgt wird.Es sieht also so aus

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

Wenn jemand das Projekt auscheckt, kopiert er die Konfigurationsdatei, die er im nicht verfolgten Bereich verwenden möchte config Es steht ihm frei, sie nach Belieben zu bearbeiten, er ist jedoch auch dafür verantwortlich, diese Änderungen zu kopieren, bevor er sie bei Bedarf auf die anderen Umgebungsdateien überträgt.

Und auf Servern kann die nicht verfolgte Datei einfach eine Kopie (oder Referenz) der verfolgten Datei sein, die dieser Umgebung entspricht.In JS können Sie einfach eine Zeile verwenden, um diese Datei anzufordern.

Dieser Ablauf mag zunächst etwas kompliziert sein, hat aber große Vorteile:1.Sie müssen sich nie Sorgen machen, dass eine Konfigurationsdatei ohne Backup 2 gelöscht oder geändert wird.Das Gleiche gilt, wenn ein Entwickler eine benutzerdefinierte Konfiguration auf seiner Maschine hat und seine Maschine aus irgendeinem Grund nicht mehr funktioniert.Vor jeder Bereitstellung können Sie die Konfigurationsdateien unterscheiden development Und staging Überprüfen Sie zum Beispiel, ob etwas fehlt oder kaputt ist.

Wir lassen einfach die Produktionskonfigurationsdatei eingecheckt.Es liegt in der Verantwortung des Entwicklers, die Datei zu ändern, wenn er sie für die Bereitstellung oder Entwicklung sicher aus dem Quellcode zieht.Das hat uns in der Vergangenheit verbrannt, deshalb würde ich es nicht vorschlagen.

Ich stand vor dem gleichen Problem und habe eine Lösung dafür gefunden.Ich habe zunächst alle Dateien zum zentralen Repository hinzugefügt (auch die Entwicklerdateien).

Wenn also ein Entwickler die Dateien aus dem Repository abruft, ist auch die Entwicklerkonfiguration vorhanden.Wenn an dieser Datei Änderungen vorgenommen werden, sollte Git diese Änderungen nicht bemerken.Auf diese Weise können Änderungen nicht in das Repository übertragen/festgeschrieben werden, sondern bleiben lokal.

Ich habe das mit dem Git-Befehl gelöst: update-index --assume-unchanged.Ich habe eine Bat-Datei erstellt, die im Prebuild der Projekte ausgeführt wird, die eine Datei enthalten, deren Änderungen von Git ignoriert werden sollen.Hier ist der Code, den ich in die bat-Datei eingefügt habe:

IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END

In meinem Prebuild würde ich die Bat-Datei aufrufen, zum Beispiel:

call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

Ich habe auf SO eine Bat-Datei gefunden, die die richtige Konfigurationsdatei in web.config/app.config kopiert.Ich rufe diese Bat-Datei auch im Prebuild auf.Der Code für diese Bat-Datei lautet:

@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2 
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same.  Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same.  Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.

In meinem Prebuild würde ich die Bat-Datei aufrufen, zum Beispiel:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top