Jak radzisz sobie z plikami konfiguracyjnymi w source control?

Nie wersja tego pliku. Wersja szablonu lub coś w tym stylu.

Konfiguracja jest kodem i powinieneś go wersję. Opieramy nasze pliki konfiguracyjne na nazwach użytkowników; zarówno w UNIX / Mac,jak i Windows możesz uzyskać dostęp do nazwy użytkownika i tak długo, jak są one unikalne dla projektu, jesteś w porządku. Możesz nawet nadpisać to w środowisku, ale ty powinieneś kontrolować wszystko.

Pozwala to również badać konfiguracje innych osób, które mogą pomóc zdiagnozować problemy związane z kompilacją i platformą.

Mój zespół przechowuje oddzielne wersje plików konfiguracyjnych dla każdego środowiska (web.config.dev, web.config.test, www.config.prod). Nasze Skrypty wdrożeniowe kopiują poprawną wersję, zmieniając jej nazwę na web.config. W ten sposób mamy pełną kontrolę wersji na plikach konfiguracyjnych dla każdego środowiska, możemy łatwo wykonać diff, itp.

Obecnie mam plik konfiguracyjny "template" z dodanym rozszerzeniem na przykład:

web.config.rename

Jednak widzę problem z tą metodą, jeśli zmiany krytyczne się zmieniły.

Rozwiązaniem, którego używamy, jest posiadanie tylko jednego pliku konfiguracyjnego (web.config / app.config), ale dodajemy do pliku specjalną sekcję zawierającą ustawienia dla wszystkich środowisk.

W naszych plikach konfiguracyjnych znajdują się sekcje LOCAL, DEV, QA, PRODUCTION, z których każda zawiera klucze konfiguracyjne odpowiednie dla tego środowiska.

To, co sprawia, że to wszystko działa, to zgromadzenie o nazwie XXX. Environment , do którego odwołujemy się we wszystkich naszych aplikacjach (winforms i webforms) który informuje aplikację, w którym środowisku działa.

Zespół XXX.Environment odczytuje pojedynczy wiersz informacji z maszyny .config danej maszyny, który mówi, że jest na DEV, QA, itp. Ten wpis jest obecny na wszystkich naszych stacjach roboczych i serwerach.

Mam nadzieję, że to pomoże.

+1 w odniesieniu do metody wzorcowej.

Ale ponieważ to pytanie ma tag Git, rozproszona alternatywa sprężyny do głowy, w którym dostosowywania są przechowywane na prywatnych testach "branch": {]}

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

W tym schemacie, linia główna zawiera ogólny," szablon " config plik wymagający minimalnej ilości korekt, aby stał się funkcjonalny.

