Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?
Ahoj, to tak vlastně mám. To přetěžování přes appky per klient zvážím, ale asi až při větších změnách, jinak by mohly (do určitého času) stačit výhybky. Ale jdu do něčeho takového poprvé, ale tuším, že od určitého počtu klientů a změn budou problémy. Co vidím jako klíčový problém a kdy oddělit je změna v DB. Jak ale oddělí DB, už to skoro můžu rozsejat celé :/ Díky moc, jdu to poválet v hlavě, Standa > On 12 Sep 2020, at 09:39, Jakub Vysoky wrote: > > > Abychom ti dokazali spravne poradit, museli bychom vedet, jak velike jsou > rozdily v tech jednotlivych "instalacich" pro ruzne klienty. > > Za me je urcite "spravne" mit: > > * jednu spolecnou knihovnu v niz je vetsina funkcionality (vetsina django > apps) > * virtualenv per klient > * v kazdem virtualenvu pro kazdeho klienta jejich vlastni django projekt > (cili django settings, INSTALLED_APPS) > * nejspis i v tom vlastnim projektu jednu django appku, kterou mohu > customizovat sablony, pridavat nejakou funkcionalitu, ktera je unikatni pro > daneho klienta > > Vsechno bych instaloval pomoci pipu - i kdyz to bude z nekolika vlastnich > repositaru - to neni zas takovy problem. A urcite mel minimalne na upgrade > nejaky skript, at to volam vzdycky stejne. Ansible je urcite super, ale muze > byt pro tebe prekazka na nauceni se. > > Stejne tak mozna v tvem pripade by moje navrhovane oddeleni bylo zbytecne > silne. Ale ja bych to videla do budoucna nejspolehlivejsi. > > Drzim palce! > > >> On Sat, Sep 12, 2020 at 2:11 AM Vladimír Macek wrote: >> Ahoj, >> >> a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný jako >> multi-tenant, tzn. databáze a globální objekty (glob. objekty, cache, fajly, >> ...) by s izolací klientů počítaly. Pak bys to měl na jednu stranu >> jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu izolaci a >> udržovat rozdíly ve funkčnostech. >> >> b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet JEDEN >> projekt pro všechny, provozovat pro každého klienta extra instanci, ale z >> JEDNOHO branche. Funkční rozdíly mezi doménami by se rešily výhybkami v kódu. >> >> Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen jeden, >> jen různé settings, databáze a file storage. >> >> b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v >> INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá >> importovat. >> >> c) Silnější varianta je udržovat takovou per-instance apku jako separátně >> instalovanou jen do virtualenvu příslušného klienta. Pak by importovatelná >> nebyla, ale pro klienty bys již musel udržovat oddělené virtualenvy. >> >> Zde bych jit doporučil nástroj na automatický deployment, například Ansible. >> Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn. Deployneš novou >> verzi všem najednou, klidně s customizacemi. >> >> d) Může tě zaujmout ještě další varianta: Společnou část projektu bys >> udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys pro >> klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které by >> oproti 'prod' byly změny, které tento klient chtěl. >> >> Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul do >> všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git hooky >> -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', pokud jsi do >> něj zapomněl mergnout 'prod'. >> >> Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo dělaný. >> Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi společnou verzí a >> klienty i mezi klienty navzájem. U žádného klienta není kód navíc. >> Nespolečné commity si navždy ponesou své messages, kde svému budoucímu já >> podrobně vysvětlíš, proč existují. To se u výhybek ne vždy daří. Viděl bych >> i omezený dosah chyb v 'prod-*' brenčích. Další výhoda mě napada, že když >> při mergi do 'prod-*' dojde někde k průniku změn (nechci říkat přímo >> kolizi), přiměje tě to k úvaze, jestli dělení funkčností koncipuješ dobře. >> >> Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů, >> každého z příslušného branche gitu. >> >> V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji >> chtěl, jak jsi s ním o úpravě diskutoval. Tvým zájmem je mít rozdíly v kódu >> mezi klienty co nejmenší. >> >> Měj se, ať to jde, >> >> Vláďa >> tel. 608 978 164 >> >> >>> On 12. 09. 20 0:25, stanisl...@gmail.com wrote: >>> >>> Zdravím, >>> >>> potřeboval bych poradit či navést na best-practice v Django, jak jeden >>> projekt nasadit pro více firem, ale tak, abych v čase mohl dělat klientské >>> modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 moji klienti. >>> Django aplikace běží na nGinx a abych mohl obě aplikace aktualizovat >>> současně, na serveru jsem nalinkoval společné zdrojové kódy (virtuál >>> linkuje společné adresáře/aplikace). Vše běží, protože každá aplikace má >>> svou
Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?
Z vlastních zkušeností bych doporučil: - Mít vše v 1 repositáři - tzv. monorepo. Balíčky, knihovny, verzování, kompatibilita, je to hrozně administrativy navíc, základem monorepa jsou dobrý testy i na ty klientsky specifický funkčnosti. - Neodlišovat klientské verze větvemi, je to akorát další příležitost se v tom utopit. Udržoval bych jednotnou hlavní vývojovou linii (dev, stage, prod, nebo jak je libo/potřeba) a tam aktuální zdrojáky všeho a pro všechny. Klíčem bude vždy dobře předem zvážit, která funkcionalita je specifická a která obecná. Ale monorepo přecejen dává větší flexibilitu věci přesouvat. Společné funkce bych držel za každou cenu stejné (zejm. na úrovni modelů). I specifické funkce lze často zavádět na základě obecných mechanismů (jednotné rozhraní). Další otázkou je, jak se verze budou provozovat - 1 instance pro všechny (zde jsi již udělal rozhodnutí s různými db, ale úvaha o společné db je určitě validní), nebo na druhé straně spektra on-site u/pro konkrétního klienta. Potřeby se můžou v čase významně měnit. Ale i tady poskytuje monorepo větší flexibilitu z hlediska experimentů a změn dle potřeb. Hodně štěstí, John On Sat, 12 Sep 2020, 09:39 Jakub Vysoky, wrote: > Abychom ti dokazali spravne poradit, museli bychom vedet, jak velike jsou > rozdily v tech jednotlivych "instalacich" pro ruzne klienty. > > Za me je urcite "spravne" mit: > > * jednu spolecnou knihovnu v niz je vetsina funkcionality (vetsina django > apps) > * virtualenv per klient > * v kazdem virtualenvu pro kazdeho klienta jejich vlastni django projekt > (cili django settings, INSTALLED_APPS) > * nejspis i v tom vlastnim projektu jednu django appku, kterou mohu > customizovat sablony, pridavat nejakou funkcionalitu, ktera je unikatni pro > daneho klienta > > Vsechno bych instaloval pomoci pipu - i kdyz to bude z nekolika vlastnich > repositaru - to neni zas takovy problem. A urcite mel minimalne na upgrade > nejaky skript, at to volam vzdycky stejne. Ansible je urcite super, ale > muze byt pro tebe prekazka na nauceni se. > > Stejne tak mozna v tvem pripade by moje navrhovane oddeleni bylo zbytecne > silne. Ale ja bych to videla do budoucna nejspolehlivejsi. > > Drzim palce! > > > On Sat, Sep 12, 2020 at 2:11 AM Vladimír Macek wrote: > >> Ahoj, >> >> a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný >> jako multi-tenant, tzn. databáze a globální objekty (glob. objekty, cache, >> fajly, ...) by s izolací klientů počítaly. Pak bys to měl na jednu stranu >> jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu izolaci a >> udržovat rozdíly ve funkčnostech. >> >> b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet JEDEN >> projekt pro všechny, provozovat pro každého klienta extra instanci, ale z >> JEDNOHO branche. Funkční rozdíly mezi doménami by se rešily výhybkami v >> kódu. >> >> Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen jeden, >> jen různé settings, databáze a file storage. >> >> b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v >> INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá >> importovat. >> >> c) Silnější varianta je udržovat takovou per-instance apku jako separátně >> instalovanou jen do virtualenvu příslušného klienta. Pak by importovatelná >> nebyla, ale pro klienty bys již musel udržovat oddělené virtualenvy. >> >> Zde bych jit doporučil nástroj na automatický deployment, například >> Ansible. Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn. >> Deployneš novou verzi všem najednou, klidně s customizacemi. >> >> d) Může tě zaujmout ještě další varianta: Společnou část projektu bys >> udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys >> pro klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které by >> oproti 'prod' byly změny, které tento klient chtěl. >> >> Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul do >> všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git hooky >> -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', pokud jsi do >> něj zapomněl mergnout 'prod'. >> >> Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo dělaný. >> Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi společnou verzí a >> klienty i mezi klienty navzájem. U žádného klienta není kód navíc. >> Nespolečné commity si navždy ponesou své messages, kde svému budoucímu já >> podrobně vysvětlíš, proč existují. To se u výhybek ne vždy daří. Viděl bych >> i omezený dosah chyb v 'prod-*' brenčích. Další výhoda mě napada, že když >> při mergi do 'prod-*' dojde někde k průniku změn (nechci říkat přímo >> kolizi), přiměje tě to k úvaze, jestli dělení funkčností koncipuješ dobře. >> >> Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů, >> každého z příslušného branche gitu. >> >> V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji >> chtěl, jak jsi s ním o úpravě diskutoval. Tvým
Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?
Abychom ti dokazali spravne poradit, museli bychom vedet, jak velike jsou rozdily v tech jednotlivych "instalacich" pro ruzne klienty. Za me je urcite "spravne" mit: * jednu spolecnou knihovnu v niz je vetsina funkcionality (vetsina django apps) * virtualenv per klient * v kazdem virtualenvu pro kazdeho klienta jejich vlastni django projekt (cili django settings, INSTALLED_APPS) * nejspis i v tom vlastnim projektu jednu django appku, kterou mohu customizovat sablony, pridavat nejakou funkcionalitu, ktera je unikatni pro daneho klienta Vsechno bych instaloval pomoci pipu - i kdyz to bude z nekolika vlastnich repositaru - to neni zas takovy problem. A urcite mel minimalne na upgrade nejaky skript, at to volam vzdycky stejne. Ansible je urcite super, ale muze byt pro tebe prekazka na nauceni se. Stejne tak mozna v tvem pripade by moje navrhovane oddeleni bylo zbytecne silne. Ale ja bych to videla do budoucna nejspolehlivejsi. Drzim palce! On Sat, Sep 12, 2020 at 2:11 AM Vladimír Macek wrote: > Ahoj, > > a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný > jako multi-tenant, tzn. databáze a globální objekty (glob. objekty, cache, > fajly, ...) by s izolací klientů počítaly. Pak bys to měl na jednu stranu > jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu izolaci a > udržovat rozdíly ve funkčnostech. > > b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet JEDEN > projekt pro všechny, provozovat pro každého klienta extra instanci, ale z > JEDNOHO branche. Funkční rozdíly mezi doménami by se rešily výhybkami v > kódu. > > Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen jeden, > jen různé settings, databáze a file storage. > > b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v > INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá > importovat. > > c) Silnější varianta je udržovat takovou per-instance apku jako separátně > instalovanou jen do virtualenvu příslušného klienta. Pak by importovatelná > nebyla, ale pro klienty bys již musel udržovat oddělené virtualenvy. > > Zde bych jit doporučil nástroj na automatický deployment, například > Ansible. Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn. > Deployneš novou verzi všem najednou, klidně s customizacemi. > > d) Může tě zaujmout ještě další varianta: Společnou část projektu bys > udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys > pro klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které by > oproti 'prod' byly změny, které tento klient chtěl. > > Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul do > všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git hooky > -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', pokud jsi do > něj zapomněl mergnout 'prod'. > > Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo dělaný. > Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi společnou verzí a > klienty i mezi klienty navzájem. U žádného klienta není kód navíc. > Nespolečné commity si navždy ponesou své messages, kde svému budoucímu já > podrobně vysvětlíš, proč existují. To se u výhybek ne vždy daří. Viděl bych > i omezený dosah chyb v 'prod-*' brenčích. Další výhoda mě napada, že když > při mergi do 'prod-*' dojde někde k průniku změn (nechci říkat přímo > kolizi), přiměje tě to k úvaze, jestli dělení funkčností koncipuješ dobře. > > Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů, > každého z příslušného branche gitu. > > V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji > chtěl, jak jsi s ním o úpravě diskutoval. Tvým zájmem je mít rozdíly v kódu > mezi klienty co nejmenší. > > Měj se, ať to jde, > > Vláďa > tel. 608 978 164 > > On 12. 09. 20 0:25, stanisl...@gmail.com wrote: > > Zdravím, > > potřeboval bych poradit či navést na best-practice v Django, jak jeden > projekt nasadit pro více firem, ale tak, abych v čase mohl dělat klientské > modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 moji klienti. > Django aplikace běží na nGinx a abych mohl obě aplikace aktualizovat > současně, na serveru jsem nalinkoval společné zdrojové kódy (virtuál > linkuje společné adresáře/aplikace). Vše běží, protože každá aplikace má > svou konfiguraci a svou databázi. Pokud aplikaci vylepším, nahraju ji na 1 > místo, restartuji server či oba virtuály a oba klienti frčí na > aktualizacích. > > Nicméně: jak nejlépe postupovat, pokud např. 1. firma bude chtít nějakou > změnu v šabloně, 2. firma například upravit či přidat celou funkčnost. Rád > bych udržel zdrojový kód jednotný s nějakými "odbočkami" pro konkrétního > klienta, ale nemohu najít jak nejlépe a nejsystémověji se tomu postavit, > aby projekt byl dlouhodobě spravovatelný, zvlášť pokud by přibylo klientů. > > Věřím, že existuje nějaké systémové řešení, budu rád i za navedení či > odkaz na nějaký tutorial. Předem díky! > -- > -- > E-mailová
