Zarządzanie przez subversion plików konfiguracyjnych projektu

Question

Co to jest najlepsza praktyka w używaniu subversion (SVN) do zarządzania projektem, który wymaga pojedynczego pliku konfiguracyjnego, który ma wiele równoczesnych wersji dla różnych środowisk.

tj.

• Projekt ABC jest używany w trzech różnych środowiskach, które używają tego samego kodu, z wyjątkiem lekko zmodyfikowanego pliku konfiguracyjnego. ORAZ
• Projekt ABC jest również rozwijany przez wielu programistów, przy użyciu nieznacznie zmodyfikowanego pliku konfiguracyjnego dla każdego programisty.

Zdaję sobie sprawę, że szablon plik konfiguracyjny i svn: ignore mogą być używane, ale zastanawiałem się, czy ktoś mógłby opisać najlepsze praktyki dla tego podejścia i/lub jakiekolwiek inne odpowiednie rozwiązania alternatywne.

Z góry dziękuję!

M.

Answer 1

ja nie wiem, czy jest to „najlepsze praktyki”, ale jest to w jaki sposób sobie z tym poradzić i to działa bardzo dobrze. Mam kilka aplikacji i każdy z nich ma oddzielny plik konfiguracyjny dla swoich środowisk produkcyjnych, testowych i deweloperskich. Konfiguracje mają nazwy web.config, stage.config i dev.config. Wszystkie trzy są objęte kontrolą wersji. Aplikacja oczekuje i używa web.config do pobierania ustawień konfiguracji. Jako część naszych skryptów budujących i instalacyjnych NANT, które są wywoływane przez tempomat, w zależności od wdrażanego środowiska, odpowiednia konfiguracja zostaje przemianowana na web.config i wdrożona.

Mam nadzieję, że to pomoże.

Answer 2

Utrzymanie wielu plików w kontroli źródła może być trudne. Używamy narzędzia do konfiguracji parzenia do domu, które odczytuje zmienną środowiskową systemu i odczytuje pasujący plik konfiguracyjny, a następnie modyfikuje udostępniony plik konfiguracyjny. Nie mogę powiedzieć, że to świetne rozwiązanie, ale działa.

Answer 3

Przez lata i wiele różnych udanych projektów, po prostu nie mam wersji systemu lub konkretnego pliku konfiguracyjnego programisty. Czasem jest to po prostu informacja o dostępie do bazy danych lub o kilku ważnych ścieżkach lub czymkolwiek. Zawęź to do tak małego jak to możliwe. Nie czuj się źle z powodu braku wersji tych informacji. Zrobiono to z każdym numerem od 2 do 5 programistów w kilku projektach i nigdy nie spowodowało to zamieszania, problemów ani debaty na temat projektów realizowanych w świecie rzeczywistym.

Answer 4

Moim zdaniem nie ma sensu utrzymywać wszystkich plików konfiguracyjnych pod kontrolą wersji. W jednym z moich projektów mieliśmy pliki konfiguracyjne, które zostały utworzone za pomocą cmake na kilka platform (z tego samego szablonu). Każdy deweloper w naszym zespole miał swój własny, dostosowany dodatkowy skrypt do tworzenia potrzebnych konfiguracji.