Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-10-17 Thread Petr Messner 
Ahoj,

git zvládá větve a merge v pohodě, stejně nebo lépe než ostatní verzovací 
systémy. Asi děláš něco špatně :) Nebo ten kód při každé změně natolik 
překopeš, že to prostě mergnout nejde?

Nauč se s gitem pracovat v příkazové řádce. Podle mých zkušeností lidi, kteří 
používají GUI, se to prostě pořádně nenaučí a dělají chyby.

Pro snadný přenos jednotlivých změn mezi větvemi slouží git cherry-pick (pokud 
samozřejmě není vhodné dělat merge).

Petr Messner

> 17. 10. 2020 v 18:24, stanisl...@gmail.com :
> 
> Ahoj, moc díky. 
> 
> GIT jsem si prošel jako videa na YT a používám, je to velice jednoduchý 
> nástroj. Mám nějaká GUI klikátka, díky čemuž se v něm lze hezky vyznat a 
> rychle se vracet v čase. V podstatě s GIT (protože dělám sám) mám jediný 
> problém: větve. Ale to je utrpení! Jakmile potřebuji rozdělat práci ve dvou 
> větvích, tedy budu logicky jednoho dne spojovat, je to cesta do pekla. 
> Kdykoliv mi GIT udělá merge, je to něco jako hodit nový kód do mixéru a něco 
> vypadne. Někdy ignoruje kód z jedné větve, někdy z druhé, migrace už ani 
> neřeším (dneska si už ani netroufnu mít změny 1 modulu ve dvou větvích). 
> Testováním a skládáním modelů z obou větví někdy strávím hodně času a je 
> třeba projekt komplet přetestovat, udělat nový commit a pak zase chvíli se 
> zdviženým čelem pokračovat. Už jsem i raději kód napsal znovu a díky stroji 
> času v PyCharm kopíroval části kódu do nového commitu. Občas jsem potřeboval 
> určitý stav větve přenést do jiné a, pak rebase, výsledkem byla už úplně jiná 
> aplikace, ale nezjistil jsem, co má dělat :)
> 
> Zkusil jsem každého klienta vést jako vlastní větev, vypadalo to krásně, než 
> jsem potřeboval vzájemně prohazovat funkčnosti. Myslím, že i cestování časem 
> má lidstvo lépe zdokumentované, než co já dostal za výsledek :). Ale to jsou 
> ty větve, nesmí se holt mixovat. Aktuálně tedy jedu projekty odděleně a pokud 
> si vzpomenu, že něco mám hotové u jiného klienta, copy je sice trapné, 
> ale mám to pod kontrolou a funkční. Celková časová náročnost je vyšší, ale 
> čas se vrací, že nemusím "uklízet" a testovat po GITu a jeho merge. 
> Základní/společné moduly pak jedou společně, tam není co zkazit, snad jen, 
> občas bych si nějaký kód potřeboval "odložit", neboť zastaral a už ho asi 
> nepoužiji, ale chci mít možnost o něm vědět a případně ho rychle nalézt, na 
> to jsem v GITu nenašel jiné řešení než vlastní větev s "odpadem",  takže to 
> držím jako odkomentovaný kód.
> 
> Každopádně díky za názory, bylo to velice poučné. Trochu mě mrzí, že Django 
> toto neřeší nějak systematičtěji. Snad časem GIT bude mít funkce tímto směrem 
> a o to systematičtěji se o to půjde postarat. Standa
> 
> 
>> On Sunday, 13 September 2020 at 15:19:16 UTC+2 Vláďa Macek wrote:
>> Ahoj Stando, rozumím. Pamatuju si sám sebe v minulosti. :-) 
>> 
>> Nebuď ostražitý ke gitu. It's like UNIX - user friendly, just selective 
>> about who its friends are. :-) 
>> 
>> Programátor se gitu nevyhne. Čím dřív se ho pořádně naučíš, tím líp. Ano, 
>> řádkový klient je z hlediska UX blbě navržený, místy neintuitivní. Ale celý 
>> je to stabilní a pomáhá to. Jen věnuj víc energie a času jeho používání. 
>> Bohatě se ti učení vrátí. 
>> 
>> Tím neprosazuju svojí variantu d) níž. Byla by funkční, ale je neobvyklá a 
>> jen pro někoho. Uvedl jsem ji jako možnost.
>> 
>> Hlavní pro tebe je udržovat minimum rozdílů mezi verzemi, protože "bolesti" 
>> tvojí hlavy, kterou ti jejich TRVALÁ údržba způsobí, ti žádný klient nebude 
>> chtít zaplatit. 
>> 
>> Nad každou výhybkou dobře přemýšlej, než jí zavedeš. Budeš s ní žít ty, ne 
>> klient. Velmi pomáhá mít zavedenou diskusi s klienty a tak, abyste spolu 
>> jednali jako partneři. Dokázat umravnit nebo i odmítnout klienta, který 
>> odmítá pochopit, že něco mít nebude nebo to bude mít draho, i když jemu to 
>> připadá easy a je to přece technicky zvládnutelné. 
>> 
>> V. 
>> 
>> On 12. 09. 20 12:20, Stanislav Vasko wrote: 
>> > Díky za podrobnou odpověď. Spoléhat na GIT se bojím, už jsem si s ním 
>> > užil. Asi nejlépe mi zatím vychází ty výhybky (zatím). Dám si do settings 
>> > jméno klienta a podle toho si udělám změny. Líbí se mi, že to budu mít 
>> > pohromadě, ale dlouhodobě a při více klientech/změnách to bude asi dost 
>> > hokej. 
>> > 
>> > Moduly ad klient budou cesta, jakmile do toho někdo slápne více, zbytek 
>> > poběží na "base". Dokumentace je základ, to je základ, píšu si i hromadu 
>> > poznámek do kódu, jinak bych se zbláznil. 
>> > 
>> > Díky, Standa 
>> > 
>> >> On 12 Sep 2020, at 02:11, 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. 
>>

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-10-17 Thread stanisl...@gmail.com 
To podmínkování jsme používali i poslední firmě, jen toho pak časem bylo 
nějak moc. Pokud budu muset do základního/společného modulu, asi to bude 
právě takto "trapně", stylem IF ()..., ale zatím jsem se tomu ubránil. 
Nicméně už nyní má každý klient v settings.py USER_ID = "jmeno_klienta", 
takže to asi jednoho dne nastane. 

