Ahoj, pár nápadů:
- je fajn si rozmyslet, jestli chceš provozovat pro každého klienta samostatnou instanci (kontejner apod.), nebo to mít vše v jedné. Se samostatnými instancemi je víc režie, ale zase je např. omezený blast radius, pokud se něco u jedné z nich podělá. Samostatné instance bych asi řešil jen pokud jich bude třeba do deseti. Na druhou stranu my třeba víc instancí toho samého používáme pro škálování (sharding) a pro speciální deploymenty pro "VIP klienty", ale všechny instance mají stejný kód, jen jinou db. - chce to trochu software engineering :) Víc git větví bych nedělal, do toho se můžeš zamotat, a nebo se v tom pak už nevyzná někdo, s kým bys na tom případně spolupracoval. Spíš by tě mohly zajímat feature flagy, design patterny pro pluginy, věci trochu víc zapouzdřit, než v Djangu bývá běžné... Oddělovat věci do knihoven nebo modulů... Možná se nejdřív zamyslet, jak bys to dělal, kdyby to byl normální softwarový projekt (který začíná main funkcí a vše řeší explicitně), a pak přijít na to, jak to udělat v Djangu :) - možná by stálo zato to rozdělit do komponent. Např. backend bude stejný, frontend se může lišit u každého klienta. Btw. toto teď řeší Shoptet Premium, vyšlo o nich pár podcastů, mají zajímavý přístup (ale neříkám, že bych to dělal přesně takto). - asi by ses neměl bránit zlepšování se v devops praktikách :) Když děláš takovéhle věci, tak to chce mít infrastrukturu, o kterou se můžeš opřít. - je otázka, jak naložit s databází (v podstatě pro ni platí ty samé úvahy výše, jako pro celou aplikaci), to by chtělo vědět, co tam bude za data a jestli/jak se mohou mezi klienty strukturně lišit. Tady mám třeba zkušenosti s tím, že jsme na několika místech udělali overengineered generalizovaný systém, který by měl teoreticky zvládnout jakéhokoliv klienta (resp. jeho data) nějakým univerzálním způsobem, ale pak to stejně shořelo na něčem, s čím nikdo vůbec nepočítal :) a takový systém pak tvoří zbytečná omezení nebo dokonce hacky (což je paradoxně to, čemu měl ten systém zabránit). Takže nakonec máme spíš kód, který na první pohled vypadá duplikovaný (což triggeruje programátorské ADHD) ale zase je triviálně přehledné, co to dělá a jak se logika liší mezi jednotlivými klienty. Mimochodem mě se tady líbí nosql přístup, ve kterém se můžeš vyhnout migracím a může být jednodušší pracovat s mnoha "malými" databázemi/kolekcemi, včetně operations aspektů; ale nosql a django možná není dobrá kombinace. Jako tohle jsou přesně věci, které když se pokazí, tak rozpočet, kvalita kódu a použitelnost projektu jdou přes palubu :) Ale jestli to programuješ sám, tak snad nebudeš moc trpět sunken cost syndromem. Petr so 12. 9. 2020 v 0:25 odesílatel [email protected] < [email protected]> napsal: > 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 [email protected] > 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 [email protected]. > Chcete-li tuto diskusi zobrazit na webu, navštivte > https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com > <https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- E-mailová skupina [email protected] 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 [email protected]. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK9Q5BTNumGNk_FL9WxWgUGDpLfjZ25tO5c49T%2BJFm_tvJBOnw%40mail.gmail.com.
