Jak na verzování webu

Sunny:
„vyvíjím web online přímo na ftp na pronajatém serveru.“
Tak jsme začínali asi všichni ale ač se to nemusí zdát, je to to nejméně pohodlné řešení.

„na pronajatém serveru“
Opravdu máte pronajatý server a ne jen hosting?

Sunny:
„V čem je to pohodlnější?“
Primárně vidíš změny hned, nemusíš to nahrávat na server. Potom samozřejmě lepší debugovací nástroje, neomezená konfigurace serveru. Git bych ti doporučil. Můžete každý vyvíjet lokálně u sebe a mergovat změny. Jestli ten hosting podporuje i git, tak potom jen stačí mít dvě branche (jednu pro vývoj, jednu pro ostrý provoz) a až budete chtít publikovat, tak je jen mergnete a pushnete na server. (Pro inspiraci, na podobném principu fungují stránky na github.io.)

Sunny:
„V čem je to pohodlnější?“
Tak pokud chceš (a měl bys) používat Git, tak je to nutnost. Každý vývojář má svojí lokální kopií a když se v tom hrabě, tak mu nikdo nešahá pod ruce. Teprve až má vše hotové, tak své změny nahraje na internet, kde se sloučí se změnami ostatních.

„nicméně jedná se o naprosto neomezený prostor co se týče domén, emailů, atp.“
Přesto jsi omezen verzí nainstalovaných programů a vůbec množinou dostupných programů. Chceš optimalizovat svoji aplikací a v části místo MySQL použít Redis? Tak to máš bohužel smůlu. Je vidět, že jsi ještě nezažil volnost kterou máš, pokud máš k dispozici celý server. Tam si můžeš nainstalovat programy jaké chceš, ve verzi kterou potrebuješ a nakonfigurovat je dle svých potřeb. Je s tím samozřejmě víc práce ale vyplatí se to.

Nicméně dá se žít i na hostingu.

Teď popíšu můj postup s nahráváním na hosting.
Na svém počítači mám Linux a na něm rozchozený webserver. Snažím se mít nainstalované stejné programy ve stejné verzi a se stejnou konfigurací jako na ostrém serveru abych předešel problémům s tím, že mě to funguje ale na serveru to fungovat nebude. Projekt verzuji gitem. Když jsem s tím spokojený, tak to gitem odešlu na Github, kde je jeho kopie dostupná pro všechny ostatní vývojáře. Jakmile tam kód nahrají, Github informuje server, že jsem nahrál novou verzi kódu. Server se tedy připojí na Github, stáhne si nové zdrojové kódy, aplikací sestaví a bez výpadku s ní nahradí tu starou.

Moje celá práce tedy končí tím, že odešli Git commity na Github a od té chvíle je vše automatizované. Tím se minimalizuje riziko, že při tom na něco zapomenu nebo rozbiju.

Jak se nahrazuje aplikace novou verzí bez výpadku (na hostingu to nejde)? Jednotlivé verze aplikace mám v adresářích podle identifikátorů Git commity z kterého jsou sestaveny. Toto webu ukazuje na zástupce, který ukazuje do jedné z těch složek. Stačí mi tedy změnit kam ten zástupce ukazuje a v tom okamžiku už běží na webu jiná verze. Je to přepnutí z jedné funkční na jinou funkční. To že se ta nová nějakou chvíli stahovala a pak sestavovala ničemu nevadí, protože k přepnutí dochází až na konci, kdy je vše hotovo a připraveno.

Co mi tam chybí? Před tím, než Github informuje server o nové verzi by se měly ještě spouštět automatické testy a nová verze by se měla nasadit jen a pouze v případě, že všechny testy projdou.

No a co hosting?
I na něm jde využít tento postup i když se bude muset upravit. Pokud nemáte na hostingu Git o kterém psal Radek9, dá se sehnat PHP knihovna, která umí stáhnout zdrojové kódy z Githubu které si pak pomocí PHP funkcí překopíruješ na správné místo. Jsi však omezen maximální dobou běhu PHP scriptu což u větších projektů může začít vadit.

