Toolbox: Jak mentax korzysta z SVN
Napisał scanner w kategorii Ogólne, tags: framework, mentax, subversion, svn, ZendJednym z podstawowych narzędzi, jakiego używa się podczas tworzenia oprogramowania – szczególnie, jeśli jest to praca zbiorowa – jest niewątpliwie jeden z wielu systemów kontroli wersji. To dzięki tej klasie oprogramowania możemy cieszyć się tym, że nie spotka nas niespodzianka z pamiętnymi „lub czasopisma” – system ten bowiem pamięta kto, co, gdzie i kiedy zmienił w danym dokumencie. Aplikacji takowych jest wiele, w różny sposób także one działają (client-server, p2p) i nie będę tutaj się zbytnio na ten temat rozpisywał, przynajmniej w tym momencie, tematem notki jest bowiem to, jak wykorzystujemy te narzędzie w codziennej pracy mentaxu.Specyfiką bowiem naszej pracy jest to, że nie tworzymy jednego produktu, który ma swoje wersje, rewizje i milestony, którymi się wygodnie zarządza. U nas, w ramach jednej klasy rozwiązań (którą roboczo nazywamy myCRM) istnieje wiele produktów opartych na tym samym jądrze oraz wykorzystujących prawie te same biblioteki zewnętrzne. Prawie, ponieważ nie zawsze wykorzystujemy w konkretnym projekcie np. pclzip, mimo że biblioteka ta jest dostępna w strukturze katalogów. Jako kontroler wersji wybraliśmy od samego początku SVN, który jest szybszy, wygodniejszy i ciekawszy niż wiekowy już nieco CVS. Oba te programy działają w architekturze client-server.
W naszych zasobach znajduje się kilka repozytoriów, które przechowują różne materiały (np. osobne repo dla stron WWW, osobne dla MyCRM) i wszystkie one maja podobną strukturę, którą zademonstruję na przykładzie repo MyCRM3:
Podczas tworzenia tego repozytorium postanowiliśmy, że foldery trunk, stable i tags zachowają swoją oryginalną funkcjonalność (czyli trunk jako inkubator, stable jako bazowa wersja stabilna i tags jako jako magazyn wersji „do zapamiętania”), problem natomiast pojawił się w momencie, gdy trzeba było równolegle pracować nad dwoma, trzeba, siedemnastoma projektami dla rożnych klientów, z których każdy ma odmienną specyfikację. Część osób, szczególnie z irc.php.pl zna ogólne założenia budowy naszego „systemu”, tych którzy zaś są ciekawi tego tematu zapraszam do jednej z następnych notek.
MyCRM3 bowiem składa się z trzech głównych części:
- SYS – czyli obsługa bazy danych, formularzy, walidatorów, podstawowe akcje, uprawnienia i cała reszta niezbędnego stuffu
- PROJECT – definicje projektu (formularze, akcje, configi itp.)
- LIBS – wszystkie biblioteki zewnętrze, jak np. wspomniany pclzip, fpdf czy PHPExcel
Postanowiliśmy, że folder(y) branches przechowywać będą wszystkie projekty z danej gałęzi, każdy we własnym subfolderze. Rozwiązanie to było na tyle dobre, że pozwalało dosyć szybko rozprowadzać zmiany w LIBS czy SYS na poszczególne instancje.
Otwarcie nowego projektu wiązało się z wykonaniem polecenia branch/tag na folderze stable i wskazaniu miejsca na nowe zlecenie. Szybko łatwo i przyjemnie.
Niestety wraz z rozwojem samego systemu jak i wzrostem liczby projektów, proces aktualizacji SYS/LIBS stawał się dość niewygodny – wielokrotne kopiowanie tych samych plików ze stable/ do branches/*/ mogło nieźle uprzykrzyć życie. Rozwiązaniem okazało się ustawienie wszystkich wspólnych folderów jako external (przy pomocy właściwości svn: externals). Dzięki temu każda zmiana w tych folderach dokonana czy to na poziomie danego brancha, czy stable ładnie propagowała się na pozostałe.
I trwałby taki stan dalej, gdyby nie fakt, że odświeżenie całego repozytorium, co wypada czasami robić (na co dzień siadając do pracy nad konkretnym projektem odświeżamy tylko jego folder domowy), trwa straszną ilość czasu, bowiem projektów nie ubywa, a przybywa. A z każdym z nich zwiększa się ilość odświeżeń każdego externala. Dlatego też, postanowiliśmy, przy okazji projektowania kolejnej serii MyCRM przekształcić zarówno podstawową budowę systemu, jak i jego repozytorium. Największym problemem było oczywiście odciążenie dysków od mielenia wciąż tych samych danych oraz takie zaprojektowanie budowy samego systemu, aby był jeszcze łatwiej skalowalny niż jest teraz.
Po dłuższej analizie, stworzyliśmy strukturę, którą widać na obrazku obok. Wygląda może nieco skomplikowanie, ale wszystko wskazuje na to, że dośc znacznie skrócimy czas odświeżania repo na maszynach developerów oraz uprościmy same prace rozwojowe. Ważne, aby zawsze pamiętać o kilku zasadach:
- Checkuot wykonujemy zawsze na folderze root, dzięki czemu tags nie jest widoczny (chyba że przy pomocy przeglądarki repozytorium), a tym samym nie jest pobierany na dysk pracownika.
- Wszelkie prace rozwojowe systemu wykonujemy klasycznie na danych znajdujących się w trunk
- Wszelkie prace rozwojowe projektów wykonujemy na danych w base
- Wersje zatwierdzone i uruchomione u Klienta znajdują się w stable
- svn:external służy tylko do dowiązania repozytoriów zewnętrznych
Co nam to daje? Ano to że np. zawsze mam na dysku aktualnego Zend Frameworka z bieżącej wersji 1.7. Wszystkie projekty korzystają z tego samego folderu libs/ zamiast z wielu oddzielnych jak to miało miejsce w serii 3.x – już nawet wolę nie liczyć ile razy na dysku mam np. phpMailer’a.
Niewielkim utrudnieniem jest to, że o ile w 3.x aby wrzucić projekt na ftp, wystarczyło skopiować zawartość jednego folderu- w nowym rozłożeniu dotyczyć to będzie trzech folderów, jednak ta drobna niedogodność rekompensowana jest pozostałymi zaletami.
Jak zapewne zauważyliście, w folderach libs widać dwa wpisy – Zend i Mentax. ten pierwszy to oczywiście ZF, drugi natomiast to dawny (3.x) SYS. Ponieważ bowiem przypominał on nieco swoją budową ZF, który z kolei posłuży do budowy serii 4.x, postanowiliśmy, że cały „Core” systemu będzie przez wszystkie projekty na nim oparte traktowany nie jako część składowa, ale jak zewnętrzna biblioteka, analogicznie do ZF.
Ponieważ notka się robi już nieco przydługa a godzina późna, pozwolę sobie w tym miejscu zakończyć, żeby za bardzo nie skomplikować przekazu. Jeśli macie jakieś wątpliwości, pytania i sugestie – komentarze stoją otworem, a ja postaram się wszystko zebrać razem i ewentualne odpowiedzi uwzględnić w kolejnym naszym spotkaniu.
Shoutbox RSS Feed
Wpisy (RSS)
Cześć,
tak z czystej ciekawości – jak robicie później deployment? Phing, paczki binarne, skrypt shellowy czy po prostu FTP?
Jak na razie wystarczy FTP.