Git deploy

2.9.2013 01:05 | Přečteno: 1998× | poslední úprava: 2.9.2013 15:18

Git deploy je nástroj pro vykládání Git projektů na vzdálený server přes SSH nebo FTP/S a to jak z klientské strany tak ze strany serveru při git push, který jsem napsal speciálně pro mé použití a pro firmu kde momentálně pracuji. Primární použití je pro vykládání webových stránek na produkční server.

Script je napsán v PHP, a to z několika důvodů:

• Kompatibilita s firemními programátory (Python nebo Ruby jim připadá jako sprosté slovo a C++/QT jako sci-fi)
• Chybějící SSH v python3 (Nebo chybělo když se o tomto rozhodovalo)
• A ještě něco co jsem už zapomněl

Dále už jen strohý překlad README.md

Instalace

Skript stačí jednoduše nakopírovat do /usr/bin a nastavit práva pro spuštění.

V root repositáře který chceme vykládat vytvoříme soubor deploy.ini s následující konfigurací (Pro server side jej musíme také commitnout na server):

;target configuration
[deploy]    
;;protocols can be sftp for SSH (SCP), ftp or ftps for FTP or secure FTP
target = 'ftp://user:password@example.com:21/path/to/deploy'
;;deploy a project or not
deploy = true

;Special rights for files relative to git root
[file_rights]
dir/file = 777

Klient

V klientské části stačí v root git repositáře spustit příkaz git deploy.

Server

Pro nasazení na serveru je třeba postupovat stejně jako v případě klienta, poté stačí vytvořit link z /usr/bin/git-deploy do hook složky požadovaného repositáře (nebo do šablon hooku) jako post-receive. Tímto způsobem se při git push vždy vyloží nové změny na server. Toto je výhodné při práci více lidí na projektu.

Jak to funguje

Git deploy ukládá soubor pojmenovaný REVISION na cílové úložiště který obsahuje stávající revizi vyloženého kódu. Když se spustí vykládání přes git deploy, git deploy stáhne soubor z cílového serveru a vyloží změny od dané revize.

TODO

Možnost načíst url při úspěšném vyložení (pro vysypání cache, spuštění migrace, etc)

PS:Pokud najdete jakoukoliv chybu tak mi dejte prosím vědět, všechno bylo ušito poměrně horkou jehlou, pokud někdo touží po stejné funkcionalitě v jiném jazyce mohl bych také vyhovět, přeci jen je škoda instalovat PHP na server kde nemá žádné jiné použití.

• Update 2013-09-02 15:17:18 - přidána animace deployingu

       

Komentáře

[bono]

A proc nepouzit capistrano? ktere ma osetrene spoustu veci, ktere mohou nastat pri deploymentu aplikace.

[Salamek]

• Capistrano bezi na client side ne na serveru
• Capistrano ja napsano v ruby, ruby aplikace nejsou tak jednoduche na rozbehani jako PHP
• V pripade firmy kde pracuji je moje workstation jediny linuxovy stroj (krome serveru) takze apt-get install capistrano moc nehrozí, a vubec je to dalsi rezie, HC bylo tady vubec protlacit GiT

[bono]

Takze servery vam bezi na linuxu a workstation na Windows? Tak to bych potom nechtel resit problemy typu: nejaka featura php na windows funguje a na linuxovem serveru ne a obracene (a ze jsem na takovych chyb narazil az az, nehlede na drzeni rozdilnych konfiguraci pro linux vs windows). Proc nepouzivate vagrant? abyste meli vsechno jednotne a zbavili se zbytecnych problemu.

[Salamek]

Jak bych ti to jen rekl... kdyz jsem sem prisel tak se tu pouzivaly wXP/7 s PsPad a Totalcommander a vse se nahravalo pres FTP, svn se tu pouzivalo jako jakesi zalohovaci uloziste (proste jendou za cas nekdo vzal bordel z FTP a nahral jej do SVN) Horor.

Me s kolegou se tu povedlo rozsirit netbeans s php modulem a Nette jako framework. (zbyvaji dva programatori kteri stale trci na TC a Pspadu)

Dale se mi povedlo zrusit a zmigrovat SVN na GIT (Gitlab presneji) plus tento deploying jako sprava verzi a pomalu nim nahrazuji FTP.

Dale tu vytvarim tlaky na technicke aby zmigrovali servery na novy debian, nekde se pouziva jeste debian 5.0 jinde 6.0, jeden 6.0 jsem sam zmigroval na 7.1

A moje workstation je taky hromada me prace, je slozen z dilu k vyhozeni ktere byly lepsi nez moje puvodni stanice z WXP, Archlinux jsem si sem nainstaloval bez povoleni protoze pod Windows se proste neda rozume pracovat

A o codestyle radsi uz ani mluvit nebudu... nebo nad security bugy ktere jsem obevil a "mava" se nad nema rukou...

[bono]

Tak aspon ten git se povedl. Mimochodem kdyz uz pozivate git tak jake workflow pouzivate? Jestli klasicke jako v svn tak to nemelo moc smysl prechazet na git - doporucoval bych github workflow kdy merge do masteru musi schvalit ostatni vyvojari (tohle se mi osvedcilo na odbourani spatnych zvyklosti v kodu ostatnich vyvojaru - je to vlastne code review).

