Cum tratezi fișierele de configurare în controlul sursei?

Pentru mult timp, am făcut exact ceea ce a făcut bcwood-ul. Păstrez copii ale web.dev.config, web.test.config, web.prod.config etc., sub control sursă, iar apoi sistemul meu de construire / implementare le redenumește automat în timp ce se deplasează în diverse medii. Aveți o anumită sumă de redundanță între fișiere (mai ales cu toate lucrurile de pe asp.net), dar, în general, funcționează foarte bine. De asemenea, trebuie să vă asigurați că toată lumea din echipă își amintește să actualizeze toate fișierele atunci când fac o schimbare.

Apropo, îmi place să păstrez ".config" la sfârșit ca extensie, astfel încât asociațiile de fișiere să nu fie rupte.

În ceea ce privește versiunile de dezvoltatori locale ale fișierului de configurare, întotdeauna mă străduiesc să încurajez oamenii să folosească aceleași setări locale cât mai mult posibil, astfel încât să nu fie nevoie să aveți propria versiune. Nu funcționează întotdeauna pentru toată lumea, caz în care oamenii o înlocuiesc, de obicei, local, după cum este necesar, și merg de acolo. Nu e prea dureros sau nimic.

Tocmai păstrăm fișierul de configurare a producției verificat. Este responsabilitatea dezvoltatorului de a schimba fișierul atunci când îl scoate din sursă în siguranță pentru etapizare sau dezvoltare. Acest lucru ne-a ars în trecut, așa că nu aș sugera-o.

Folosim un fișier de configurare a șabloanelor care este bifat la controlul versiunii și apoi un pas în construirea noastră automată pentru a înlocui intrările specifice din fișierul șablon cu setările specifice mediului. Setările specifice mediului sunt stocate într-un fișier xml separat, care este, de asemenea, sub controlul versiunii.

Folosim MSBuild în construirea noastră automată, deci folosim sarcina XmlUpdate de la MSBuild Community Tasks pentru a actualiza valori.

@Grant are dreptate.

Sunt în echipa cu aproape 100 de dezvoltatori, iar fișierele noastre de configurare nu sunt verificate în controlul sursei. Avem versiuni ale fișierelor din depozit care sunt trase cu fiecare verificare, dar ele nu se schimbă.

Sa făcut destul de bine pentru noi.

Nu cred că există o singură soluție care să funcționeze pentru toate cazurile, deoarece poate depinde de sensibilitatea datelor din fișierele de configurare sau de limbajul de programare pe care îl folosiți și de alți factori. Dar cred că este important să păstrați fișierele de configurare pentru toate mediile aflate sub controlul sursei, astfel încât să puteți ști mereu când a fost schimbată și de către cine și, mai important, să o puteți recupera dacă lucrurile nu merg bine. Și vor.

Deci, iată cum fac asta. Acest lucru este pentru proiecte nodejs de obicei, dar cred că funcționează pentru alte cadre și limbi, de asemenea.

Ceea ce fac este să creez un director configs la rădăcina proiectului și în acest director să păstreze mai multe fișiere pentru toate mediile (și uneori fișiere separate pentru mediul fiecărui dezvoltator), toate urmărite Controlul surselor. Există și fișierul propriu-zis pe care codul îl folosește pe config la rădăcina proiectului. Acesta este singurul fișier care nu este urmărit. Arată așa

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

Când cineva verifică proiectul, copiază fișierul de configurare pe care dorește să îl folosească în fișierul config și nu poate să o edite așa cum dorește, dar este, de asemenea, responsabil să copieze aceste modificări înainte de a se angaja la alte fișiere de mediu, după cum este necesar.

Și pe servere, fișierul netracked poate fi pur și simplu o copie (sau o referință) a fișierului urmărit corespunzător acelui mediu. În JS puteți avea pur și simplu o linie pentru a solicita acest fișier.

Acest flux poate fi un pic mai complicat la început, dar are mari avantaje: 1. Nu trebuie să vă faceți griji că un fișier de configurare a fost șters sau modificat pe server fără a avea o copie de rezervă 2. Același lucru dacă un dezvoltator are unele config personalizate pe mașina lui și mașina lui nu mai lucrează pentru nici un motiv 3. Înainte de orice implementare, puteți difuza fișierele de configurare pentru development și staging de exemplu și vedeți dacă ceva lipsește sau este rupt.

+1 pentru abordarea șablonului.

Dar din moment ce această întrebare are eticheta Git, alternativa distribuită izvoare în minte, în care personalizările sunt păstrate pe o testare privată ramură:

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

În această schemă, linia principală conține o configurație generică, "șablon" fișier care necesită cantitatea minimă de ajustări pentru a deveni funcțională.