Spoléhat se na něco, že to vždy vybere správnou DB nechci, takže v settings 
(ad klient) je konfigurace databáze pro daného klienta. Navíc jsem zůstal u 
SQLite (jedná se zatím o tisíce řádek denně), neboť miluji, když celý 
projekt je v souborech.

Měj se, Standa

On Tuesday, 6 October 2020 at 11:50:34 UTC+2 MirekZv wrote:

> Zaujalo mě, že se tady vůbec neprobírá možnost použít Sites framework (ze 
> základní instalace, contrib.sites).
> Pak bys udržoval jeden kód, který by pouze v settings.py dělal: from 
> konfigurace_tehle_firmy import SITE_ID, a kód by sis větvil: if 
> SITE_ID=n:...
> Resp. pokud v konfiguráku SITE_ID nemáš, tj. máš společný konfigurák pro 
> více zákazníků, tak Sites framework určí SITE_ID podle domény (url).
> Neboli, dávalo by Ti to možnost pro větší zákazníky mít extra instalaci a 
> extra databázi.
>
> Jinak s multitenant jsem si něco zkoušel, konkrétně s 
> django-tenant-schemas, které mají každou kopii databáze jako jedno Postgres 
> schéma a podle domény (např. podle domény 3.řádu: zakaznik.sluzba.cz) 
> vyberou schéma, se kterým pracují.
> Funguje to, zdá se dobře.
> Seznam zákazníků si uděláš do své aplikace např. customer, do tabulky 
> např. customers.Customer. Je otázka, jestli by to šlo směřovat přímo na 
> djangové Sites, to asi ne (asi nebudou sedět pole, která má Sites a pole, 
> která chce django-tenant-schemas), ale neměl by být problém nějak druhotně 
> určit to SITE_ID, abys mohl větvit kód podle zákazníka, pokud má mít něco 
> extra.
>
> No a nebo to zkombinovat nějak jakkoli jinak: třeba nastavené SITE_ID by 
> znamenalo produkční instalaci, přičemž ta by buď jela přímo (velký 
> zákazník, vše pro něj extra), nebo s django-tenant-schemas + tabulkou 
> Customers (malý zákazník, sdílí Postgres cluster).
> Kombinace SITE_ID a customers.id by pak dávala unikátní klíč, který 
> určuje zákazníka. Ten třeba pomocí nějaké tabulky centrální evidence 
> zákazníků změnit na string, a větvit úplně obyčejně: if 
> request.zakaznik='TESCO':...
>
> Napsal jsem schválně request.zakaznik, protože takovou věc je asi vhodné 
> přiřadit v middlewaru (=vždy).
>
>
> Dne čtvrtek 17. září 2020 v 13:58:49 UTC+2 uživatel Messa napsal:
>
>> 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

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-10-17 Thread stanisl...@gmail.com 
Ahoj, moc díky. 

