Rozgałęzienie: różne pliki konfiguracyjne do wydania/rozwoju

Question

Odziedziczyłem projekt i używamy gita. Mamy wiele środowisk (dev, test, prod). Poprzedni zespół w zasadzie odtwarzał wszystko w każdej instancji, używając tych samych kont, haseł, sidów itp. Jedyną zmianą było mapowanie nazw hostów w/etc/hosts. Aby połączyć się z innym serwerem bazy danych.

Teraz, to stwarza problem, bo nie można na przykład skopiować schemat tak, że deweloper może przeprowadzić eksperyment przy użyciu tej samej instancji bazy danych jako głównego serwera rozwoju. Zasadniczo muszę utworzyć nową instancję bazy danych na innym hoście i zmienić/etc/hosts, aby wskazać ten nowy serwer.

Choć jest to obecnie konfiguracja pracy, staram się znaleźć sposób, aby utrzymać różne pliki konfiguracyjne dla każdej instancji. tj: Różne wersje applicationConfig.xml w zależności od oddziału. Zgaduję, że można argumentować, że przechowywanie referencji bazy danych w repozytorium nie jest świetnym pomysłem, ale zignorujmy to na chwilę.

Inna sytuacja, która może uzasadniać konieczności inna wersja pliku może być debugowania. Powiedzmy, że używam struktury rejestratora javascript, a ja dodaję kod debugowania, którego nie chcę wysyłać z wersją produkcyjną. Nie chcę dodawać elementów rejestratora podczas rozwijania/testowania, a następnie usuwać je ponownie przed zwolnieniem. Ktoś mógłby zapomnieć to zrobić.

Jaki jest właściwy sposób radzić sobie z różnych „wersji” z pliku dla różnych gałęzi? Czy istnieje sposób na uzyskanie oddziału, który pozostaje zsynchronizowany z najnowszym kodem na master, ale z kilkoma plikami konfiguracyjnymi/kodowymi? Nie oczekuję, że pozostanie ona zsynchronizowana automatycznie, ale chciałbym móc nie scalać plików konfiguracyjnych (lub ich części), nie ignorując ich całkowicie (?). Na przykład: nie łącz linii 6,7 (nazwa użytkownika i hasło db), ale scalaj pozostałe zmiany w plikach.

Answer 1

Wygląda na to, że powinieneś przeczytać o atrybutach git. Check out the section at the bottom of this page

Jest to przydatne, jeśli oddział w projekcie odbiegał czy wyspecjalizowane, ale chcesz być w stanie scalić zmiany z powrotem z nim i chcesz ignorować pewnych plików. Załóżmy, że masz ustawienia bazy danych plik o nazwie database.xml że różni się w dwóch oddziałach, a chcesz połączyć w inny oddział nie psując pliku bazy danych.

Answer 2

Jak już wspomniano, przechowywanie ustawień konfiguracyjnych wewnątrz kodu nie jest dobrym pomysłem. W szczególności, twoi programiści nie powinni nawet znać referencji do bazy danych produkcyjnych, moim zdaniem.

Co robimy tutaj jest to, że na każdym serwerze mamy predefiniowane zmienne środowiskowe wskazujące do pliku konfiguracyjnego, który ma niezbędne poświadczenia. Ponieważ używamy tutaj Java, jest to plik taki jak database.properties, a ten plik nigdy nie znajduje się w systemie kontroli wersji.

To również sprawia, że ​​możliwe są różne ustawienia i różne poświadczenia na każdym serwerze