Komentáře

• Michal Kleiner : Souhlasim s arronem, jedna vec je hosting, druha vec je build proces. Doporucil bych se podivat treba na https://codeship.com/, ale jsou i dalsi alternativy, pokud chces treba lokalni build a mit CI/CD server pod kontrolou, ve virtualu se da rozjet https://github.com/Strider-CD/strider. — 24.8.2015
• Občan : Lze rozvést proč je @mawebis deploy "špatný" a verze, která je lepší? Také používám deploy přes TSL+GIT a posílám pouze zdrojáky. A jsem docela rád, že klasický FTP potkám, tak jednou za rok. — 24.8.2015
• mawebis : Osobně jsem se snažil udělat workflow na deploy co nejednodušší co mě napadlo, plus dokázal bych si to bez problémů i nascriptovat. Ve firmě používám Bamboo na tyto věci, ale na soukro projekt (minimalistického rozsahu) mi to připadalo jako jít kanónem na vrabce. Plus, říkal jsem si že je rok 2015, takže hostingové firmy po tom co se naučili konečně ssl, tak bych od nich neočekával zamrznutí, ale další rozvoj pro vývojáře. Ale bohužel i dle toho, že mi tu zatím nikdo nenapsal "Jo to je jasné v Česku tohle nabízí tyhle tři firmy", tak jsem se asi zmýlil : ( — 24.8.2015
• arron : Vyjděme z toho, co tady už bylo řečeno a to, že "do repozitáře zdrojové kódy závislostí nepatří". Pak tam ale nepatří ani třeba transpilovaný JS, CSS a další věci. Patří tam jenom výchozí zdroje. A to se ještě dnesk běžně dělá i další kompilace/minimalizace/concatifiace (heh, nový slovo :-D) a co já vím, co ještě. Takže na serveru by se pak musely nejenom stahovat závislosti, ale i provádět celý "build" těhle věcí okolo. Když pominu, že je staha udělat deploy co nejrychleji (v řádu vteřin) a tenhle proces může trvat mnoho minut, tak co se stane, když se vyskytne nějaká chyba? Deploy se nezdaří a aplikace bude nedostupná než dojde k opravě? To může trvat i další destíky minut nebo třeba i hodiny...Takže si celý "build" (stažení závislostí, transpilace/kompilace/whatever, spuštění testů atd.) připravíme raději někde bokem (pomocí skriptu, nějakého build nástroje, to je fuk) a pokud všechno proběhlo v pořádku, tak můžeme udělat balíček určený na deploy. Může to být prostý zip, může to být rpm nebo cokoliv, co potřebujeme. Na serveru se pak zdrojáky jenom nahrají (ideálně někam bokem a pak se změní symlink) a je ve své podstatě hotovo (ještě se musí smazat cache, když je potřeba a další věci podle aplikace, ale tohle je takový to gro). Takže asi tak :-) Snad jsem odpověděl @Občanovi :-) — 24.8.2015
• arron : @mawebis: Víš co, pokud si seš vědom všech nedostatků, tak ten Tvůj způsob může být v pořádku, ale ten hosting tady nejspíš takhle nebude, protože to tímhle způsobem lidé prostě nedělají :-) — 24.8.2015
• v6ak : @arron: Jo, mám takové zkušenosti… Build probíhá na serveru, zatímco běží stará verze. Problém je v tom, že pro ten build je někdy málo RAM. Na druhou stranu, pokud build probíhá u vývojáře, mohou nastat různé problémy s prostředím. Například jsem si nainstalovat Javu 8, na serveru měl Javu 7 a neměl v projektu nastavenou targetVersion, takže se to zkompilovalo pro Javu 8 a na serveru se to s Javou 7 nespustilo. (To je řešitelné, ale dá se na něco zapomenout…) Navíc mhže mezi více vývojáři vzniknout trošku race condition, pokud dva chtějí deployovat současně. Pro větší projekty bude asi nejlepší mít oddělený build server. Ono všechno má svoje pro a proti, ale build na produkčním serveru bych spíše nedělal. — 24.8.2015
• Občan : Ano, do repozitáře závislosti nepatří, to je zákon. Add co se stane, když něco selže: Deploy na serveru je sekvence akcí a poslední je teprve live. Když jedna selže na localu vypíše git fail a nic závažnýho se něděje a live krok se neprovede. Dokonce se provedou případně i testy před live. (Osobně testuju jenom zda je OK konfigurace, cca 10 řádků), o hodiny nejde, naopak deploy provádím klávesovou zkratkou a jistí vše revert. Build sice probíhá nějakou tu dekádu vteřin, ovšem zda musí proběhnout na localu, nebo na serveru neovlivní rychost, kdy bude verze live. — 24.8.2015
• mawebis : Koukám, že se diskuze začíná stáčet dost k deploy workflow : ) Z praktického hlediska bych se případné havárie nebál, měl bych na serveru prostě dva adresáře - jeden v němž by se připravovala nová verze a druhá s živým webem a po úspěšném a zkontrolovaném buildu bych jen přejmenoval složky -> otázka pár mikrosekund. Žádný dlouhý výpadek by neměl nastat. Jsem založením pro minimalistické řešení. Jestli, ale @arron znáš nějaké opravdu jednoduchý deploy nástroj, jen že vyrovná jednoduchému skritpu + práci s gitem tak se rád nechám rád poučit. Ale opravdu se jedná o minimalistický projekt. Děkuji moc. — 24.8.2015