GIT jsem si prošel jako videa na YT a používám, je to velice jednoduchý 
nástroj. Mám nějaká GUI klikátka, díky čemuž se v něm lze hezky vyznat a 
rychle se vracet v čase. V podstatě s GIT (protože dělám sám) mám jediný 
problém: větve. Ale to je utrpení! Jakmile potřebuji rozdělat práci ve dvou 
větvích, tedy budu logicky jednoho dne spojovat, je to cesta do pekla. 
Kdykoliv mi GIT udělá merge, je to něco jako hodit nový kód do mixéru a 
něco vypadne. Někdy ignoruje kód z jedné větve, někdy z druhé, migrace už 
ani neřeším (dneska si už ani netroufnu mít změny 1 modulu ve dvou 
větvích). Testováním a skládáním modelů z obou větví někdy strávím hodně 
času a je třeba projekt komplet přetestovat, udělat nový commit a pak zase 
chvíli se zdviženým čelem pokračovat. Už jsem i raději kód napsal znovu a 
díky stroji času v PyCharm kopíroval části kódu do nového commitu. Občas 
jsem potřeboval určitý stav větve přenést do jiné a, pak rebase, výsledkem 
byla už úplně jiná aplikace, ale nezjistil jsem, co má dělat :)

Zkusil jsem každého klienta vést jako vlastní větev, vypadalo to krásně, 
než jsem potřeboval vzájemně prohazovat funkčnosti. Myslím, že i cestování 
časem má lidstvo lépe zdokumentované, než co já dostal za výsledek :). Ale 
to jsou ty větve, nesmí se holt mixovat. Aktuálně tedy jedu projekty 
odděleně a pokud si vzpomenu, že něco mám hotové u jiného klienta, 
copy je sice trapné, ale mám to pod kontrolou a funkční. Celková 
časová náročnost je vyšší, ale čas se vrací, že nemusím "uklízet" a 
testovat po GITu a jeho merge. Základní/společné moduly pak jedou společně, 
tam není co zkazit, snad jen, občas bych si nějaký kód potřeboval 
"odložit", neboť zastaral a už ho asi nepoužiji, ale chci mít možnost o něm 
vědět a případně ho rychle nalézt, na to jsem v GITu nenašel jiné řešení 
než vlastní větev s "odpadem",  takže to držím jako odkomentovaný kód.

