Dotaz: jak vest vice projektu nad podobnymi zdrojaky

[Leoš Literák]

Hledam co nejlepsi zpusob, jak mit vice projektu nad skoro stejnymi zdrojaky, napriklad nasadit engine z abicka na jiny portal. Je jasne, ze 95% zdrojaku bude uplne stejnych. Zmeneno bude jen par desitek souboru, napriklad hodnoty konstant nebo HTML sablony. Zatim se mi jako nejlepsi jevi mit spolecne cvs a z druheho portalu udelat vetev a zmeny z maintrunku pak cas od casu zmergovat do teto vetve.

Napada vas lepsi zpusob? Podobny problem muze nastat, kdyz mate napriklad engine pro shopy a jeho nekolikere nasazeni.

Odpovědi

[finc]

Na toto téma se teď mluvilo na java.cz/konference.

Ja osobne bych si vytvoril vlastni skeleton a pomoci antu bych sestavoval jednotlive kusy tak, jak je potrebuji. Pri dodrzeni konvence "programovani vuci rozhrani" by nemel byt problem mit API a implementaci API, coz uz je vlastni customizace webu, pokud tedy chci mit moznost pro vsechny projekty update.

[Filip Jirsák]

Hodnoty konstant bych dal, pokud je to možné, do konfiguračních souborů (např. properties), a změněné soubory pak kopírovat třeba Antem z nějakého adresáře. Snažil bych se změny udržet na úrovni souborů, tj. aby nedošlo k tomu, že nějaký soubor bude skoro stejný pro dvě různé aplikace, ale bude se lišit v jednom řádku – to jde taky řešit, ale je to otrava. Mergování přes VCS bych se snažil vyhnout, je pak problém uhlídat, aby všude byla aktuální verze.

[Messa]

Jediný kód, vše specifické do konfigurace. Pokud je ono specifické složité (anebo obsahuje i netriviální funkčnost specifickou pro tu jednu aplikaci apod.), vytvořit pro to zvlášť modul a nakonfigurovat jeho používání.

[Leoš Literák]

To prave moc nejde. Co treba HTML sablony?

[Filip Jirsák]

Rozdělil bych je na společné části a na části specifické pro každý projekt, a ty do sebe vkládal pomocí include (FreeMarker pro to má hezkou podporu, kdy s hvězdičkou se hledá postupně v nadřazených adresářích – tím je možné udělat default). Ty specifické části pak mít uloženy pro každý projekt v samostatném adresáři a při buildu Antem podle nějakých parametrů nakopírovat ten správný adresář.

[happy barney]

popr vytvor viacero projektov:
- engine
- [projectA] / špecifické súbory (config, šablóny, pluginy ...)
- [projectB] / ....

popr správať sa v rámci jednotlivých projektov k engine ako ku "third party source" (je k tomu v cvs dokumentácii odstavec)

[Josef Kufner]

Tohle používám a funguje to. Jen to chce mít společné defaultní hodnoty a vše specifické pro konkrétní instalaci mít v nekolidujících souborech, aby se to lehce aktualizovalo.

Repozitáře používám pro každý projekt samostatné a z toho jednoho vývojového aktualizuju ostatní, když je to potřeba a chce se mi. Aktualizovat vše automaticky je nepraktické, páč se to občas podělá a člověk si to musí zbytečně moc hlídat, takle aktualizuju, jen když se v tom hrabu a nerozbije se to tedy "samo".

[Leoš Literák]

Souvisejici otazka: jak deployovat projekt z cvs/svn? Ten, kdo dela cvs/svn up, musi byt tim uzivatelem, ktery vycheckoutoval projekt. Tedy musel jsem rici sve heslo vsem, kdo mohou aktualizovat projekt. Je lepsi cesta? Me napada varianta, ze si kazdy udela vlastni checkout a pak se nejakym skriptem data nakopiruji do sdileneho adresare. V pripade takoveho skriptu by pak nemel byt problem s tim, ze by se projekt skladal z vice cvs modulu.

[Josef Kufner]

Co pověsit svn checkout na post-commit hook přímo do repositáře a všem tam dát práva ke čtení třeba rsyncem. Na vlastní update produkční instalace postačí jednoduchý skriptík.

[rastos]

Povol prístup cez ssh a v ssh nadefinuj, ktoré príkazy môže daný človek spúšťať napr. len "cvs export ..."

[happy barney]

pre cvs: pserver alebo spoločná skupina

[Leoš Literák]

pserver mame. Problem ale je, ze checkoutovany projekt je svazan s uzivatelem, ktery jej checkoutoval, tudiz AFAIK nikdo jiny nemuze na nem delat zadne svn operace.

[Josef Kufner]

Což je jen a jen dobře, protože se mu v tom nikdo nebude hrabat... ještě to tak...

Pokud jde o cestu repositář → svět, tak tam už do toho lidi nemají co kecat. Leda nějaký ten konfigurák někdy na začátku, ale víc ani ťuk. Všecko hezky automaticky, pod vyhrazeným účtem a člověk jen řekne: „Tahle revize se mi líbí, tu chci vydat.“

I takové zvrhlosti, jako tar coby login shell jsou lepší než to dělat ručně