To ze nekdo pouziva Pspad a TC neznamena ze nemuze produkovat dobry kod, ale pouzivat na deployment rucni upload FTP bych zakazal (resp. nejlepsi varianta je zrusit FTP na serveru - stejne to neni bezpecne).

Kdyz vam administratori nedokazou aktualizovat stary system tak na co tam potom jsou? To uz je rychlejsi prevzit spravu operacniho systemu a idealne nasadit chef nebo pupet.

A k tomu hardware - pokud firma nema na to aby koupila slusny pc jako workstation (dnes uz to nejsou zadne velke vydaje) tak potom nechci videt v jakem stavu jsou servery, ktere firmu zivi nebo ne?

[Salamek]

To ze nekdo pouziva Pspad a TC neznamena ze nemuze produkovat dobry kod

No zatim ma zkusenost s lidmi pouzivajici tyto tools... neni zrovna nejlepsi...

@workflow, vsechno postupne, da mi dost prace zde zabit FTP... Rad bych se ale prvne zbavil win stanic, delat tam cokoliv poradneho je hrozna otrava a na vyvoj jsou krajne nevyhovujici. Prejit na GiT melo cenu, kvuli deployingu a hlavne kvuli Gitlabu ktery nam dava krasnou privatni verzi githubu.

@administratori, jako duvod uvadeji ze nechteji rozbit aplikace zakaznikum a nemohou si pry dovolit downtime. I kdyz znam reseni jak toto vyresit s minimalnim downtime a zakaznikum se da 2mesice do predu poslat email aby otestovali sve aplikace na nove verzi php, nemuzu je do toho nutit. Mam slibeny novy server ktery bych mohl mit pod spravou a na ktery by sly nove aplikace, takze me toto trochu uklidnilo.

@HW, k tomu se nechci ani vyjadrovat... Workstation tomu rikam jen proto ze se u "toho" "pracuje", jinak to s workstation nema nic spolecneho: Normal PC s jednim HDD, Malo RAM, Dualcore CPU, bez UPS(A ze tu elektrina obcas vyleti) a to nejlepsi na konec, LCD 17' 1280x1024 s mizernyma barvama (Coz je hodne "super" protoze delam i designy k webu, responzivni)

Mam posledni dobou celkem dilema jestli ma cenu to tu "rekultivovat" nebo dat vypoved, protoze i plat je naprd

[bazil]

A proč nepoužít už hotová řešení? Např: https://github.com/ezyang/git-ftp nebo spousta jiných.

[Salamek]

Vetšina hotových řešení nestačila mým potřebám https://github.com/ezyang/git-ftp zda se neumi bezet na server side a podporuje jen FTP, git deploy bezi i na server side a podporuje FTP i SSH vykladani

[Josef Kufner]

Hm, obvykle mám Git i na cílovém serveru a v podstatě dělám jen:

ssh server.example.tld \
  cd /target/dir \
  \&\& git pull --rebase \
  \&\& git submodule update --install

Git pull se chytne checkoutnuté větve a udělá, co je potřeba, --rebase je kvůli případným modifikacím na serveru, které by tam neměly být. Samozřejmě to nevolám takle přímo, mám to ve skriptu (uloženém na serveru) spolu s pár dalšíma věcma nutnýma pro update, ty jsou však specifické pro každý projekt a instalaci.

[Salamek]

Toto je urcene pro servery s omezenym pristupem a rozdilnym prostredim... vem si ze mas 6 serveru, na jeden mas pristup pres SCP na dalsi 3 pres FTP a na jeden mas ssh ale je moc stary vuci novemu git serveru, a posledi je ok

Zbyva jednine reseni, vykladat pres FTP/SSH timto zpusobem

Prosta vykladka na rozdile servery o rozdilne konfiguraci nebo jen na blbe webhostingy je diky git-deploy mozne.

[Josef Kufner]

Do takové situace se nedostávám. Buď mám k dispozici SSH, nebo je to rozbité.

[Salamek]

To mas stesti, je musim pracovat s ruznym pochybnym bordelem...

[bono]

Toto je dobre do te doby nez potrebujete udelat rollback a git repository je nedostupna nebo to musi provest nekdo kdo neovlada git.

[Josef Kufner]

Pokud někdo neovládá Git, tak na serveru nemá co dělat. Akorát by to rozbil ještě víc. A dělat upgrade v době, kdy není poruce někdo, kdo by to mohl ihned opravit, není rozumné. Upgrade produkčních serverů spouštím zásadně ručně a celý upgrade je vždy plně automatický. Stačí zkontrolovat výsledek a chvíli počkat, zda to nechcípne. Testovací server se upgraduje ihned a automaticky po pushi do master větve v centrálním repositáři, takže automatický upgrade se tím i otestuje.

Rollback se dělá blbě, protože databáze není verzovaná a i kdyby byla, nelze zahodit mezi tím vytvořená data. Verzované jsou jen skripty pro upgrade, ale už neexistují inverzní skripty pro downgrade.

Pokud se databáze neměnila, což v pozdějším stádiu vývoje je vcelku běžné, tak stačí udělat checkout libovolné starší verze. Která to byla je napsáno v reflogu. Centrální repository není potřeba, neboť celá historie je součástí instalace.