Jeden projekt pro více zákazníků

[Krtek + Krtek]

Zdravim,

chystam se na jeden projekt (webova applikace v Jave), pricemz pro tuto aplikaci budu mit nekolik zakazniku v radu jednotek (5 - 10 zakazniku). Pro kazdeho zakaznika bude aplikace bezet na jemu vyhrazenych serverech (tyto servery budu mit ve sve sprave ja, zakaznici budou pouzivat pouze danou aplikaci). A jedna se mi o to, co je "best practice" pro vyvoj takoveto aplikace, kde priblizne 90% kodu bude spolecneho pro vsechny zakazniky a tech zbyvajicich 10% kodu budou specifika jednotlivych zakazniku.
Zajima me treba jak se nejlip popasovat s drobnymi odchylkami databazoveho schematu (napr. nutnost pro nektereho zakaznika evidovat navic nektere attributy urcitych entit z duvodu mistni legislativy apod.). ORM framework chci pouzit JPA z cehoz vyplyva urcita zavislost Javovskych trid mezi sebou. Moje idea zatim je takova, ze pro tech specifickych 10% kodu na zakaznika bych narval do oddeleneho jar souboru, pricemz pri deployi aplikace pro daneho zakaznika by se takto pribalil jeho specificky jar soubor.
Na buildovani projektu chci vyuzit Maven a pocitam ze s vyuzitim profilu by toho mohlo jit dosahnout.
Dalsi vec je repository se source codem (svn?, git?) a bug fixing, pripadne vytvareni novych features prave v te spolecne casti kodu? Vidite zde nejaka uskali a ktery z danych nastroju je podle vas vhodnejsi? Bohuzel ja sam mam zkusenosti pouze s svn, takze nemuzu moc porovnavat.
Diky za odpovedi.

[Reklama]

[to_je_jedno]

javu neznam, reknu jedine: svn pro novy projekt je nesmysl (pokud to nema dlouhodobou historii ve firme, napojeni na infrastrukturu a tak.)

[Mirek Prýmek]

Jak to nejlíp řešit v javě neporadím, ale co se týče VCS, v gitu se branchování, mergování apod. dělá hodně dobře, včetně rebase a cherrypick* a díky jednoduchosti formátu je to krásně přehledný.

Se SVN porovnat neumím, ale git mi přijde jako hodně dobrej nástroj, se kterým se pěkně pracuje, včetně případnýho ručního vrtání se v jeho vnitřnostech (v případě, že nevím, jak něco udělat automaticky, potřebuju něco ručně opravit atd...).

Myslím, že s GITem neprohloupíš

*
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html

[none_]

S tím programováním je to vždycky těžký. Záleží na tom, jak moc se toho liší mezi těmi klienty. Pokud je to alespoň v jedné specifické oblasti, tak by to mělo být v pohodě. Pokud se každý bude lišit v něčem jiném, tak jsi v pytli.

Jinak to s těma jar-kama je podle mě správná cesta. Konkrétní implementace záleží na tom, jestli se liší v nějaké službě nebo mají specifickou celou část od DB po View. Takhle bez dalších informací se nedá víc říct.

[to_je_jedno]

ja jsem obcas donucen neco s SVN delat, bohuzel . uz ve dvou vyvojarich mame obcas problem. s gitem je to uplne jinde.

[Reklama]

[Ivan]

Pokud zacinas, tak bych doporucil git. Na verzovani db schematu se poduk mozno vykaslej. Je to spousta prace a navic budes muset resit modifikace stavajich dat, pri zmene DB struktury. Urcite si usetris spoustu casu pokud navrhnes DB schema dostatecne univerzalni aby mohlo slouzit vsem zakaznikum najednou.

[Krtek + Krtek]

Tak na git jsem slysel/cet spoustu chvaly oproti svn, takze se v nem chci trochu pohrabat tak jako tak (diky za linky, kouknu na to).
Co se db tyka, tak pocitam, ze velka vetsina struktury dat bude spolecna, nimene jak jsem psal, z duvodu mistni legislativy ocekavam drobne rozdily v podobe sem tam nakyho atributu na tabulku navic. Pak se totiz nejedna jen o tu db, ale souvisi s tim i "drobna" odlisnost ve view (nejake fieldy navic ve formulari, jejich validace apod. + sem tam nejake to tlacitko navic pro urciteho zakaznika). Ale ocekavam opravdu odlisnost jen v detailech. Jelikoz se dany projek teprve chystam vytvorit, tak by me prave zajimalo predem jak se vyporadat s temito drobnymi odlisnostmi pro urcite zakazniky, jak nastavit strukturu projektu, abych s tim uz pocital dopredu, protoze ty odlisnosti urcite vzniknou, a nesnazil se to nejak haluzove napasovat pozdeji az teprve vznikne nejaky problem.

Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..

[nohous]

Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..

Jestli jsou rozdili takhle trivialni, tak drz kod spolecnej - bude umet vsechno a pro konkretni zakazniky budes featury disablovat compile-time nejakym "#define" (ja vim, java), pripadne parametrem v nastaveni.

[Ivan]

Tak na git jsem slysel/cet spoustu chvaly oproti svn, takze se v nem chci trochu pohrabat tak jako tak (diky za linky, kouknu na to).
Co se db tyka, tak pocitam, ze velka vetsina struktury dat bude spolecna, nimene jak jsem psal, z duvodu mistni legislativy ocekavam drobne rozdily v podobe sem tam nakyho atributu na tabulku navic. Pak se totiz nejedna jen o tu db, ale souvisi s tim i "drobna" odlisnost ve view (nejake fieldy navic ve formulari, jejich validace apod. + sem tam nejake to tlacitko navic pro urciteho zakaznika). Ale ocekavam opravdu odlisnost jen v detailech. Jelikoz se dany projek teprve chystam vytvorit, tak by me prave zajimalo predem jak se vyporadat s temito drobnymi odlisnostmi pro urcite zakazniky, jak nastavit strukturu projektu, abych s tim uz pocital dopredu, protoze ty odlisnosti urcite vzniknou, a nesnazil se to nejak haluzove napasovat pozdeji az teprve vznikne nejaky problem.

Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..

Pokud jde o neco takovyho tak bych - alespon na neco - doporucil pouzit EAV. Zvlast jestli ta DB bude mala.
Takze budes mit tabulku PERSON s pevnyma sloupcema a pak tabulku CUSTOMER_PERSON_DETAIL
kde bude "PERSON_ID", "DETAIL_NAME", "DETAIL_VALUE". Dulezity je aby ty pridavny atributy nebyly soucasti PK ani FK.
Jakmile budes mit u ruznych zakazniku ruznou verzi DB schematu tak se z toho drive nebo pozdeji zblaznis.
Po par aktualizacich uz ani nebudes tusit, v jakym poradi jsou ktery sloupecky u kteryho zakaznika.

Videl jsem i systemy, kde se DB schema generovalo primo z objektoveho modelu aplikace. Po par letech to ale vetsinou skouncilo.
Jakmile mas v produkcni databazi nekolik GB dat, tak musis zmeny ve schematu resit "rucne" a chytre - zadny tool ti nepomuze.

[Kit]

Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo)...

Udělej si další tabulku, do které si uložíš konfiguraci daného zákazníka. Ve Factory si nejprve načteš tuto konfiguraci a podle ní vyrobíš ty správné objekty.