[default]

Pokud jde o cestu repositář → svět, tak tam už do toho lidi nemají co kecat.

A v tomhle případě žádný svn co ale hezky poctivě svn export.

---

Navrhuju anketu:

Adresáře CVS/, .svn/…

• miluju je
• nevadí mi
• nesnáším je
• nenávidím je
• něco ještě mnohem horšího!

Osobně hlasuji pro poslední možnost.

[Josef Kufner]

svn export zbytečně zatíží server při commitu a zdržuje to. Onen checkout při commitu dělám do adresáře uvnitř repositáře a odtut zdrojové kódy distribuuju pomocí rsync (mám to na více strojích), kde už je uvedeno --exclude=.svn a navíc mi rsync vyrábí automaticky zálohy změněných souborů, což ulehčí opravy v případě problémů.

Tohle prostě záleží na celém procesu a adresáře .svn taky nemám rád

[default]

Onen checkout při commitu dělám do adresáře uvnitř repositáře

??? Teď si nerozumíme :-/ Já checkout dělat nemusím, protože po commitu mám ve working copy stejný stav jako v repozitáři. Export dělám jen tehdy, když sestavuji finální CD image nebo deployable package, což je maximálně jednou za týden…

[Josef Kufner]

No, ono po commitu mám stav v pracovním adresáři a repositáři také stejný, ale jde o to, že rsync kopíruje rychleji a má více možností konfigurace než svn export. Takže po commitu se automaticky updatne adresář na serveru, ze kterého pak skript s rsyncem aktualizuje podružné projekty, aniž by přepisoval jejich úpravy (různé soubory, kolize nejsou).

Nedávno jsem ale od svn upustil a používám jen git a všecko teď obstará prosté git pull po lokálním disku, což je ještě rychlejší a lze to dělat i offline. Commity z hlavního repositáře (= pracovního adresáře) pak jen občas pošlu do svn pomocí git svn dcommit. S tím, že starší projekty stále pouzívají svn.

Vlastní nasazení pak obstarává dvojice scriptů okolo rsyncu, jeden na upload do testovací instalace (to používám velmi často) a druhý pro update produkční verze z testovací. Tady už do toho žádné VCS nekecá vůbec, jen se zálohují měněné soubory.

[cronin]

Hmm. Cele to vypada celkom zaujimavo. Nechce sa Ti to rozpisat do clanku? Vyzera, ze sa pri tom postupe riesia mnohe problemy. Celkom by ma to zaujimalo.

[default]

Také bych se přimlouval. Specielně bych byl rád za ukázky použití toho gitu…

[Josef Kufner]

Tak s tím gitem je to velmi jednoduché: V hlavním repositáři (= pracovním adresáři) udělám nějaké změny a git commit. A v druhém pak jen git pull a změny se mergnou samy. Že nedochází ke kolizím, které bych musel ručně řešit, je zaručeno vhodnou adresářovou strukturou celého projektu a hledáním souborů na dvou místech (pro konkrétní projekt, které v hlavním repositáři neexistují, a defaultní pro všechny projekty).

V případě, že v "tom druhém" repositáři provedu nějaké úpravy, které nejsou specifické pro konkrétní projekt, vyrobím si patch, který aplikuju v hlavním repositáři (git diff > /tmp/patch; patch -p1 < /tmp/patch). Podrobnosti prozradí kdejaký tutoriál o gitu.

Když zakládám nový projekt odvozený od hlavního, použiju git clone, což rovnou nastaví i vše potřebné pro následné git pull. Opravdu v tom žádná magie není a pokud je, tak se o ní postará git

A jeden tip: git log --graph – je tam krásně vidět jak se to větví a spojuje a šmodrchá...

Ad článek: Nechce se mi moc vyzrazovat výrobní tajemství, ale nehledej v tom žádné složitosti. Celé to je jen o dvou jednoduchých skriptech s rsyncem, které si beztak musíš napsat sám sobě na míru.

[default]

No, myslím, že se na ten git asi někdy podívám. Ale moc se mi nechce. Nějak jsem už skeptický…

[happy barney]

btw, máte nejaký konkrétny dôvod nepoužívať v tomto prípade git push ?

[Josef Kufner]

Jednak jsem moc nezkoumal, co push dělá a druhak chci mít kontrolu nad přesným obsahem onoho patche -- většinou z něj ručně vyházím nějaký bordel nebo ho dělám jen nad pár soubory. Ale asi se na ten push kouknu trochu důkladněji až budu mít náladu

[happy barney]

no, skôr som myslel miesto kroku, kde používate pull
ok, len som sa pýtal, že či tam nie je náhodou nejaký problém, ktorý sa mi ešte neprejavil

[Josef Kufner]

Aha, tak tam je to jen o směru přenosu. Spouštím to vždy v repositáři, který aktualizuju z hlavního, proto pull.

[happy barney]

aha, asi mi zaplo, máš na mysli už samotné nasadenie aktuálnych zdrojákov? ak to chceš riešiť priamo checkoutom z cvs, tak to by som riešil separátnym accountom per nasadenie + v crone na cieľovom stroji cvs update voči konkrétnemu tagu (last-stable).