Každopádně díky za názory, bylo to velice poučné. Trochu mě mrzí, že Django 
toto neřeší nějak systematičtěji. Snad časem GIT bude mít funkce tímto 
směrem a o to systematičtěji se o to půjde postarat. Standa


On Sunday, 13 September 2020 at 15:19:16 UTC+2 Vláďa Macek wrote:

> Ahoj Stando, rozumím. Pamatuju si sám sebe v minulosti. :-) 
>
> Nebuď ostražitý ke gitu. It's like UNIX - user friendly, just selective 
> about who its friends are. :-) 
>
> Programátor se gitu nevyhne. Čím dřív se ho pořádně naučíš, tím líp. Ano, 
> řádkový klient je z hlediska UX blbě navržený, místy neintuitivní. Ale 
> celý 
> je to stabilní a pomáhá to. Jen věnuj víc energie a času jeho používání. 
> Bohatě se ti učení vrátí. 
>
> Tím neprosazuju svojí variantu d) níž. Byla by funkční, ale je neobvyklá a 
> jen pro někoho. Uvedl jsem ji jako možnost. 
>
> Hlavní pro tebe je udržovat minimum rozdílů mezi verzemi, protože 
> "bolesti" 
> tvojí hlavy, kterou ti jejich TRVALÁ údržba způsobí, ti žádný klient 
> nebude 
> chtít zaplatit. 
>
> Nad každou výhybkou dobře přemýšlej, než jí zavedeš. Budeš s ní žít ty, ne 
> klient. Velmi pomáhá mít zavedenou diskusi s klienty a tak, abyste spolu 
> jednali jako partneři. Dokázat umravnit nebo i odmítnout klienta, který 
> odmítá pochopit, že něco mít nebude nebo to bude mít draho, i když jemu to 
> připadá easy a je to přece technicky zvládnutelné. 
>
> V. 
>
> On 12. 09. 20 12:20, Stanislav Vasko wrote: 
> > Díky za podrobnou odpověď. Spoléhat na GIT se bojím, už jsem si s ním 
> > užil. Asi nejlépe mi zatím vychází ty výhybky (zatím). Dám si do 
> settings 
> > jméno klienta a podle toho si udělám změny. Líbí se mi, že to budu mít 
> > pohromadě, ale dlouhodobě a při více klientech/změnách to bude asi dost 
> > hokej. 
> > 
> > Moduly ad klient budou cesta, jakmile do toho někdo slápne více, zbytek 
> > poběží na "base". Dokumentace je základ, to je základ, píšu si i hromadu 
> > poznámek do kódu, jinak bych se zbláznil. 
> > 
> > Díky, Standa 
> > 
> >> On 12 Sep 2020, at 02:11, 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

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-10-06 Thread MirekZv 
Zaujalo mě, že se tady vůbec neprobírá možnost použít Sites framework (ze 
základní instalace, contrib.sites).
Pak bys udržoval jeden kód, který by pouze v settings.py dělal: from 
konfigurace_tehle_firmy import SITE_ID, a kód by sis větvil: if 
SITE_ID=n:...
Resp. pokud v konfiguráku SITE_ID nemáš, tj. máš společný konfigurák pro 
více zákazníků, tak Sites framework určí SITE_ID podle domény (url).
Neboli, dávalo by Ti to možnost pro větší zákazníky mít extra instalaci a 
extra databázi.

Jinak s multitenant jsem si něco zkoušel, konkrétně s 
django-tenant-schemas, které mají každou kopii databáze jako jedno Postgres 
schéma a podle domény (např. podle domény 3.řádu: zakaznik.sluzba.cz) 
vyberou schéma, se kterým pracují.
Funguje to, zdá se dobře.
Seznam zákazníků si uděláš do své aplikace např. customer, do tabulky např. 
customers.Customer. Je otázka, jestli by to šlo směřovat přímo na djangové 
Sites, to asi ne (asi nebudou sedět pole, která má Sites a pole, která chce 
django-tenant-schemas), ale neměl by být problém nějak druhotně určit to 
SITE_ID, abys mohl větvit kód podle zákazníka, pokud má mít něco extra.

