Přejít k navigační liště

Zdroják » Různé » Spravujte verze WordPressu pomocí Gitu

Spravujte verze WordPressu pomocí Gitu

Články Různé

Git dokáže mnohem více, než jen verzování kódu aplikací. Je také praktickým nástrojem pro sledování změn software, který používáte. Naučte se, jak snadno spravovat verze WordPressu díky vendor branch a spravovat větší množství webů.

Použití Gitu pro paralelní správu oddělených větví kódu popsal před více než dvěma lety Karel Minařík v druhém dílu seriálu Pět důvodů, proč zvolit Git. Přes nepřeberné možnosti využití v rámci vývoje aplikací jsou větve také praktickým nástrojem pro správu různých verzí. A to nejen na straně koncového produktu – tj. vaší aplikace, ale i pro sledování změn u software třetích stran a jejich snadnou integraci.

Typickým příkladem, ve kterém potřebujete sledovat změny v cizím kódu, je například správa webů pomocí redakčního systému WordPress. Pokud máte na starosti více než jednu instalaci, dříve nebo později zjistíte, že sledování změn, jejich evidence a instalace vám zbytečně zabírá čas. Jen za rok 2011 vyšlo pět aktualizací v rámci verze WordPressu 3.1. Vynásobte to počtem webů a rozdílnými požadavky zákazníků, díky kterým spravujete vždy víc než jen jednu verzi, a ten správný “guláš” je na světě.

Řešením problému je použití vendor branch v Gitu. Jedná se o větev, ve které spravujete cizí aplikace nebo balíky. Tento přístup má hned několik výhod. Asi nejdůležitější je možnost sledovat změny mezi verzemi, zvlášť v případě bezpečnostních záplat. Další výhodou je zajištění kódu, na kterém je vaše aplikace/web závislá, pro případ nedostupnosti původního zdroje, ale také jednoznačnost zdroje, se kterým mají všichni vaši vývojáři a designeři pracovat.

Tento článek vám přináší Virtualmaster, poskytovatel virtuálních serverů a řešení pro lepší provoz web aplikací.

Vendor branch prakticky

Na první (a vlastně ani na druhý) pohled nepřinese použití vendor branch žádnou zásadní změnu při tvorbě webů. Tedy pokud používáte Git, nebo alespoň jiný verzovací systém. Základní distribuci WordPressu rozbalíte, v jeho adresáři inicializujete repositář, přidáte všechny soubory a provedete obligátní první commit.

tar xvfz wordpress-3.2.tar.gz
cd wordpress
git init
git add .
git commit -m "Wordpress 3.2" 

Pro lepší orientaci v dostupných verzí je dobré si ještě oštítkovat danou revizi.

git tag v3.2 

Při klasickém způsobu práce na webových stránkách by základní nastavení skončilo. Pro použití vendor branch musíte vytvořit speciální větev, v tomto případě nazvanou “wordpress”, ve které zůstanou jednotlivé původní verze redakčního systému, tak jak je získáte na stránkách projektu.

git branch wordpress 

Díky tomu získáte dvě větve, master a wordpress.

$ git branch
* master
  wordpress 

S tímto nastavením můžete implementovat potřebné změny, jako přidání témat, pluginů, vlastní kód a konfiguraci.

Upgrade

Jakmile bude k dispozici aktualizovaná verze WordPressu, můžete použít vendor branch, ve které provedete aktualizaci a následně sloučíte do pracovní verze webu (ve větvi master).

Pro upgrade se nezapomeňte přepnout do správné větve,

git checkout wordpress 

smažte původní soubory,

rm -Rdf * 

rozbalte aktualizovanou distribuci (v tomto případě 3.2.1)

cd ..
tar xvfz wordpress-3.2.1.tar.gz 

a přidejte ji do verzovacího systému.

cd wordpress
git add .
git commit -a -m "Wordpress 3.2.1"
git tag v3.2.1 

Tento postup vám zajistí jedna správné ošetření nových souborů, tak i přidání nových. Pro získání přehledu změn už stačí použít diff.

git diff HEAD^ HEAD 

Vlastní upgrade webu je potom záležitostí sloučení jednotlivých větví.

git checkout master
git merge wordpress 

