Re: OT: Ako a kde ukladat zakaznicke customizacie vo VCS?

[Benda Lukas]

Anebo se na to da rict, pouzivejte mavena :)) Taky jsem se snazil tohle 
vsechno udelat v antu, ale pak jsem si nainstaloval mavena a ten presne 
to co popisujete dela vlastne automaticky, paklize neurcite jinak. Takze 
se vase praxe jevi jako spravna :))
Ahoj,

    my pouzivame pro deleni zdrojovych kodu tri zakladni organizacni
jednotky - library, product line a project. Kazdy konkretni "item" dane
kategorie sestava z jednoho ci vice jaru ktere ho tvori.
    Liby jsou obecne systemove knohovny a frameworky bez konkretni business
funkcnosti, ale zapouzdrujici nejake systemove funkce - pristup do databaze,
apod... Jedna knihovna muze pouzivat jinou knihovnu, nicmene cyklicke odkazy
nejsou povoleny.
    Produktove linie jsou knihovny se specialni business funkcnosti,
vztahujicimu se ke konkretnimu nicmene zobecnitelnemu "business" problemu.
Produktova linie muze vnitrne pouzivat obecne knihovny nebo jine produktove
linie. Cyklicke odkazy mezi produktovymi liniemi nejsou povoleny
    Projekt pak znamena jednu konkretni implementaci, jeden konkretni
vysledny produkt (napr. pro jednoho konkretniho zakaznika s jeho specifiky,
apod.) Projekt muze pouzivat (v instalacnim setu obsahovat) jak obecne
knihovny, tak i produktove linie, projekty vzajemne se ale pouzivat nesmi.
    Prirozene, pokud je nejaka funkcnost ktera se ma chovat jinak na
konkretnim projektu, muze byt nutne to zohlednit nejakou konfiguracni
moznosti v produktove linii, nekdy pomuze zmena factory (resp. zmena
konfigurace u aliasu objektu, vytvareneho pod timto obecnym aliasem v
nadrazene produktove linii tak aby smeroval na zmenenou implementaci)...
    Zda se nam, ze to docela vyhovuje sdileni zdroju i v pripade jinych
programovacich jazyku a ruznych typu projektu. Diky tomuto deleni je mozne
vzdy separatne otestovat uvedene komponenty nezli se poskladaji dohromady
(kazdy jar s "produktivnimi" tridami ma i sveho partnera s "develop"
tridami, kde jsou m.j. JUnit testy apod.).

    Konkretne v Jave delime pak projekty na vrstvy - prezentacni vrstva
(pl), fasady business vrstvy (bl facade) a jadro business vrstvy (bl core) a
vrstvu pristupu k datum (dal) - nadrazena vrstva smi pouzivat vzdy jen
podrazenou - ale to je asi celkem bezna zalezitost.

    Pokud se tyka verzovani, i kdyz Subversion nepouzivame (nas VCS neumi
historii adresaru coz je pri javovskem strukturovani docela problem),
pouzivame obecne pouzitelny princip - verzujeme jednotlive jary pri jejich
buildu automaticky antem a dohromady je pak oznacime labelem ve VCS - pak
jsou vsechny jary spadajici k danemu produktu oznacene jednim labelem.
Vnitrne jary pak v manifestu obsahuji knihovny i s verzemi, ktere je nutno
mit, aby dana funkcnost korektne fungovala (knihovny i s jejich verzemi se
kterymi byla dana knihovna zkompilovana a tedy i otestovana). Protoze se
vytvari pro jistotu vzdycky i jary se zdrojaky a s dokumentaci dane verze
plus v pripade potreby jdiff pro rozdilovou dokumentaci a to vse se pak
oznacuje i labelem ve VCS, mame jistotu ze i v pripade uzivatelske nebo
systemove chyby VCS jsme schopni zrekonstruovat odpovidajici stav (resp.
mame ho dvojmo - jednou primo jako verzi zdrojovych souboru primo ve VCS a
jednou jeste v jaru vzdy pro danou verzi).
    Build antem pak umi i prekompilovat v pripade potreby celou kaskadu
