Workflow pro vývoj WordPress webů

Vydal Jan Bien | 03/2017 | Trvalý odkaz | Komentáře (4)

Solidně vyvíjet weby na WordPressu, to znamená mít dobře nabroušené a zmáknuté nástroje. Článek o prostředích, deploymentu a verzování pro WordPress vývojáře a kodéry, kteří se potřebují v klidu soustředit na práci.

Byly doby, kdy vývojáři a kodéři webů byli praví kovbojové. Každý, kdo jsme s webem začínal, žil jsme takovým kovbojským životem. Nedělali jsme si vrásky se složitými nástroji, byla to doba nevinná a prostá. Vystačili jsme si s ostrým webem, který jsme skrze FTP klienta upravovali napřímo v Notepadu. Ti nejostřejší sekáči dokonce k serveru přistupovali pouze přes příkazovou řádku a soubory upravovali ve Vimu.

Za těch časů se taková úprava webu občas stala celkem napínavou kovbojkou. To když po úpravě najednou web přestal fungovat, souběžně s tím náhle spadlo vytáčené internetové připojení a v tom do pokoje vstoupil vychovatel či rodič za účelem výkonu rozhodnutí, že pro dalších 12 hodin už bylo dost počítače a internetu.

Dnes už máme vysokokapacitní připojení k internetu a vlastní pracovní místa z dosahu vychovatelů, ale také frekventovanější návštěvnost webů a vyšší očekávání uživatelů, pokud jde o jejich dostupnost a stabilitu. Doba proklatě nízkých koltů je už dávno pryč a my dnes pro vývoj potřebujeme poněkud chytřejší a automatizovanější workflow.

V tomto článku bych vám rád trochu blíže povyprávěl o tom, jak vypadá mé workflow, z jakých nástrojů je složené a jak o něm celkově uvažuji. Věřím, že bude inspirovat každého, kdo vyvíjí weby, na WordPressu zejména.

Jak vypadá ideální workflow

Workflow = sada dobře vybraných a promyšleně propojených nástrojů, která zjednodušuje vývojářův život, minimalizuje riziko chyb a šetří jeho už tak dost drahý čas. Je to taková více nebo méně automatizovaná výrobní linka, která osvobozuje vývojářovo myšlení od rutinních výrobních úkonů k samotné tvorbě a kreativitě.

Ideální workflow má pro mně tyto vlastnosti:

Klasické vývojářské workflow

Klasické vývojářské workflow vychází z konceptu tří prostředí:

  1. Vývojové prostředí – to je webserver, který je zcela oddělen od produkčního prostředí. Je to testovací a vývojové pískoviště. Na něm si mohu víceméně jakkoliv hrát, dokonce ho mohu celý smazat a nic vážného se nestane. Nemusí mít shodnou konfiguraci, jako je produkční prostředí.
  2. Stage (testovací) prostředí – to je webserver umístěný fyzicky v těsné blízkosti produkčního prostředí, shodně s ním konfigurované. V ideálním (a u WP teoretickém) případě “vidí” na ostrou databázi. Stage prostředí slouží k finálnímu otestování aplikace na serverové konfiguraci a také ke schválení klientem. Stage prostředí je takový můstek mezi vývojovým prostředím a produkčním prostředím.
  3. Produkční prostředí – to už je ostrý (nebo také live, živý) webserver, ze kterého web běží.

Podle velikosti projektu a množství vývojářů na něm pracujících je toto workflow více nebo méně košaté.

Na pozadí těchto prostředí existuje repozitář. To je datové úložiště zdrojových kódů, do kterého vývojáři skrze verzovací systém “commitují” a “pushují” všechny vyprodukované zdrojové kódy. Akce či proces, který se na vyžádání vývojáře postará o distribuci příslušené verze webu z repozitáře směrem do stage a následně do produkčního prostředí se nazývá deployment.

Scénář, který nad těmito prostředími probíhá, vypadá typicky takto:

Já ve svém workflow vydržuji vždy bez výjimky vývojové prostředí. Bez něj ani ránu, resp. ani řádek kódu. Vývojové prostředí provozuji lokálně na svém počítači a je jednotné pro všechny mé weby.

Produkční prostředí je klientův hosting a u všech webů existuje pochopitelně také.

Stage prostředí používám jak kdy a jak kde. Neřeší se úplně snadno kvůli databázi — ještě se k tomu dostanu.

Lokální webserver