Návod představuje snadnou cestu, jak si udržet kontrolu nad verzováním WordPressu. Jelikož nejste omezeni v počtu větví, které můžete použít, lze stejný postup použít i pro sledování dalších komponent – jako například pluginů, témat nebo knihoven. Samozřejmě s každou další závislostí se zvýší komplexita celé správy, ale na druhou stranu na tom budete pořád podstatně lépe než s ručním sledováním změn.

Správa více webů

Stejně, jako se dá použít více vendor branch pro sledování dalších komponent, je možné jednu větev použít pro sledování verzí pro více webů. V předcházejícím příkladu jsme pracovali pouze s jedním webem ve větvi master.

Nyní si pro každého zákazníka, resp. jeho webový projekt založíme novou větev, a to vždy z čisté instalace WordPressu.

git checkout wordpress
git branch example_com 

Práci na každém webu si tak můžete oddělit. V případě aktualizace WordPressu potom stačí opět sloučit změny z vendor branch.

git checkout example_com
git merge wordpress 

Přestože se ve většině případů bude jednat o weby klientů, nemusíte se centralizací do jednoho repositáře bát ztráty možnosti jednoduše sdílet změny. Díky možnosti integrace vzdálených repositářů lze zajistit načítání/propagaci změn do správných větví.

Pro konfiguraci použijte .git/config a pro každého zákazníka (resp. jeho repositář použijte konfiguraci)

[remote "zakaznik1"]
  url = git@github.com:zakaznik/webovky.git
  fetch = refs/heads/master:refs/remotes/zakaznik1/example_com
  push = example_com:refs/head/master 

Pro inicializaci stačí “pushnout” větev do masteru zákazníka

git push zakaznik1 example_com:master 

a případně začlenit změny zpět.

git fetch zakaznik1
git pull zakaznik1 

Jméno zakaznik1 identifikuje vzdálený repositář (definovaný pomocí URL), v rámci, kterého se používá větev master. Lokální sledování potom probíhá ve větvi example_com.

Nebuďte nástrojem

Využitím Gitu získáte nástroj, který vám umožní zachovat si přehled nejen o provedených změnách, ale i použitých verzí WordPressu (případně dalších knihoven). Pro větší komfort je logickým krokem automatizace celého procesu, pomocí jednoduché sady skriptů na základě výše popsaného řešení. Případně rozšíření o deployment díky post-receive hookům. Ale to už je víc než nad jedno pokračování.

Komentáře

Subscribe
Upozornit na
guest
4 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
tovi

Díky za pěkný článek.

U wordpressu dochází také ke změnám ve struktuře databáze. Je možné nějakým efektivním způsobem verzovat u všech zákazníků také MySQL databázi?

Děkuji

Radim

Samotnou databázi zálohuji zvlášt (tj. ne do stejné GIT repository), jen do jména backupu přidávám zkrácené jméno commitu, pro zajištění konzistentní obnovy. To samé platí o uploadech, uložených mimo vlastní root wordpressu.

Jediné verzování DB, které jsem zkoušel bylo verzování samotného schématu databáze a pro zajištění „migrací“ jsou využil funkce dbDelta, která je použitá při wp_upgrade. Tím se dají lehce uložit změny mezi jednotlivými verzemi schématu (směrem k novější verzi).

Funkce je dostupná ve wp-admin/includes/up­grade.php
https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/upgrade.php#L1495

Samozřejmě pro účely ukládání nezapomeňte mít execute = false

Radim

Ondřej Kučera

Vzhledem k tomu, že s upgrady WordPressu jsem se už nejednou tvrdě spálil, začal jsem ctít pravilo „nehrabej na to co funguje“.

Opravdu dokážete hromadně upgradnout více instalací WordPressu (desítky) a garantovat úplnou funkčnost? Já tedy ne. WordPress je takový bastl, že se často zblázní pluginy a podobně. Navíc je zákazník zbytečně zmatený z neustálých proměn administrace.

Nejlepší je WordPress pořádně zabezpečit a nechat ho ve verzi, v jaké byl původně nainstalovaný. V pohodě mi takhle běží stránky i z roku 2005 a je to bez problémů.

Marek Hudík

A tedy bezpečnostní opravy se neřeší?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.