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
<mailto: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
<https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
--
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/afec4bde-39ed-1d99-f88c-a276e5921ff8%40sandbox.cz.
