Zaczęliśmy od jednego programisty i jednego repozytorium svn zawierającego cały nasz kod:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(w tym czasie była to duża poprawa). Po tym, jak mieliśmy szansę się nieco rozwinąć, zaczęliśmy mieć problemy z zależnościami cyklicznymi, powolnymi testami i ogólnymi trudnościami w ponownym korzystaniu z kodu (ponieważ np. Zestaw funkcji witryny1 wkradł się w inny ogólny moduł a).
Chcąc zmodularyzować bazę kodu i oczekując, że wkrótce przejdziemy do git (i przeczytaliśmy gdzieś, że git nie lubi svn mega-repos), przeszliśmy do bardziej szczegółowej struktury:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
To było świetne pod względem koncepcyjnym. Bardziej modułowy kod, znacznie szybsze pakiety testowe, łatwiejsze do dokumentowania itp. Udostępniliśmy niektóre z naszych bardziej ogólnych komponentów i udostępniliśmy wszystkie moduły do instalacji pip (za pomocą pip install -e .ich instalacji w developmentvirtualenv).
Utworzyliśmy ^/srv/trunkrepozytorium zawierające strukturę folderów środowiska wykonawczego, tj. ^/srv/trunk/libdla modułów, /srv/trunk/srcpozostałości ^/foo/trunk, ^/srv/trunk/wwwstron internetowych itp.
I wreszcie (biorąc pod uwagę pomysł z perforce, z którym pracowałem bardzo dawno temu [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) stworzyliśmy „vcs- fetch ”plik tekstowy, w którym wymieniono wszystkie stosowne repozytorium i gdzie należy je wypisać do środowiska programistycznego, oraz odpowiednie polecenie, aby to zrobić. Np. Linia vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
spowodowałoby albo (pierwszy raz)
cd /srv/lib && svn co ^/module-a/trunk module-a
lub (później)
cd /srv/lib/module-a && svn up
i podobnie w przypadku repozytoriów github (zarówno naszych własnych, jak i zmienionych / niezmienionych pakietów dostawców).
Użyliśmy tego samego procesu vcs-fetch do stworzenia środowiska produkcyjnego, ale szybko dowiadujemy się, że nie mamy możliwości dowiedzieć się, która wersja działała w prod po wykonaniu vcs-fetch.
Dzięki mega-repo mogliśmy po prostu zanotować numer wersji przed zaktualizowaniem produ z pnia, a powrót był prosty svn -r nnn up .. Z kodem zarówno w svn, jak i git (i jednym module w hg) - i ~ 120 repos, nie jest oczywiste, jak to zrobić ..
Dzisiaj czytam http://12factor.net/ , a pierwszym czynnikiem jest „One codebase”, więc zastanawiam się też, czy nie jestem tutaj na dobrej drodze?
Jednym z moich pomysłów było stworzenie skryptu wdrażania, który utworzyłby koła „wdrażania” do zainstalowania przez pip i „spakował” je razem w requirements.txtpliku. Wdrożenie obejmowałoby następnie utworzenie nowego pliku virtualenv, instalację pliku pip wymagań.txt z listą kół wdrażania i przełączenie aktywnego pliku virtualenv. Powrót do poprzedniego wymagałby po prostu przełączenia virtualenv z powrotem (ale chyba, że chcieliśmy zachować virtualenvs na zawsze, nie pozwoliłoby nam to wrócić do dowolnego punktu w czasie - z mojego doświadczenia, które nigdy nie było potrzebne).
W tym momencie zastanawiam się, czy idę w złym kierunku, czy po prostu nie poszedłem wystarczająco daleko właściwą ścieżką ...? (wszystko, co czytam, mówi o „Twojej aplikacji” i nie wiem, jak to przekłada się na uruchamianie 14 stron internetowych z tej samej bazy kodu ...)