[Java lista] verziokovetes

[Gergely Hodicska]

Szia!


Kicsit hosszú lesz, de épp most dolgozgatom ki a saját felállásunk erre 
a célra. A rendszer PHP, de szerintem Javas projektre is jó.

> Eddig cvs-t hasznaltunk sima parancssorbol, de mar nem nagyon tudjuk 
> ezeket a dolgokat karban tartani.
Szerintem az SVN lényegesen jobb, mint a CVS (bár lsp válaszára még 
kíváncsi leszek):
o a commitok atomiak (CVS bármikor maradhat inkozisztens állapotban).
o CVS nem kezeli rendesen a könyvtárakat.
o CVS-ben nem tudsz normálisan átnevezni valamit (mondjuk ez az SVN-ben 
sem kerek)
o globális revision szám
o hatékonyabb binary kezelés
o lokálban van a BASE revision, sok funkcióhoz ezért nem kell a repóhoz 
fordulni
o a dróton csak a változásokat zavarja át, ergó gyorsabb
o van még sok apróság is (repo fromátum is hatékonyabb, ahogy én tudom)

> 5. barmi mas javaslat, eszerevetel, kerdes.
A mi rendszerunkben szempont volt, hogy minden szinten lehessen 
teszteket futtatni (ez most még nincs, ezért erről részletet nem tudok), 
vagy akár CI szervert használni.

Én a következő felállást találtam ki:

SVN szintjén van trunk, stage, prelive. A trunkban van a projekt. A 
stageben készülünk a következő releasre. A preliveban vannak a releasek 
(visszamenőleg elérhető pár darab, leginkább csak azért, hogy ha 
élesítéskor valamit benéznék, akkor egy mozdulattal vissza lehessen 
állni), ha már tuti nem kell, akkor átmozgatjuk egy oldies mappába (vagy 
akár törölhető is). Ezek mind elérhetők egy saját URL-en, így akár 
funkcionális teszteket is lehet futtatni rajtuk.

Bármit amit commitolunk az SVN-be, az ki syncelődik a szerverekre. Ez 
úgy néz ki (ill. fog kinézni), hogy van egy post commit handler, ami 
elvégzi a szükséges beállítások (pl. chmod amire kell, stb.), 
valószínűleg a többnyelvűsítéskor itt lesz egy build folyamat is, vagy 
bármi egyebet, amire itt még szükség lehet, és ha ezzel megvan, akkor 
rsync-kel kitolja a kész cuccot (ez mind trunk, stage, prelive szinten 
megtörténik).

Ezenkívül van a szervereken egy live könyvtár. Itt szintén releasek 
vannak, valamint egy current symlink, ez utóbbira van az éles rendszer 
vhostja(i) felépítve. Ha egy adott release a prelive-ban jónak tűnik, 
akkor minden szerveren átmásoljuk a live könyvtárba, majd ha minden 
készen van, akkor mindenhol átzavarjuk a symlinket. Ez részben azért is 
lett így, mert az átmozgatás időigényesebb lehet, míg a symlink 
változtatás nagyon gyorsan megvan, így rövidebb (nagyon röivid) ideig 
lesznek a szerverek esetlegesen inkozisztens állapotban.

A külön live prelive felállásra azért is szükség van, mert a bugfizeket 
közvetlenül a release prelivebeli könyvtárában készítjük el, majd 
commitoljuk, és akkor a prelive-on lehet még tesztelni, és ha oké, akkor 
rsync a live-ba. Azért jobb ide a bugfix, mert ehhez a kódhoz 
kapcsolódik, a trunk menetközben már el is térhet annyira, hogy ott a 
hibának már nincs létjogosultsága, ha meg kell, akkor vissza kell 
protolni a trunkba és a stage-be.

Egy dolgon még nem teljesen tiszta nálunk: trunk -> stage közti mozgás. 
Ha csak simán a fejlesztők commitolják a kész, tesztelt cuccukat a 
trunkba, akkor amikor mergelni akarunk a trunkból egy adott "feature"-t 
a stage-be, akkor ez nem egy túl explicit dolog. Erre a terv (csak nem 
tudom még, hogy adminisztrációs szinten mennyi lehet ennek az 
overheadje, illetve milyen jó eszközök léteznek erre a célra), hogy 
minden egyes feature úgy készül, hogy létrehozunk egy feature branch-et 
a trunkból, és ott készül el. Ha úgy döntünk, hogy a feature kész, és 
mehet a következő release-be, akkor ezt a feature branchet mergeljúk a 
trunkba és a stage-be. Előtte ha kell, akkor a fejlesztő szinkronba 
hozza a trunkkal.

Ebben az egészben még az is jó lehet, hogy a folyamatok nagy része 
automatizálható, illetve a feature branch-ek használatával jó esetben a 
merge-elés a stage-be is. Persze conflict esetén kézzel kell belenyúlni. 
Amit nem tudok tapasztalat nélkül most megbecsülni, hogy menyi olyan 
eset lehet, amikor két külön feature-höz hasonló dolgokra van szükség 
"library" szintjén, és két fejlesztő mondjuk ugyanazt másképp csinálja 
meg. Bár valószínűleg tervezés és kommunikációval ez megoldható (főleg a 
mi szintünkön).

Érdekelne, hogy aki nagyobb helyen dolgozik, ott van-e valami hasonló, 
vagy hogyan oldják ezt meg. Számomra ez a rendszer szimpinek tűnik, de 
tapasztalat még nincs vele, illetve most csinálgatok hozzá majd 
valamilyen admin felületet. Ezzel kapcsolatban ami még érdekes lehet, 
hogy végül úgy döntöttem, hogy nem svn log paranccsal fogok bűvészkedni, 
hanem a post commit handlerben mentek dolgokat DB-be, és állítok 
státuszokat, és a "kifrissítő" admin ezen fog alapulni. Szépen ki lehet 
listázni, hogy mondjuk a stage-ben milyen feature-ők vannak, adott 
release-be milyen bugfizek kerültek be, sync-ek gombnyomásra, ilyesmi.


Üdv,
Felhő