Pro svou práci tedy nezbytně potřebuji lokální webserver. Ten mi umožní “hostovat” každý vyvíjený web lokálně na svém stoji, bez nutnosti trvalého internetového připojení produkčního nebo stage prostředí.

Možností lokálního hostování je povícero. Jedna možnost je: instalace webserveru (typicky Apache), databáze (typicky MySQL), scriptovacího jazyka (typicky PHP) s tím, že si vše ručně pokonfiguruji. Řešení je to nejsložitější a pokud serverovým záležitostem úplně nerozumím, mohu si způsobit různé trable, pomalým počítačem počínaje, únikem diskrétních dat konče.

Druhá, snadnější možnost, je instalace hotového “LAMP balíčku”. Já jsem několik let na Windows spokojeně používal XAMPP. Chvilku jsem si hrál s MAMP a plánoval vyzkoušet Trellis od Roots.io, ale od toho jsem upustil ve jménu Dockeru.

Docker. Třetí a nejlepší, nejčistší a nejbezpečnější varianta. Skvělé je, že každý jeden web může běžet v tzv. “docker konteineru”, který (narozdíl od předchozích dvou variant) běží izolovaně od ostatních webů a od operačního systému, do kterého “nevidí”. Je to taková hodně chytrá emulace.

Když mohu, tak se rád vyhnu terminálu, což tady mohu díky aplikaci Local by Flywheel. Ta spojuje předpřipravený Docker konteiner rovnou s WordPressem s krásným praktickým UX rozhraním. Prakticky “na jedno kliknutí” mám připravenou čistou lokální WP instalaci, na druhé kliknutí si vyberu typ serveru (Apache, nginx), verzi PHP a MySQL. (A na třetí kliknutí fakturuji práci ;). Suprová je funkce Live Link, po jejíž aktivaci mohu na svou lokální instanci přistupovat odkudkoliv z internetu. Hodí se skvěle pro testování na mobilech a tak.

Verzování souborů

Verzovací systém slouží ke správě všech úprav souborů na projektu. S verzovacím systémem se mohu vrátit k jakékoliv dřívější verzi, mohu vrátit jednu konkrétní úpravu, atd… Adresář spravovaný verzovacím systémem se nazývá repozitář.

Používání verzovacího systému by měla být pro každého vývojáře samozřejmost. Vývojář, který nepoužívá verzovací systém, není vývojář.

Pro mě byl jasná volba GIT. Je nejrozšířenější, decentralizovaný (nepotřebuje server) a umí toho mraky. Nevyžauje moc velké osobní odvahy prohlásit: GIT je de-facto verzovací standard.

CZ.NIC vydal český překlad pěkné a vyčerpávající knihy o gitu od Scotta Chacona and Bena Strauba, který si můžete prostudovat online, stáhnout jako e-knihu nebo koupit v papíře. Ale studujte spíše po kouskách, jinak tam utopíte mraky času.

S gitem jde pracovat v terminálu, nebo z GUI klienta. Na Windows jsem používával TortiseGit, který se integruje do Windows Exploreru. Na Macu používám SourceTree (ten je přímo od provozovatelů Bitbucketu), který občas kombinuji s integrací v editoru — v Sublime Text rozšíření SublimeGit a teď čerstvě mě zaujalo Visual Studio Code, který má git moc pěkně integrován nativně.

Všechny repozitáře jsem si navíc navykl hostovat na vzdáleném serveru. Nejznámější git hostingy jsou Github a Bitbucket, já využívám druhý zmíněný. Vzdálené repozitáře používám především ze dvou důvodů:

  1. Zálohování: Všechen kód, který jsem kdy napsal, mám v Bitbucketu. Co je jen na lokále se může ztratit. Co je ve vzdáleném repozitáři, je “doma” v bezpečí. Pushuji stále, pushuji rád.
  2. Spolupráce: Na některých projektech zvu ke spolupráci Jakuba. Vzdálený repozitář je elegantní způsob, jak můžeme každý upravovat kód, vzájemně si soubory nepřepisovat a pohodlně mezi sebou synchronizovat.

Projektový repozitář

Otázka je: Co vše patří do repozitáře? V zásadě jsou dvě možnosti:

  1. Pouze má práce, tedy šablona a případně plugin (pluginy), které jsou mým výtvorem.
  2. Celý WordPress, pluginy i šablona. Zkrátka prakticky vše, kromě adresáře “uploads”.

