Vlákno názorů k článku
Webů s čitelným .git je na světě asi 400 tisíc
od Přezdívka: * - Jo na to jsem cetl reakce nekterych sasku,...
-
Stevko (neregistrovaný)
Ideálne by webroot mal byť v nejakom podadresári. Takže .git by bola o úroveň vyššie a nešlo by sa k nej dostať (http://example.com/../.git snáď dnes už nikde nefunguje). Takže aj nejaký config.php s heslami a tak (tie by asi ale aj tak nemuseli byť v gite, nie?)
-
Přezdívka: * (neregistrovaný)
"Ideálne by webroot mal byť v nejakom podadresári."
Presne tak ale i to reseni se jim nelibilo."tie by asi ale aj tak nemuseli byť v gite, nie?"
Taktez. Konfiguraky by mely byt v .gitignore a nahravany jednou rucne. Tedy minimalne ty ktere obsahuji pristupove udaje(k cemukoliv). -
null null (neregistrovaný)
@Stevko
To záleží na tom, co v těch konfigurácích je. Jestli je to nějaké přesné nastavení věcí, které se nemění s prostředím, tak to klidně zaverzovat můžeš, někdy i chceš/musíš. Pokud jsou to klasické proměné volby jako připojení k databázi, tak to přirozeně verzovat nechceš, protože se to mění s lokací kam to nasadíš, např. vývojový, testovací a produkční stroj, atd .. atd ...
-
Filip JirsákStříbrný podporovatelKonfiguráky s klasickými proměnnými volbami pro různá prostředí přirozeně verzovat chcete – samozřejmě pro každé prostředí zvlášť (obvykle v samostatném adresáři). Nemusí být součástí repository se zdrojovými kódy, ale verzovat konfiguráky je velmi rozumné.
-
Filip JirsákStříbrný podporovatel
Verzovat konfiguráky rovnou s aplikací je nejjednodušší. Aspoň když někdo přidá do konfiguračního souboru novou volbu, spíš to správně nastaví i pro všechna prostředí.
-
Yak (neregistrovaný)
Jiste, ovsem ne vsechny konfigurace jsou stejne pro vsechny prostredi. Typicky napr. Factories a jejich konfigurace pro automaticke vybuildovani nebo ruzne package manager configurace je dobre verzovat primo s aplikaci, ale např. nastaveni ruznych pripojeni a dyn. parametru jako napr. nejake mem limity je dobre neverzovat primo s kodem. Jen pro upresneni ...
-
null null (neregistrovaný)
@Přezdívka: *
Git deployment není zdaleka jediná cesta jak kód dostat do produkce automatizovaně. A stále platí, co se týče oné '.git' složky, že co na produkci prostě není, to se neproflákne - úplně stejně ti na serveru neběží služby které nepotřebuješ, akorát se zakázaným portem apod ...
-
Přezdívka: * (neregistrovaný)
Jiste ze to neni jedina cesta a kazdy preferuje svoje. Nicmene kouzlo GIT deploymentu je treba v hodne rychlem Rollback na predchozi verzi pokud se procpe nejaka chyba az na produkci(budme realisti, i pres vsechny testy i rucni testovani se to proste stava).
úplně stejně ti na serveru neběží služby které nepotřebuješ, akorát se zakázaným portem apod ...
Jak bylo receno vyse.
1. Pristupove udaje v CVS nemaji co delat
2. document root by mel byt pod urvni kde se nachazi slozka .git nebo by mela byt skryta.
3. Ja tu slozku pouzivam prave k tomu deploymentu, takze ne, neni to bezici sluzba se zakazanym portem, spise bych to prirovna ke sluzbe ktera pousloucha pouze na localhostu a k necemu ji pouzivam. -
null null (neregistrovaný)
@Přezdívka: *
Netvrdím že git-deployment je špatná volba, ovšem jak bych to ...., z mého pohledu už je to zastaralé. Opustil jsem to právě z důvodu jako jsem psal výše. Prostě verze zdrojáků (i bez příst. údajů) tam mít nechci, chci tam jenom kód který tam má být. Nic jiného. Nic. Jo, je to možná trochu ortodoxní, ale mě se to líbí, připadám si víc cool ;-).
1. ano, přísupové údaje tam nemají co dělat, ale v teamu více různých lidí, typicky menší firmy kde lidi přichází, odchází, jsou lepší či horší, čas plyne ... se na to musíš evidentně spoléhat. Když to na produkci nedám, tak dál můžu nechtít mít údaje v SCM, ale pokud se i stane, nehrozí mi teoreticky kompromitace. Dále pak musíš hlídat aby ta složka byla skutečně tam kde má (nedošlo neopatrností k jejímu přesunu, zkopírování - třeba při manuálním zásahu ze serveru (stává se)), zase se na něco spoléhat ... to už jsou jenom tak z hlavy dvě teoretické, ne však nereálné, možnosti problémů, lepší když tam vůbec není ...
2. ano, dokument by měl být jinde, ale když to vezmeš tak, že vyvíjíš přeba přes VPN, máš nějaké certy přístupu k SCM a pak hodíš celé SCM .git na nějaký další stroj otevřený do prostoru? To se mi taky nelíbilo, tam se mi to nechce dávat ...
3. No, poslouchá/neposlouchá, lokalhost/saloonhost je tam a teoreticky - z mého pohledu - vůbec nemusí, viz. výše, takže může teoreticky způsobit problémy. -
Přezdívka: * (neregistrovaný)
Ja je tam prave chci mit kvuli rollback. V podstate cely deployment resi za me, tedy to zda byl stahnut cely soubor a je v poradku, bezpecnost, verzovani(muzu si stahnout jakou verzi chci) popr prepnout na jakou chci. Nicmene nepopiram ze promysleny FTP deployment je spatny, ale osobni zkusenosti jsou takove, ze to bud chtelo opravdu komplikovane/neprustrelne CI, ktere resilo spoustu veci. Problem s FTP jsem zminil v dalsim komentari.
1. Toto resi code review, ktere nedovoli aby se pristupove udaje dostali do hlavniho repozitare = opet na nic nemusim myslet. Ano u presunu se to stat muze, stejne tak se muze stat ze dam na konfiguracni soubor CHMOD 777, ze bude presunut nejake public slozky apod.
2. Omlouvam se ale ten postup jsem tak nejak nepochopil :D
3. Jakoze kdyz mam DB co posloucha jen na localhostu, tak bych ji nemel pouzivat vubec, nebo jak to mam chapat? -
null null (neregistrovaný)
@Přezdívka: *
1. Code review ... hmmm ... super věc, ale ne samospásná ...
2. Často jsou pro vývoj a interní síť použité VPN, často jsou přístupy ke gitu omezené, chráněné na rozdíl od public repozitářů a tímto pak dáš .git složku na produkční stroj ...
3. Ne vždy máš DB jen na localhostu. Zvláště u větších, resp. širších, řešeních ...Ale fakt tím neříkám že git deployment je naprd, jenom jsem toto nechtěl ....
-
null null (neregistrovaný)
@ jarda mira
Nebo spíš takhle. Ten checkout by ti měl jenom posunout HEAD, nikoliv vyresetovat.
-
Ondra Satai NekolaZlatý podporovatelU statickeho webu ti to vetsinou projde.
Pokud zmeny obsahovaly trebas zasahy do schematu databaze... no za chvili zjistis, ze pres git cesta nevede.
-
Filip JirsákStříbrný podporovatel
Jistěže to projde, když se uživateli stránka rozbije (třeba protože stáhnul novější verzi HTML, které odkazuje na CSS, skript nebo obrázek, které na serveru ještě nejsou), udělá reload. Ale že by to vypadalo dobře…
-
Přezdívka: * (neregistrovaný)
Jake je teda genialni reseni, ktere obstara i rollback pro schema databaze?
Uz je potreba mit nachystany i nejaky rollback skript/deployment, ktery vola DB Migrations ... proc ho nenaskriptovat tak aby pouzival k deployi souboru GIT a DB zase jiny nastroj.BTW nemam moc rad kdyz nekdo hodit do debaty pulku vety. Jestlize mas rozumnejsi reseni sem s nim. Clovek se uci kazdy den a nemuze znat vsechno, ale tvuj komentar je prd do prazdna.
-
Filip JirsákStříbrný podporovatel
Já jsem nic o databázi nepsal. Navíc pokud se dělá bezvýpadkové nasazení nové aplikace, schéma databáze nové verze se navrhuje tak, aby bylo zpětně kompatibilní se starou verzí aplikace. Takže v případě rollbacku verze nepotřebujete hned dělat i rollback databáze.
Řešení pro statický web, které je možné použít i pro některé dynamické weby, jsem popisoval níže – přehození symlinku kořenového adresáře webu na novou verzi. Postup deploye je tedy takový, že pokud máte databázi, nejprve provedete upgrade databáze (zpětně kompatibilní, takže s ním funguje i stará verze aplikace), pak na server přenesete do nového adresáře novou verzi aplikace (která obsahuje i staré verze stylů a skriptů) a na novou verzi pak přepnete změnou symlinku
ln -sn --backup=simple $VERSION /var/web/current. Roollback na předchozí verzi provedete přejmenováním zálohy symlinkucurrent~zpět nacurrent, databáze je zpětně kompatibilní, takže tu hned při rollbacku aplikace nemusíte řešit.Jinak jsem psal o alternativě k deploy i přes Git, který samozřejmě upgrade databáze také neřeší. Řeč tedy byla především o statickém webu, případně o jednoduchém dynamickém webu, a tahat do toho databázi je odklon od původního tématu.
-
Ondra Satai NekolaZlatý podporovatel
Geniální řešení není.
Když to rozhodn rozdělíš na dvě věci, tak zvýšíš pravděpodobnost, že se ti to "rozjede"
-
Přezdívka: * (neregistrovaný)
Nejjednodussi je veskere verze aplikace tagovat u vetsich systemu a ve vetsim tymu se tomu stejne asi nevyhnes a navic si verze pojmenujes podle sebe a nemusis resit ty git hashe jednotlivych commit.
pak uz ti staci jen neco takoveho ... otazka 3 vterin
git checkout tags/1.1.4Ale tech zpusobu je samozrejme vice.
-
Filip JirsákStříbrný podporovatel
Mně teda na git deploymentu vadí to, že není atomický – v průběhu deploymentu se tam mixují různé verze, což uživatelům většinou nebude fungovat. Lepší mi připadá nahrát na server novou verzi a pak jen přehodit symlink na kořenový adresář. Roolback pak spočívá jenom v přejmenování symlinku
current~nacurrent. -
Ale ani tohle reseni neni atomicke. Klient zpravida nacita celou hromadu prvku a toto reseni nezajistuje, ze budou navzajem konzistentni. Jina receno se stane ze session klienta je vytvorena jednou verzi SW a pokracuje na jine verzi. A vzhledem ke vsudypritomnemu dynamickemu docirani, responzivnimu webu atd muze ta session trvat zatracene dlouho.
-
Filip JirsákStříbrný podporovatel
Je to atomické, pokud verzujete pomocné soubory (skripty, styly, obrázky), aby je prohlížeč mohl cacheovat a zároveň se při změně hned použila nová verze. Pak jediné, co potřebujete zařídit, je to, aby součástí deploye byly i staré verze těch pomocných souborů – když si prohlížeč stáhl starou verzi HTML, aby si i z nové verze na serveru mohl stáhnout odpovídající staré verze pomocných souborů. Session je pak něco jiného, to už je záležitostí aplikace, aby uměla pracovat s různými verzemi dat.
-
Filip JirsákStříbrný podporovatel
Lze. Součástí té nové verze webu jsou i potřebné soubory ze staré verze webu. Což se samozřejmě nejlépe zajistí v rámci buildu té nové verze.
-
Filip JirsákStříbrný podporovatel
Samozřejmě. Pokud už má webový prohlížeč staženou novou verzi, bezbolestný rollback pro něj už neexistuje.
-
Na případný rollback v podstatě není potřeba git. FTP nad vhodným COW filesystemem s vhodným nastavením bude při rollbacku řádově rychlejší (například). Nicméně, upřímně mne děsí představa, že se update produkčního systému dělá přes git. Důvod? Aby překlopení systému proběhlo atomicky, musí se služba odstavit a to na dobu, kterou tomu gitu zabere nahrání nové verze, což obvykle bývá hodně dlouhý příběh, takže dává smysl udělat nejprve upload, potom krátce odstavit server a překonfigurovat ho tak, aby používal novou verzi. Stará tam sedí, takže případný rollback bude opět expresní, což u gitu nehrozí.. Pochopitelně to takhle nejde dělat v situacích, kdy máte sesypaná uživatelská data s vlastním systémem, ovšem za to patří vývojářům ustřelovat zadnice, mimo jiné proto, že se pak taková věc opravdu bezvadně zálohuje. Ovšem pokud to máte, tak si pak můžete vybrat z řešení s git nebo to celé provozovat nad cow fs (což mimochodem řeší i jiné problémy). A navíc, s git je ten rollback celkem nespolehlivý, protože pokud v tom řádně "zaplavou" a máte v chumlu uživatelská data se systémem, tak máte celkem dlouhou zábavu. A že to git umí, mi předvedl už několikrát.
Ale upřímně řečeno, už jsem vzdala představu, že by na serveru, který se nějakým způsobem dotkne webu, mohlo být něco udělané normálně či efektivně.
-
Ok, takze kdyz si to shrnu -
- s gitem
- nestaci commit, musi se i odbourat fily, ktere by tam zustaly
- .git musi byt jinde, stejne jako prihlasovani apod.
- stejne to bude nesystemove reseni
- lepsi reseni jsou linky current
- nejlepsi je cow fsProc? cow znam jako virtualni disk co umi snapshoty. Pokud chci jet dozadu, tam se mi to zda jasne, pokud chci dopredu, tak co? Musim odstavit, uploadnout na cow, spustit ? - takze si to nekde vyvijim s gitem a mam uploadovaci skript a rollback resim pres snapshoty ?
-
Filip JirsákStříbrný podporovatel
CoW se snapshoty můžete použít tak, že webserver servíruje data ze snapshotu (ten snapshot může být klidně pro větší bezpečnost readonly). Při updatu zaktualizujete soubory (v jiném snapshotu, než ze kterého běží webserver), vytvoříte nový snapshot pro webserver a webserver následně přesměrujete na ten nový snapshot. Princip je prakticky stejný, jako s těmi symlinky, akorát u CoW máte tu výhodu, že stejné soubory (nebo jejich části) nemusíte mít na disku víckrát. Reálně by se to tedy vyplatilo jen u webů, kde budete mít velké neměnné soubory (třeba programy nebo videa ke stažení). Jinak mi ten symlink připadá na použití o dost jednodušší.
-
Přezdívka: * (neregistrovaný)
Uz jsem to jednou psal. Pokud aplikaci buildim at uz jako docker container (deploy se da provest pomoci balickovaciho systemu) neni git absolutne namiste, protoze build nema v CVS co delat(pokud to treba neni repo ciste a jen pro buildy aplikace). Takze s timto tvrzenim nemam problem. Jen dodam ze se dnes testy atd. spousteji jinde nez na produkci (gitlab, travis.ci a jine). Na produkci se vetsinou uz posle jen aplikace, nejaka DB migration, smazani cache popr. rovnou generovani cache pro novou verzi aplikace. Ja se zastavam nazoru ze se ma deployovat otestovana aplikace, resp. do produkcni vetve nema prijit nic co neprobehlo testama, code review, coding standard checkerem/fixerem apod.
