Częściowo edytowalne pliki (np. Pliki konfiguracyjne) i kontrola wersji - najlepsze praktyki?

Question

Więc, dzisiaj zabiłem kompilacji, sprawdzając plik konfiguracyjny. Wie, gdzie jest serwer (pomyśl o serwerze SQL lub tym podobnym), a ja pracowałem przeciwko serwerowi, który działa na moim komputerze. Zwykle, a raczej w innych okolicznościach, ucieklibyśmy na serwer centralny. Codzienna kompilacja oczywiście nie odnalazła "mojego" serwera, stąd złamanie. Potem znowu edytowanie pliku konfiguracyjnego, aby wskazywał na "normalny" serwer przed checkinem, i edytowanie go ponownie po meldowaniu jest bardzo interesujące.

Kusiło mnie, żebym VC po prostu zignorował plik konfiguracyjny, aby nie został przypadkowo sprawdzony. Z drugiej strony, repozytorium powinno zawierać czystą, użyteczną wersję pliku. Nie mogę tego zignorować i mogę to sprawdzić w tym samym czasie, prawda?

Tak więc, szukam sposobu, aby mieć plik, który, errr, który sprawdza, ale nigdy nie sprawdza. Przynajmniej w najczęstszym przypadku - jeśli plik konfiguracyjny ulegnie znacznej zmianie, niektóre specjalne Procedura umożliwiająca pobranie nowej wersji do repozytorium jest wykonalna.

Jeśli wcześniej napotkali Państwo ten problem, byłbym zainteresowany rozwiązaniami, które Państwo znaleźli. Tak długo, jak nie łamią kompilacji, oznacza to;)

Answer 1

Co można zrobić, to mieć domyślny plik konfiguracyjny, który pozostaje niezmieniony, chyba że dodana zostanie nowa konfiguracja. Następnie masz inny plik, który zastępuje domyślne konfiguracje pliku.

config.Default.xml 
config.User.xml 

Tylko config.Default.xml jest sterowany przez źródło. config.User.xml zawiera tylko konfiguracje, które są różne dla ciebie. Powiedzmy, że testujesz na lokalnym serwerze SQL, wstawiasz tam tylko ciąg połączenia, który zastąpi ciąg połączenia config.Default.

Spójrz na .Net Framwork Application Configuration, wykonuje większość (jeśli nie wszystkie) pracy za Ciebie.

Answer 2

Jedną z używanych przeze mnie metod jest posiadanie dwóch wersji pliku konfiguracyjnego i pobranie skryptu instalatora z prawidłowej wersji.

• settings.xml
• settings.xml-Release

Oba pliki zawierają te same klucze, ale jeden zawiera wartości „dev”, a drugi zawiera wartości oczekujemy wdrożyć i być edytowane w polu.

Answer 3

Gdy pracuję, mamy oddzielne pliki konfiguracyjne dla wdrożeń. Pliki konfiguracyjne w naszych rozwiązaniach są wersjami programistycznymi, a ludzie mogą je zmienić na zawartość swoich serc. Te pliki konfiguracyjne nigdy nie są wdrażane w dowolnym miejscu.

Założone pliki konfiguracyjne są przechowywane w oddzielnym miejscu w naszym dostawcy kontroli źródła. Jeśli ktoś musi dokonać zmiany konfiguracji, która zostanie wdrożona, musi zmodyfikować tę wersję.

Answer 4

Pliki tego typu przechowujemy w naszym systemie kontroli źródła i mają różne foldery dla środowiska, dla którego budujemy.

Więc mamy:

Dev 
Test 
Live 

Są one pod podfoldery dla konkretnych plików innym środowisku.

Answer 5

Mamy

• *. (Config | xml)
• *. (Config | xml) .cert
• *. (Config | xml) .production

Hudson usuwa początkowy plik i wdraża poprawny plik dla właściwego środowiska (obecnie tylko certyfikat).