Tato zdánlivě bezvýznamná otázka má ale velký (až filosofický!) význam. Odpověď záleží na tom, jak k projektu přistupujeme: o jaký projekt jde, jakým způsobem vlastně WordPress používáme, jak zamýšlíme deployment, jak se postaráme o aktualizace WP, kolik lidí na projektu pracuje, … Ani jeden způsob není lepší nebo horší.

Já povětšinou používám první způsob: verzuji jen to, co je má práce. Tedy šablonu, případně nějaký ten plugin. O WordPressu tedy uvažuji jako o svébytném prostředí, do kterého je “zasazena” má šablona (případně plugin). WordPress samotný si takříkajíc “žije svým životem”(tento výstižný pojem jsem si vypůjčil od Vladimíra Smitky).

Je důležité vědět, že weby, které typicky realizuji, jsou malého až středního rozsahu. Většinou jde o zcela standardní WordPress instalaci s mou vlastní šablonou a s několika ověřenými pluginy. Na takových webech nebývá po delší dobu od dokončení nutná žádná práce a proto musí být extra snadné (nenákladné) provést aktualizaci WordPressu a pluginů.

Můžeme o tom ale uvažovat i opačně: tak, že WordPress je zasazen do naší aplikace. Pak dává smysl do repozitáře zahrnout celý WordPress a vypnout automatické aktualizace — ty jsou ostatně vypnuté automaticky, pokud adresář s WordPressem je repozitářem. Tento přístup je typický pro větší projekty, kde máme WP implementovaný více spešl, instalujeme jej třebas přes Composer, apod.

Deployment souborů

Deployment = proces, který se postará o rozdistribuování úpravy webu z repozitáře do stage prostředí a následně do produkčního prostředí. Zároveň vývojáři dává možnost vzít tuto akci zpět, pokud se z nějakého důvodu nevydaří.

Já pro deployment používám kombinaci dvou nástrojů: verzovacího systému (git) a skriptu pro upload souborů.

Každý jednotlivý web má svůj vlastní repozitář se dvěmi větvemi: dev a master. Pracovní adresář mám standardně namířen na dev, kam commituji různé malé pracovní commity. Když mám hotovo a chci provést deployment nové verze, dev větev merguji do master větve a spustím uploadovací skript. V master větvi mám tedy commity, které byly uploadovány. Tím mám dobrý přehled a jednoduše se mohu kdykoliv vrátit k některé z předchozích verzí.

Upload souborů na server probíhá scriptem přes starý dobrý FTP (resp. SFTP) protokol. To proto, že většina webů je hostovaná na klasickém sdíleném hostingu, kde mám málokdy větší vymoženosti. Používám Davido-Grudlův skript FTP Deployment, který je děsně dobrej:

  1. Pracuje z příkazové řádky, celá konfigurace je uložená v INI souboru. Jeho spuštění tak jde šikovně automatizovat.
  2. Je hodně rychlý, pracuje inkrementálně. Na serveru má uložený soubor s otiskem všech nahraných souborů. Při deploymentu tak nahrává jen to, co se od minula změnilo. To šetří přenesená data a zkracuje dobu uploadu.
  3. Minimalizuje nedostupnost webu. Při deploymentu pojmenovává nahrávané soubory dočasným názvem. Až když se mu podaří všechno nahrát, tak nově nahrané soubory přejmenuje na pravé názvy. Protože přejmenování souborů je (na rozdíl od uploadu) atomická operace, web je úplně miniaturní dobu v nekonzistentním stavu, kdy je část souborů nová a část ještě stará.
  4. Eliminuje riziko rozbitého webu. Pokud dojde k přerušení uploadu (výpadek spojení, obsazený hostingový prostor, …), nezůstane web rozbitý kvůli nekonzistenci (viz předchozí bod). Prostě vše běží jako před deploymentem.
  5. Umí toho hodně. Aktivovat a deaktivovat maintenance mód (režim údržby), promazat po deploymentu keš, nahrávat jen vybrané soubory. Tak si říkám, co vlastně neumí?

V úvahu by připadal i některý z inkrementálních deployovátek, které si umí tahat informace rovnou z gitu: PHploy nebo git-ftp.

Protože pracuji hodně sám, je v pohodě, že deployment provádím ze svého lokálního repozitáře. Kdybych pracoval častěji v týmu více lidí, bylo by daleko vhodnější deployment globalizovat – externalizovat někam ven. Jako velmi vhodné se jeví napojení deploymentu na vzdálený repozitář. Šikovně a bezpečně to má přes Docker vyřešené Bitbucket přes Pipelines s již zmíněným git-ftp.