Acum, dezvoltatorii / testerii pot optimiza fișierul de configurare în inima lor conținut și comitem aceste modificări numai local pe una privată (de exemplu, B '= personalizări B +). De fiecare dată linia principală avansuri, le combină fără efort în testare, care are ca rezultat îmbinarea comitetelor, cum ar fi D '(= D + versiunea îmbinată a personalizărilor lui B).

Această schemă strălucește cu adevărat când fișierul de configurare "șablon" este actualizat: schimbările de la ambele părți devin fuzionate și sunt extrem de probabil să duceți la conflicte (sau la eșecuri de testare) dacă acestea sunt incompatibile!

Pe proiectul nostru avem o configurație stocată în fișiere cu un prefix, apoi sistemul nostru de construire trage în configurația corespunzătoare bazată pe numele de gazdă al sistemului curent. Acest lucru funcționează bine pentru noi într-o echipă relativ mică, permițându-ne să aplicăm modificări de configurare în fișierele altor persoane dacă / când adăugăm un nou element de configurare. Evident, acest lucru nu se limitează la proiecte open source cu un număr nelimitat de dezvoltatori.

Am folosit șablonul înainte, adică web.dev.config, web.prod.config, etc, dar acum preferă tehnica "suprascriere fișier". Fișierul web.config conține majoritatea setărilor, dar un fișier extern conține valori specifice mediului, cum ar fi conexiunile db. O explicație bună despre blogul lui Paul Wilson .

Cred că acest lucru reduce cantitatea de duplicare între fișierele de configurare care pot provoca durere atunci când se adaugă noi valori / atribute.

Soluția utilizată este să avem doar singurul fișier de configurare (web.config / app.config), dar adăugăm o secțiune specială fișierului care conține setări pentru toate mediile.

Există secțiuni LOCALE, DEV, QA, PRODUCTION , fiecare conținând cheile de configurare relevante pentru acel mediu în fișierul (ele) de configurare.

Ceea ce face ca toate acestea să funcționeze este un ansamblu numit xxx.Environment care face referire în toate aplicațiile noastre (winforms și webforms), care indică aplicației în ce mediu lucrează.

Ansamblul xxx.Environment citește o singură linie de informații de la machine.config a mașinii date care îi spune că este pe DEV, QA etc. Această intrare este prezentă pe toate stațiile de lucru și servere.

Sper că acest lucru vă ajută.

Am păstrat întotdeauna toate versiunile fișierelor de configurare în controlul sursă, în același folder ca și fișierul web.config.

De exemplu

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

Prefer această convenție de denumire (spre deosebire de web.config.production sau production.web.config) deoarece

• Păstrează fișierele împreună atunci când sortați după numele fișierului
• păstrează fișierele împreună atunci când sortați după extensia fișierelor
• Dacă fișierul intră accidental în producție, nu veți putea vedea conținutul peste http deoarece IIS va împiedica difuzarea fișierelor * .config

Fișierul de configurare implicit trebuie să fie configurat astfel încât să puteți rula aplicația local pe mașina proprie.

Cel mai important, aceste fișiere ar trebui să fie aproape 100% identice în fiecare aspect, chiar formatare. Nu trebuie să utilizați filele într-o singură versiune, iar spațiile în alta pentru indentare. Ar trebui să puteți rula un instrument diff împotriva fișierelor pentru a vedea exact ce este diferit între ele. Prefer să folosesc WinMerge pentru difuzarea fișierelor.

Când procesul dvs. de construire creează fișierele binare, ar trebui să existe o sarcină care suprascrie web.config-ul cu fișierul de configurare corespunzător acelui mediu. Dacă fișierele sunt închise, atunci fișierele care nu sunt relevante ar trebui să fie șterse din acea construcție.

M-am confruntat cu aceeași problemă și am găsit o soluție pentru asta. Am adăugat mai întâi toate fișierele la depozitul central (de asemenea, cele de dezvoltator).

Deci, dacă un dezvoltator preia fișierele din depozit, există și configurarea dezvoltatorului. Când se efectuează o modificare a acestui fișier, Git nu ar trebui să fie conștient de aceste modificări. În acest fel, schimbările nu pot fi împinse / angajate în depozit, ci rămân la nivel local.

Am rezolvat aceasta folosind comanda git: update-index --assume -changed . Am făcut un fișier de bat care este executat în prebuild pentru proiectele care conțin un fișier ale cărui modificări ar trebui ignorate de Git. Iată codul pe care l-am pus în fișierul de lilieci:

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

În prebuild mea aș fi sunat la fișierul de lilieci, de exemplu:

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

Am găsit pe SO un fișier de tip bat care copiază fișierul de configurare corect la web.config / app.config. De asemenea, numesc acest fișier bat în prebuild. Codul pentru acest fișier bat este:

@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.

În prebuild mea aș fi sunat la fișierul de lilieci, de exemplu:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config