Używanie kontroli wersji z niehierarchicznym kodem?

Question

Szukam umieszczenia podstawy kodu, która uruchamia kilka stron internetowych do kontroli wersji. Istnieje kilka przykładów tego kodu bazującego na witrynach na różnych serwerach wirtualnych.

Problem, z którym borykam się, polega na tym, że każda z tych oddzielnych instancji mniej więcej tego samego kodu ma podkatalogi z funkcjami specyficznymi dla witryny. Wygląda jednak na to, że systemy kontroli wersji chcą kontrolować całą hierarchię katalogów.

Na przykład każda instancja ma katalog

/www/smarty/libs/plugins/ 

gdzie znajdziesz funkcje site-specific dla smarty. Kiedy będziemy gotowi, aby wprowadzić go do kontroli wersji, folderem będzie katalog /www.

Jedną z opcji jest udostępnienie wszystkich funkcji specyficznych dla witryny wszystkim witrynom. Nie widzę problemu samo w sobie, ale wydaje się, że w jakiś sposób jest "zło" architektoniczne. Będzie kilka plików, które należą tylko do jednego wdrożenia.

Inną opcją jest posiadanie osobnego repozytorium dla poszczególnych plików witryny w obrębie bazy kodu. Ale brzmi to tak, jakby szybko mogło stać się koszmarem podczas próby poprawnego wdrożenia nowych witryn.

Jaki jest najlepszy sposób na zrobienie tego? System kontroli wersji, na który patrzymy, to subwersja.

Answer 1

Ogólnie, systemy kontroli źródła powinny być używane do sterowania źródłem. Nie są one w stanie całkowicie kontrolować hierarchii plików, uprawnień i innych powiązanych elementów. Te najlepiej pozostawić do konfiguracji wdrożenia.

Co powiesz na to, że każdy z projektów i katalogów, które potrzebujesz reprezentuje jeden raz w systemie kontroli wersji. Następnie, w oddzielnym katalogu (może nazywać się /build/), mają różne układy konfiguracji. Możesz mieć plik mrówek, który buduje każdą witrynę lub maven. Można również użyć narzędzi takich, jak lub Fabric, aby uzyskać większą kontrolę nad każdym wdrożeniem.

Answer 2

Uważam, że najlepszą rzeczą do zrobienia byłoby stworzenie katalogu najwyższego poziomu w repozytorium dla każdej witryny (Site-01, Site-02, itp.) I wewnątrz tych katalogów umieścić drzewo źródłowe. Następnie możesz sprawdzić projekty oddzielnie. Sądzę, że jest to akceptowalne i dość standardowe, aby używać tego samego repozytorium dla wszystkich projektów, w które zaangażowana jest Twoja firma.

Moja terminologia może nie pasować, ale podstawowa idea jest rozsądna, jak sądzę.

Answer 3

Narzędzia są wykonane jako elastyczne (ogólnie), więc oto kilka wskazówek:

1. Większość VCS”pozwalają na ignorowanie plików i katalogów za pomocą jakiegoś mechanizmu (np Mercurial .hg ignorować pliku), więc powinieneś być w stanie kierować to, czego chcesz/powinieneś kontrolować w porównaniu do tego, co nie powinno być.

2. Rozdziel pliki/katalogi na wspólny projekt zasobów i projekty specyficzne dla witryny, a następnie użyj systemu kompilacji do zintegrowania ich w celu utworzenia możliwego do wdrożenia pakietu. System kompilacji może być tak prosty jak skrypt powłoki lub bardziej wyrafinowany framework. Jeśli jest to naprawdę prosta integracja, VCS może mieć kilka podstawowych funkcji do łączenia baz (na przykład podbionów Mercurial).

Answer 4

z Subversion, można mieć kilka repozytoriów:

• www być w ogólnym repozytorium
• plugins każdy być w repozytorium site-specific

wtedy zagnieżdżone kopie robocze:

svn co http://www_repo www 
cd www/smarty/libs 
svn co http://foo_plugins_repo plugins 

Wskazówka: aby dodać pluginssvn:ignore własnością www/smarty/libs

svn propset svn:ignore "plugins" www/smarty/libs 

Można było na pewno to zrobić z git też (poprzez .gitignore) i prawdopodobnie z innymi systemami kontroli wersji, ale ja ich nie znam.

(Ewentualnie można pominąć część zagnieżdżone kopii roboczej (co może cudo niektórych ludzi) i sprawdzić stronę rzeczy siebie, ale użyć dowiązania zamiast smarty/libs/plugins, natomiast ignore nadal dotyczy)

Answer 5

You” brakuje kroku "kompilacja", który mógłby wziąć źródło w kontroli kodu źródłowego i utworzyć pakiety wdrażania dla różnych witryn. Potrzebny jest tylko jeden pakiet źródłowy, różne konfiguracje kompilacji tworzą różne pakiety wdrażania. Nie próbuj bezpośrednio umieścić zestaw deplyoment w kontroli źródła, to nie jest źródło!