Zde bych asi měl krátce zmínit i klasický FTP klient. Používám vysokozdvižný ForkLift, na Windows jsem používal WinSCP. Myslím si ovšem, že do standardního workflow by FTP klient patřit neměl. Já jej používám jen pro jednorázové a příležitostné úkony: pro úpravu souborů specifických pro konkrétní prostředí (htaccess, wp-config), a při vytváření samotného workflow.

Verzování a deplyment databáze

Pokud mohu tvrdit, že management kolem souborů mám skrze verzovací systém a deployment vyřešený ke své spokojenosti, nemohu totéž prohlásit o MySQL databázi. Se systémovým verzováním a deploymentem databází je obecně svízel.

U WordPressu je hodně dat uloženo právě v databázi. Vždy je to obsah stránek a často je to i část funkčnosti nebo vzhledu. Pokud příkladně používáte některý z pluginů pro formuláře, máte v databázi uloženou třeba samotnou definici a nastavení formulářů. Otázka, co z principu patří do databáze a co do souborů, by bylo na dlouhou diskuzi. Zkrátka to tak je a nějak si s tím musíme poradit.

WordPress sám má verzování databáze vyřešené jen na úrovni jednotlivých post typů (příspěvků, stránek). Což je hodně málo. Deployment nebo synchronizaci “řeší” (ano, uvozovky) exportováním a importováním přes XML soubory. Mnoho dat, jako je nastavení WP, vzájemná provázání, data pluginů, atd… neřeší vůbec. Některé pluginy si to nějak řeší po svém, na každý pád to nemá jednotou formu a z toho plyne i problém s jednotným deploymentem.

Nejambicióznější projekt, který se o systémové verzování WordPress databáze a vyřešení deploymentu snaží, je VersionPress. Startup z Pardubic, o kterém Borek Bernard už pár let vypráví v rozhovorechpo konferencích. VersionPress otevírá dveře do úplně nového světa a docela dost nám jednou naše workflow zajímavě promění. S ním to však zatím pořád vypadá na dlouhou trať.

Nejlepší reálně použitelné řešení je prémiový plugin WP Migrate DB Pro. Kdo by za něj nechtěl platit, může zkusit jeho bezplatný starší klon WP Sync DB. Plugin si nainstalujete na dvě prostředí, mezi kterými pak data přepisujete. Umožňuje omezit přepis jen na některé databázové tabulky (odfiltrovat lze také jen některé post typy), vynechat SPAM komentáře, samozřejmě nahrazuje všechny absolutní odkazy správnou variantou a před provedením lze provést zálohu. Je to tedy trochu chytřejší přepisování, ale i tak jde pořád o hromadný přepis dat — nenazval bych tento postup ryzím deploymentem.

Protože je to s databází tak jak je, né vždy zařazuji do svého workflow stage prostředí. Když s klientem řešíme menší úpravy, spíše je zapracuji nějak chytře v produkčním prostředí.

Například: řešíme novou verzi jedné stránky. Vytvořím si ji neprve na vývojové verzi, kde odladím šablonu. Pak šablonu deployuji do produkce, stránku ručně založím na neveřejné adrese v produkci, kde ji následně doladíme s klientem.

Při úpravách si eviduji celkem podrobný checklist, co budu vše muset udělat, až klient úpravy odmávne. Hlavní úkony na tomto checklistu bývají vesměs jen se svou kategorií: a) stará dobrá “kopy pasta”, b) ruční exportování a importování jen určitých dat.

U větších úprav se už bez stage prostředí neobejdu. Co do metod a nástrojů pracuji ale víceméně stejně jako u malých úprav + někdy používám ruční přepis databázových tabulek a ruční synchronizaci souborů a párkrát jsem použil WP Sync DB. Žádná slavná automatizace se v tomto směru tedy nekoná.

Založení workflow u nového webu

Tak to by bylo asi vše o mém workflow. Pro úplnost chybí dvě věci. První věc je, jak nové workflow nechávám vzniknout u nového webu. A druhá: jak řeším web, na kterém jsem nic neupravoval delší dobu.

Když začínám realizovat nový web, ihned zakládám repozitář a vývojové prostředí. Až když web nabude jakés takés kvality, založím stage — to je zpravidla jen neveřejná subdoména na klientově doméně a stejném hostingu, kde web také ve finále poběží.