No a nebo to zkombinovat nějak jakkoli jinak: třeba nastavené SITE_ID by 
znamenalo produkční instalaci, přičemž ta by buď jela přímo (velký 
zákazník, vše pro něj extra), nebo s django-tenant-schemas + tabulkou 
Customers (malý zákazník, sdílí Postgres cluster).
Kombinace SITE_ID a customers.id by pak dávala unikátní klíč, který určuje 
zákazníka. Ten třeba pomocí nějaké tabulky centrální evidence zákazníků 
změnit na string, a větvit úplně obyčejně: if request.zakaznik='TESCO':...

Napsal jsem schválně request.zakaznik, protože takovou věc je asi vhodné 
přiřadit v middlewaru (=vždy).


Dne čtvrtek 17. září 2020 v 13:58:49 UTC+2 uživatel Messa napsal:

> 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 stanisl...@gmail.com <
> stanisl...@gmail.com> 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ě

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-09-17 Thread Petr Messner 
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 stanisl...@gmail.com <
stanislav.va...@gmail.com> 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 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 zobrazit tuto diskusi na webu, navštivte

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-09-13 Thread Vladimír Macek 

Ahoj Stando, rozumím. Pamatuju si sám sebe v minulosti. :-)

Nebuď ostražitý ke gitu. It's like UNIX - user friendly, just selective 
about who its friends are. :-)


Programátor se gitu nevyhne. Čím dřív se ho pořádně naučíš, tím líp. Ano, 
řádkový klient je z hlediska UX blbě navržený, místy neintuitivní. Ale celý 
je to stabilní a pomáhá to. Jen věnuj víc energie a času jeho používání. 
Bohatě se ti učení vrátí.


Tím neprosazuju svojí variantu d) níž. Byla by funkční, ale je neobvyklá a 
jen pro někoho. Uvedl jsem ji jako možnost.


Hlavní pro tebe je udržovat minimum rozdílů mezi verzemi, protože "bolesti" 
tvojí hlavy, kterou ti jejich TRVALÁ údržba způsobí, ti žádný klient nebude 
chtít zaplatit.


Nad každou výhybkou dobře přemýšlej, než jí zavedeš. Budeš s ní žít ty, ne 
klient. Velmi pomáhá mít zavedenou diskusi s klienty a tak, abyste spolu 
jednali jako partneři. Dokázat umravnit nebo i odmítnout klienta, který 
odmítá pochopit, že něco mít nebude nebo to bude mít draho, i když jemu to 
připadá easy a je to přece technicky zvládnutelné.


V.

On 12. 09. 20 12:20, Stanislav Vasko wrote:
Díky za podrobnou odpověď. Spoléhat na GIT se bojím, už jsem si s ním 
užil. Asi nejlépe mi zatím vychází ty výhybky (zatím). Dám si do settings 
jméno klienta a podle toho si udělám změny. Líbí se mi, že to budu mít 
pohromadě, ale dlouhodobě a při více klientech/změnách to bude asi dost 
hokej.


Moduly ad klient budou cesta, jakmile do toho někdo slápne více, zbytek 
poběží na "base". Dokumentace je základ, to je základ, píšu si i hromadu 
poznámek do kódu, jinak bych se zbláznil.


Díky, Standa


On 12 Sep 2020, at 02:11, 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,

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-09-12 Thread Stanislav Vasko 
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?

2020-09-12 Thread Jan Walter 
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?

2020-09-12 Thread Jakub Vysoky 
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á

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-09-11 Thread Vladimír Macek 

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 zobrazit tuto diskusi na webu, navštivte

[django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

2020-09-11 Thread stanisl...@gmail.com 
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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com.