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 <jakub.vys...@gmail.com> 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 <ma...@sandbox.cz> 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á skupina django-cs@googlegroups.com >>> Správa: http://groups.google.cz/group/django-cs >>> --- >>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny >>> „django-cs“ ve Skupinách Google. >>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, >>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. >>> Chcete-li tuto diskusi zobrazit na webu, navštivte >>> https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com. >> >> -- >> -- >> E-mailová skupina django-cs@googlegroups.com >> Správa: http://groups.google.cz/group/django-cs >> --- >> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny >> „django-cs“ ve Skupinách Google. >> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, >> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. >> Chcete-li tuto diskusi zobrazit na webu, navštivte >> https://groups.google.com/d/msgid/django-cs/afec4bde-39ed-1d99-f88c-a276e5921ff8%40sandbox.cz. > > > -- > Jakub Vysoky > > mob: +420 605 852 377 > jab: jakub.vys...@gmail.com > twit: https://twitter.com/kvbik > -- > -- > E-mailová skupina django-cs@googlegroups.com > Správa: http://groups.google.cz/group/django-cs > --- > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny > „django-cs“ ve Skupinách Google. > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete > e-mail na adresu django-cs+unsubscr...@googlegroups.com. > Chcete-li tuto diskusi zobrazit na webu, navštivte > https://groups.google.com/d/msgid/django-cs/CAEO8NYwACMW6Vqcw8W3ZS6mjDcLwNSQYZZzQqQHr-cXb5H%3D4Qw%40mail.gmail.com. -- -- E-mailová skupina django-cs@googlegroups.com Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/347BE401-FF88-4DD8-9C18-414E87A463C0%40gmail.com.