vzajemne se pouzivajicich podprojektu (jaru) - jeste tedy se ty jary musi
rucne checkinovat a checkoutovat, ale to se obecne da taky zvladnout
automaticky - tim ze se verzovani posunuje v praxi z urovne trid na uroven
jaru se cela vec docela zjednodusuje.
    Samozrejme se snazime mit od jednoho produktu co nejmene verzi, nastesti
nas prilis netrapi muset delat paralelni vyvoj nove funkcnosti (nepocitam
opravy) pro vice verzi jednoho produktu, to je celkem malokdy a snad se tomu
da temer vzdy administrativne predejit... Nicmene pokud je to nutne napr.
pro jednoho zakaznika udelat nejakou zmenu specifickou a narychlo, melo by
to zasahnout jen jeho projekt a ostatni projekty to snad nezasahne.

    Tolik teorie :-).

        Ahoj, Artur.

----- Original Message ----- 
From: "Benda Lukas" <[EMAIL PROTECTED]>
To: "Java" <konference@java.cz>
Sent: Tuesday, October 10, 2006 6:04 PM
Subject: Re: OT: Ako a kde ukladat zakaznicke customizacie vo VCS?


  
Asi je to otazka poctu zakazniku, firemni politiky a schopnosti daneho
zarizeni. Ale ja resim, vse pomoci parametru, tudiz, aplikace umi vzdy
vse jen je nutno ji nastavit tak aby to delala. Je sice pravda, ze
odmazani kusu kodu, nebo prepsani je casove mene narocne, ale vetsinou
tu upravu casem chce i nekdo jiny a hlavne nemusim pro kazdeho zakaznika
delat zvlast kompilaci.

Ty parametry jsou v XML souboru nastavene pres spring.

Mam i zarizeni (ctecka carovych kodu), ktera ma ruzna omezeni a tam se
bohuzel musim uchylovat prave k specialnimu programu pro kazdeho
zakaznika, ale musim rict ze mi to velmi nevyhovuje. Nejhorsi je kdyz
prijdu k novemu potencialnimu zakaznikovi a predvadim mu schopnosti
onoho zarizeni a pri predvadeni nejake Cool funkce zjistim, ze ta je ve
verzi pro jineho zakaznika nez mam prave nahrano v ctecce, to by mne
vzdycky mohl cert urvat.

Lukas "benzin" Benda ([EMAIL PROTECTED];  http://benzin.bloguje.cz)
 Java a Delphi programator
 PHP a JavaScript skrypter
 Tvurce databazovych aplikaci
 A "cestinarsky" ignorant
    
Zdravim!

Moja otazka sa netyka priamo javy, preto som ju oznacil OT, ale s
      
vyvojom
  
velmi uzko suvisi a mnohi z vas tento problem riesili a verim ze aj
vyriesili.

Mame projekt, ktory obsahuje niekolko standalone javovskych modulov,
      
t.j.
  
standalone aplikacii, web aplikaciu a nejaky core, ktory je poskytovany
modulom ako kniznica (jar). Problem je, ze aplikaciu je potrebne pre
jednotlivych zakaznikov customizovat. Zakaznikov nie je velke mnozstvo
(radove jednotky), ale pre kazdeho z nich sa robia upravy, ktore su len
pre neho.  Tieto customizacie su od loga a farbiciek v css webovej
aplikacie, cez defaultne jazykove mutacie, samostatne schemy v DB az po
upravy zdrojoveho kodu, ked napr. pre zakaznika X mozu byt baliky (v
zmysle java packages) A, B.A a B.B, pre zakaznika Y to mozu byt B.B a C,
etc.

Problem je, ako udrziavat jednotlive customizacie vo VCS (konkretne
pouzivame Subversion). Customizacie by mali byt dostatocne oddelene od
core, ale zaroven by malo byt co mozno najjednoduchsie checkoutovat,
buildovat, instalovat a testovat verziu pre kazdeho zo zakaznikov. Takze
otazka je: Ako oddelujete zakaznicke customizacie od produktu a ako ich
      
v
  
pripade potreby na projekt aplikujete?

Vdaka za rady a napady.

J.