Pozwala to programistom na samodzielne dokumentowanie i rozwijanie plików konfiguracyjnych produkcji, certyfikatów i programów rozwojowych oraz ich oddzielne wersjonowanie w SVN.

Answer 6

Dla każdego pliku konfiguracyjnego x, utwórz plik do sprawdzenia o nazwie x.dist, który jest domyślną konfiguracją rozproszoną. Po tym, jak deweloperzy się wypróbują, przygotuj skrypt, który skopiuje każdy plik x.dist do x, gdzie może dostosować x tak, jak to konieczne. Skrypt ten można ponownie uruchomić, aby zaktualizować pliki po dużych zmianach, lub programiści mogą ręcznie scalać swoje zmiany.

W celu wdrożenia można sprawdzić pliki na żywo podczas wdrażania, a skrypty uruchomieniowe odwołują się do nich jawnie (np. --config x.production).

Takie podejście jest używane, na przykład, w sposobie dystrybucji Wordpress (należy skopiować plik szablonu wp-config.php) lub w projektach programistycznych, które używają autoconf (gdzie plik configure.ac jest włączony, ale plik konfiguracyjny musi być wygenerowany przez każdego programistę, specjalny plik konfiguracyjny jest zbudowany do dystrybucji w paczkach w czasie wydania).

Answer 7

Myślę, że zaakceptowana odpowiedź jest dobra, ale w zależności od wymagań może mieć ograniczenia.

Stosujemy następujące podejście. Zauważ, że jesteśmy sklepem .NET używającym VS i korzystamy z zadań MSBuild (wbudowane, społecznościowe i niestandardowe).

• App.config jest ignorowany przez kontrolę wersji, ale zawarte w projekcie.
• App.default.config znajduje się pod kontrolą wersji i jest częścią projektu. Zamiast trudnych kodów rzeczy, które mogą się zmienić, np. W przypadku ciągów połączeń db używamy tokenów.

BeforeBuild zadaniem projekt wygląda na istnieniu w app.config i jeśli nie znaleziono kopie App.default.config do app.config. Ponadto serwer kompilacji zawsze usuwa App.config, jeśli istnieje na kompilacji CI (zapewnia czystą konfigurację). Następnie używamy zadania FileUpdate społeczności MSBuild, aby zastąpić tokeny odpowiednimi wartościami na podstawie tego, co buduje projekt.

Na przykład, świeże deweloper Zamówienie możliwe ciągi połączeń konfiguracja dB dla lokalnej bazy danych, nightly build, można skonfigurować na nocne db itp

Answer 8

Zaakceptowanych odpowiedź jest dobra.Jednak możliwe jest zrobienie tego, co chciałeś (4 lata temu), i utrzymywanie tylko jednego pliku konfiguracyjnego, który sprawdza się i nigdy nie sprawdza - jeśli twój system kontroli wersji ma koncepcję listy zmian. Zrobiłem to w Perforce:

Sprawdź plik konfiguracyjny i pozostaw go w swojej własnej liście zmian. Po zatwierdzeniu, zatwierdzaj tylko inne listy zmian; to jest łatwe do zapamiętania, jeśli nazwiesz listę zmian w pliku konfiguracyjnym, na przykład "NIE ZATWIERDŹ".

Zaletą tego systemu jest to, że jeśli ktoś inny zmieni wersję produkcyjną pliku konfiguracyjnego - tj. Takiego, który istnieje na serwerze i który wszyscy utrzymują zmodyfikowaną wersję lokalną - zostaniesz powiadomiony możliwych konfliktów, gdy otrzymasz plik konfiguracyjny z serwera. Przy takim rozwiązaniu sugerowanym w zaakceptowanej odpowiedzi, możesz milcząco nadpisywać nowe ustawienia produkcyjne lokalnymi ustawieniami, które mogą złamać lokalną kompilację lub spowodować, że będziesz łamał kompilację podczas następnego zatwierdzania.