[#6] Sunny
Nepouštěl bych se do toho najednou. Vyladit plnou automatizaci není úplně jednoduché. Já jsem třeba měl největší problém s nalezením optimální metody, jak propagovat změny v databázi.
Ale vývoj na localhostu a správa gitem je určitě dobrý základ.

Alphard:
Ano, s databáze přináší problémy. Naštěstí se nemusí měnit tak často jako kód. Takže migrace databází zatím řeším ručně. Mohl bys tu svou metodu popsat? Dost by mě to zajímalo.
Zrovna nedávno jsem četl pěkný článek o migracích obrovských databází. Tak velký projekt ještě nemám ale rozhodně to stálo za přečtení.

Jinak ta plná automatizace opravdu není nezbytná, k tomu se můžeš třeba časem postupně dopracovat ale s vývojem na lokálu a s gitem bych začal co nejdřív.

Keeehi:
„Zrovna nedávno jsem četl pěkný článek o migracích obrovských databází“
Ten blog sleduji také, ale to je něco jiného. Nyní jsem měl na myslí drobné změny struktury při vývoji.

Své řešení popsat mohu, ale stále jsou tam věci, které nejsou ideálně dořešené.
Aktuální postup, který používám, je založený na tom, že ke každé úpravě databáze musí existovat SQL dotaz a ten musí být uložený v souboru, který se verzuje gitem. Starostí vývojáře je tedy mít před každým commitem v pořádku tento SQL log.

Při deploymentu na server se spustí script, který tento soubor naparsuje, nalezené SQL dotazy porovná s lokální historií a dosud neprovedené dotazy spustí.
Lokální historii zdůrazňuji z toho důvodu, že na serveru máme kromě produkční verze ještě beta verzi, takže se každá změna musí provést 2x. Po push na server se ihned updatuje beta, tj. člověk, který změnu provedl, hned vidí, jestli je vše v pořádku (a pokud ne, není to katastrofa). Když je vše v pořádku, očekává se, že bude vše bude fungovat i později při updatování production verze.

Zkušenosti jsou takové, že na přidání tabulky/sloupce, pro insert/update to funguje perfektně.

Co je největší problém je počítání s variantou, že někdy nastane situace, kdy bude třeba zpětně nasadit starší verzi. A při tomhle automatika už selze, takže je třeba podívat se do logu, které dotazy byly provedeny a rozhodnout se, jak situaci řešit. Naštěstí to není časté. Preventivně se snažíme nenechávat automaticky provádět destruktivní dotazy, takže např. dotazy na smazání tabulek si ukládáme zvlášť a spouštíme ručně až máme jistou, že se nebudeme chtít vrátit.

Co jsem tak různě viděl a četl, tak tento systém je docela běžný, jen to každý implementuje trochu jinak. Myslím že třeba na Poslední sobotě někdo ukazoval UI nadstavbu. Některé jiné týmy si zase preventivně píší i dotazy pro krok zpět, aby se mohli rychle vrátit. Do toho se nám ale zatím nechce.


Občas přemýšlím o nějakém nástroji, který by vzal historii z Admineru, vyfiltroval modifikační dotazy a nechal vývojáře vybrat si ty, které chce commitovat. Ale ještě jsem ani nezačal.

Přihodím svou zkušenost s migracemi: u projektů které máme postavené na Symfony 2 (kde má Doctrine už tak velmi dobře vyřešené synchronizování modelu s databázovou strukturou) využíváme Doctrine Migrations Bundle. Po jakékoliv změně modelu se spustí jediný příkaz, který vygeneruje PHP soubor s migračními SQL, a to jak "nahoru", tak i "dolů" - tedy lze i z "nové" verze (třeba při nějakém problému) snadno zmigrovat i o libovolný počet migrací zpět.

Není to teda neprůstřelné a jsou věci s kterýma si to moc dobře neporadí (ty automaticky generované SQL dotazy je vždy potřeba zkontrolovat a případně upravit), ale pořád to extrémně usnadňuje práci. Zmigrovat na libovolnou verzi se dá jediným příkazem, který lze spouštět automaticky při deployi. Ukázka migrace.