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&paste 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 <[email protected]> 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, [email protected] 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 [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] > >>> <mailto:[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/94928c7b-29e6-4a51-b881-9f42c572fcb1n%40googlegroups.com.