Teraz Programiści / testerzy mogą dostosować plik konfiguracyjny do własnych potrzeb treści i zatwierdzać tylko te zmiany lokalnie na jednej prywatnej testowanie branch (np. B' = B + customizations). Za każdym razem mainline postępy, bez wysiłku łączą je w testy, co skutkuje Scal commity takie jak D' (=D + scalona wersja modyfikacji B).

Ten schemat naprawdę świeci, gdy plik konfiguracyjny" szablon " jest aktualizowany: zmiany z obu Stron się łączą i są bardzo prawdopodobne, że prowadzić do konfliktów (lub niepowodzeń testów), jeśli są one niezgodne!

Używałem już wcześniej szablonu, czyli web.dev.config, web.prod.config, etc, ale teraz preferuje technikę 'nadpisania pliku'. Sieć.plik konfiguracyjny zawiera większość ustawień, ale plik zewnętrzny zawiera wartości specyficzne dla środowiska, takie jak połączenia db. Dobre wyjaśnienie na Blog Paula Wilsona.

Myślę, że zmniejsza to ilość duplikacji między plikami konfiguracyjnymi, co może powodować ból przy dodawaniu nowych wartości / atrybutów.

@Grant ma rację.

Jestem w zespole z blisko 100 innymi programistami, a nasze pliki konfiguracyjne nie są sprawdzane w kontroli źródła. Mamy wersje plików w repozytorium, które są pobierane przy każdym sprawdzaniu, ale nie zmieniają się.

Wyszło nam całkiem nieźle.

Zawsze przechowywałem wszystkie wersje plików konfiguracyjnych w source control, w tym samym folderze co web.plik konfiguracyjny.

Na przykład

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

Wolę tę konwencję nazewnictwa (w przeciwieństwie do web.config.produkcja lub produkcja.www.config) ponieważ

• przechowuje pliki razem, gdy sortujesz według nazwy pliku
• przechowuje pliki razem, gdy sortujesz według rozszerzenia pliku
• Jeśli plik zostanie przypadkowo przesunięty do produkcji, nie będzie można zobaczyć zawartość przez http, ponieważ IIS uniemożliwi *.pliki konfiguracyjne z serwowanych

Domyślny plik konfiguracyjny powinien być tak skonfigurowany, aby można było uruchamiać aplikację lokalnie na własnym komputerze.

Co najważniejsze, pliki te powinny być prawie w 100% identyczne pod każdym względem, nawet formatowania. Nie należy używać tabulatorów w jednej wersji i spacji w innej do wcięć. Powinieneś być w stanie uruchomić narzędzie diff na plikach, aby zobaczyć, co dokładnie różni się między nimi. I wolę używać WinMerge do różnicowania plików.

Kiedy proces budowania tworzy pliki binarne, powinno być zadanie, które nadpisuje sieć.config z plikiem konfiguracyjnym odpowiednim dla tego środowiska. Jeśli pliki są spakowane, to nieistotne pliki powinny zostać usunięte z tej kompilacji.

Kontroluję go, ale nigdy nie wypycham go na inne serwery. Jeśli serwer produkcyjny wymaga zmiany, dokonuję tej zmiany bezpośrednio w pliku konfiguracyjnym.

Może nie jest ładny, ale działa dobrze.

The checked-in, plain-vanilla version of app / web.config powinien być na tyle ogólny, aby działał na wszystkich maszynach programistycznych i być na bieżąco z wszelkimi nowymi zmianami ustawień itp. Jeśli potrzebujesz określonego zestawu ustawień dla ustawień dev / test/production, sprawdź w osobnych plikach z tymi ustawieniami, jak stwierdził GateKiller, z jakąś konwencją nazewnictwa, chociaż zwykle idę z " web.prod.config", aby nie zmieniać rozszerzenia pliku.

Używamy pliku konfiguracyjnego szablonu, który jest sprawdzany w kontroli wersji, a następnie krok w naszej automatycznej kompilacji, aby zastąpić określone wpisy w pliku szablonu ustawieniami specyficznymi dla środowiska. Ustawienia specyficzne dla środowiska są przechowywane w oddzielnym pliku XML, który jest również pod kontrolą wersji.

Używamy MSBuild w naszej automatycznej kompilacji, więc używamy zadania XmlUpdate z MSBuild Community Task do aktualizacji wartości.

Przez długi czas robiłem dokładnie to, co zrobił bcwood. Przechowuję kopie sieci.dev.config, web.test.config, web.prod.config, itp. pod kontrolą źródła, a następnie mój system budowania/wdrażania zmienia nazwy ich automatycznie, gdy wdraża się w różnych środowiskach. Dostajesz pewną ilość nadmiarowości między plikami (zwłaszcza przy wszystkich asp.net rzeczy tam), ale generalnie działa naprawdę dobrze. Musisz również upewnić się, że wszyscy w zespole pamiętają, aby zaktualizować wszystkie pliki, gdy dokonają zmiany.

Przy okazji, Lubię zachować".config " na końcu jako rozszerzenie, aby skojarzenia plików nie zostały zerwane.

Jeśli chodzi o lokalne wersje deweloperskie pliku konfiguracyjnego, zawsze staram się jak najlepiej zachęcić ludzi do korzystania z tych samych ustawień lokalnych, tak aby nie było potrzeby posiadania własnej wersji. Nie zawsze działa dla wszystkich, w takim przypadku ludzie zwykle po prostu wymieniają go lokalnie w razie potrzeby i stamtąd idą. To nie jest zbyt bolesne czy coś.

W naszym projekcie mamy konfigurację zapisaną w plikach z prefiksem, a następnie nasz system kompilacji pobiera odpowiednią konfigurację opartą na bieżącej nazwie hosta systemu. To działa dobrze dla nas w stosunkowo małym zespole, pozwalając nam na stosowanie zmian konfiguracyjnych do plików innych osób, jeśli / kiedy dodamy nową pozycję konfiguracji. Oczywiście to zdecydowanie nie skaluje się do projektów open source z nieograniczoną liczbą deweloperów.

Po prostu sprawdzamy plik konfiguracyjny produkcji. Obowiązkiem dewelopera jest zmiana pliku, gdy wyciągnie go z bezpiecznego źródła w celu umieszczenia lub opracowania. To nas spaliło w przeszłości, więc nie sugerowałbym tego.

Mamy tu dwa problemy.

• Najpierw musimy kontrolować plik konfiguracyjny dostarczany wraz z oprogramowaniem.

  To wszystko jest łatwe dla programisty, aby sprawdzić niechciany do zmiany do głównego pliku konfiguracyjnego, jeśli używają tego samego pliku w środowisku devolvement.

  Z drugiej strony, jeśli masz oddzielny plik konfiguracyjny dołączony do instalatora, bardzo łatwo jest zapomnieć o dodaniu do niego nowego ustawienia lub pozwolić komentarze w nim się zsynchronizować z komentarzami w pliku konfiguracyjnym devolvement.

• Następnie mamy problem, że programiści muszą zachować kopię pliku konfiguracyjnego na bieżąco, gdy inni programiści dodają nowe ustawienia konfiguracyjne. Jednak niektóre ustawienia, takie jak ciągi połączeń z bazą danych, są różne dla każdego programisty.

• Istnieje trzeci problem, którego pytania/odpowiedzi nie obejmują. Jak połączyć zmiany wprowadzone przez Klienta do twojego plik konfiguracyjny po zainstalowaniu nowej wersji oprogramowania?

Jeszcze nie widziałem dobrego rozwiązania to działa dobrze we wszystkich przypadkach, jednak Widziałem pewne częściowe rozwiązania (które można łączyć w różne kombinacje w razie potrzeby), co zmniejsza problem często.

• Najpierw zmniejsz liczbę pozycji konfiguracyjnych, które masz w głównym pliku konfiguracyjnym.

  Jeśli nie masz potrzeby, aby pozwolić swoim klienci zmieniają mapowania, używają Fluent NHibernate (lub w inny sposób), aby przenieść konfigurację do kodu.

  Podobnie w przypadku iniekcji depency.

• Jeśli to możliwe, podziel plik konfiguracyjny, np. użyj oddzielnego pliku, aby skonfigurować logi Log4Net.

• Nie powtarzaj elementów między wieloma plikami konfiguracyjnymi, np. jeśli masz 4 aplikacje webowe, które są zainstalowane na tym samym komputerze, masz ogólny plik konfiguracyjny, który jest w sieci.config plik w każdej aplikacji wskazuje na.

  (domyślnie używa ścieżki względnej, więc rzadko trzeba zmieniać sieć.plik konfiguracyjny)

• Przetwarza plik konfiguracyjny rozwoju, aby uzyskać plik konfiguracyjny wysyłki.

  The could be done by mają domyślne wartości w komentarzach Xml, które są następnie ustawiane w pliku konfiguracyjnym po zakończeniu kompilacji. Lub o sekcje, które są usuwane w ramach procesu tworzenia instalatora.

• Zamiast z posiadania tylko jednego łańcucha połączeń z bazą danych, mieć jeden na deweloperów.

  Np. najpierw poszukaj "database_ianr" (gdzie ianr to moja nazwa użytkownika lub nazwa maszyny) w pliku konfiguracyjnym podczas uruchamiania, jeśli nie zostanie znaleziony, to poszukaj "database"

  Mają drugi poziom "np.-oracle lub-SQLServer", dzięki czemu programiści szybciej dostaną się do obu systemów bazodanowych.

  Można to oczywiście zrobić również dla dowolnej innej wartości konfiguracyjnej.

  Wtedy wszystkie wartości, które kończą się na "_userName" można usunąć przed wysłaniem pliku konfiguracyjnego.

Jednak w końcu to, czym jesteś, jest "właściciel pliku konfiguracyjnego", który bierze odpowiedzialność za zarządzanie plik konfiguracyjny jak wyżej lub inaczej. On / ona powinien również zrobić diff na okładzinach klienta plik konfiguracyjny przed każdym przesyłka.

Nie możesz usunąć potrzeby troskliwej osoby, która nie ma problemu.

Nie sądzę, że istnieje jedno rozwiązanie, które działa we wszystkich przypadkach, ponieważ może zależeć od wrażliwości danych w plikach konfiguracyjnych lub używanego języka programowania i wielu innych czynników. Ale myślę, że ważne jest, aby zachować pliki konfiguracyjne dla wszystkich środowisk pod kontrolą źródła, więc zawsze możesz wiedzieć, kiedy został zmieniony i przez kogo, a co ważniejsze, być w stanie go odzyskać, jeśli coś pójdzie nie tak. I zrobią to.

To, co robię, to tworzenie katalogu configs w katalogu głównym projektu, a pod nim przechowuję wiele plików dla wszystkich środowisk (a czasami również oddzielne pliki dla każdego środowiska programistycznego), które są śledzone w kontroli źródeł. W kodzie głównym projektu znajduje się plik, którego kod używa o nazwie config. Jest to jedyny plik, który nie jest śledzony. Wygląda na to, że to

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

Kiedy ktoś sprawdza projekt, kopiuje plik konfiguracyjny, którego chce użyć w niezatleczonym pliku config i może go dowolnie edytować, ale jest również odpowiedzialny za skopiowanie tych zmian przed zatwierdzeniem do innych plików środowiska w razie potrzeby.

I na serwerach, Nie śledzony plik może być po prostu kopią (lub odniesieniem) śledzonego pliku odpowiadającego temu środowisku. W JS możesz po prostu mieć 1 linię, aby wymagać tego pliku.

Przepływ ten może być na początku trochę skomplikowane, ale ma wielkie zalety: 1. Nigdy nie musisz się martwić, że plik konfiguracyjny zostanie usunięty lub zmodyfikowany na serwerze bez tworzenia kopii zapasowej 2. To samo, jeśli programista ma niestandardową konfigurację na swojej maszynie i jego maszyna przestaje działać z jakiegokolwiek powodu 3. Przed wdrożeniem możesz zmienić pliki konfiguracyjne dla development i staging na przykład i sprawdzić, czy czegoś nie brakuje lub nie działa.

Stanąłem przed tym samym problemem i znalazłem rozwiązanie dla niego. Najpierw dodałem wszystkie pliki do centralnego repozytorium (również te deweloperskie).

Więc jeśli programista pobiera pliki z repozytorium, tam jest również konfiguracja programisty. Podczas zmiany dokonanej w tym pliku, Git nie powinien być świadomy tych zmian. W ten sposób zmiany nie mogą być przesyłane/zatwierdzane do repozytorium, ale pozostają lokalnie.

Rozwiązałem to używając komendy git: update-index --assume-unchanged. Zrobiłem plik bat, który jest wykonywany w prebuild projektów zawierających plik, którego zmiany powinny być ignorowane przez Git. Oto kod, który umieściłem w pliku bat:

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

W moim prebuildzie wykonałbym wywołanie do pliku bat, na przykład:

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

Znalazłem na SO plik bat, który kopiuje poprawny plik konfiguracyjny do sieci.config / app.config. Ja również nazywam ten plik bat w prebuild. Kod dla tego pliku bat to:

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

W moim prebuildzie wykonałbym wywołanie do pliku bat, na przykład:

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