Celý web jednorázově pomocí FTP klienta zkopíruji na stage. Buďto ručně, nebo pluginem Duplicator (už jsem o něm psal), zapojím FTP Deployment z lokálního repozitáře, pošlu klientovi odkaz k připomínkování. Všechny další úpravy už frčím výchozím scénářem.

Do produkce je postup často ještě jednodužší: složku se stage webem přesunu na hostingu jen do jiného adresáře a Adminerem upravím odkazy v databázi spuštěním těchto tří MySQL příkazů:

UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://dev.example.cz/', 'http://www.example.cz/'); 
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'http://dev.example.cz/', 'http://www.example.cz/'); 
UPDATE wp_options SET option_value = REPLACE (option_value, 'http://dev.example.cz/', 'http://www.example.cz/');

Tím samozřejmě zanikne stage prostředí, ale to je většinou žádoucí. Pokud potřebuji stage zachovat, tak postupuji stejně jako při kopii z vývoje na stage.

Oživení workflow u webu “po letech”

Občas provádím úpravy na webu po mnoha měsících bez zásahu. Vývojové prostředí už pak není obsahově aktuální a možná jsem ho i v rámci průběžného úklidu smazal. Potřebuji tedy data na lokále uvést do aktuálního stavu podle produkce.

Pokud jde o malý web, prostě jej z produkce zkopíruji stejně, jako popisuji výše.

U obsáhlejšího webu se snažím nekopírovat na vývoj složku “uploads”. Je zbytečné, abych si disk v notebooku plnil daty, která slouží jen k otestování. Zkopíruji jen WordPress, šablonu, pluginy. A samozřejmě databázi – ručně nebo pluginem WP Sync DB.

Abych ale na vývoji nekoukal na web bez načtených obrázků, upravím si lokální .htaccces tak, aby se mi neexistující obrázky načítaly z produkce. Řeší to tenhle kousek kódu, který jsem šlohnul Stevovi Grunwellovi:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Attempt to load files from production if
  # they're not in our local version
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule wp-content/uploads/(.*) \
    http://{PROD}/wp-content/uploads/$1 [NC,L]
</IfModule>

A to je vše, přátelé

Tak tolik o mém workflow, které mi (podle mého soudu) slouží dobře a poctivě. Rád bych podotkl, že si nečiním nárok na to, aby bylo mé workflow považováno za nejlepší, univerzální nebo snad dokonce ideální. Jiné typy webových projektů, vznikající za jiných podmínek, spravované jinými lidmi, pracujícími na jiných platformách a pro jiné klienty, budou mít na workflow jiné požadavky.

Budu rád, když se v komentářích podělíte o to, jak WordPress workflow řešíte vy, co máte vychytané a kde naopak cestu stále hledáte.

Níže ještě připojuji pár zajímavých souvisejících článků k tématu.

Tož tak.

Remote Workflows

Installing a Local Server

WordPress Deployment Workflow: How I Roll

Deploying WordPress: What’s your Workflow?

Database migrations & deployments with WordPress

O autorovi

Jan Bien
Jan Bien
Jako kluk jsem si hrál se stavebnicí Merkur, kterou jsem v dospělosti (lze-li o něčem takovém u muže vůbec mluvit) vyměnil za WordPress. S WordPressem kouzlím zajímavé weby, radím lidem, zda je WordPress dobrý nápad pro konkrétní projekt, a občas koučuji jiné freelancery, co a jak s WordPressem podniknout ke spokojenosti své i svých klientů.

4 komentáře: “Workflow pro vývoj WordPress webů”

  1. Borek Bernard napsal:

    Skvělý přehled!

  2. Jakub Kadeřávek napsal:

    Super, ten htaccess určitě někde využiju.

    Na přepisovaní databáze používám skript od interconnectit – viz https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ a funguje skvěle i na serializovaná data

  3. Michal Odcházel napsal:

    Pěkný článek. ;-)
    Drobná rada u přepisování URL v databázi. Lepší je použít třeba tento plugin https://cs.wordpress.org/plugins/better-search-replace/ který umí i serializovaný pole.
    Možná nejlépe tvořit rovnou s relativní URL :-)

  4. Jan Rybařík napsal:

    Perfektní článek. Verzování DB je jeden z důvodů, kvůli němuž od WordPressu momentálně víc a víc utíkám:)

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *