Cieľom tohto článku je na príklade knižnice schema-keeper ukázať nástroje, ktoré umožňujú podstatne zjednodušiť proces vývoja databáz v rámci PHP projektov používajúcich databázu PostgreSQL.

Informácie z tohto článku budú predovšetkým užitočné pre vývojárov, ktorí chcú maximálne využiť možnosti PostgreSQL, ale stretávajú sa s problémami správy obchodnej logiky, presunutej do DB.

Článok nebude popisovať výhody alebo nevýhody uchovávania obchodnej logiky v databáze. Predpokladá sa, že čitateľ si už výber urobil.

Bude sa zaoberať nasledujúcimi otázkami:

1. V akom formáte uchovávať dump štruktúry DB v systéme na kontrolu verzií (ďalej len VCS)
2. Ako sledovať zmeny v štruktúre DB po uložení dumpu
3. Ako prenášať zmeny v štruktúre DB do iných prostredí bez konfliktov a obrovských súborov migrácií
4. Ako nastaviť proces paralelnej práce na projekte viacerých vývojárov
5. Ako bezpečne nasadzovať väčšie množstvo zmien v štruktúre DB na produkčné prostredie
   

   SchemaKeeper je optimalizovaný na prácu s uloženými procedúrami napísanými v jazyku PL/pgSQL. Testovanie s inými jazykmi nebolo vykonané, preto môže byť použitie menej efektívne alebo nemožné.

V akom formáte uchovávať dump štruktúry DB v VCS

Knižnica schema-keeper poskytuje funkciu saveDump, ktorá uchováva štruktúru všetkých objektov z DB vo forme samostatných textových súborov. Na výstupe sa vytvorí adresár obsahujúci štruktúru DB rozdelenú na skupinové súbory, ktoré je možné ľahko pridať do VCS.

Pozrime sa na transformáciu objektov z DB do súborov na niekoľkých príkladoch:

Typ objektu
Schéma
Názov
Relatívna cesta k súboru

Tabuľka
public
accounts
./public/tables/accounts.txt

Uložená procedúra
public
auth(hash bigint)
./public/functions/auth(int8).sql

Pohľad
booking
tariffs
./booking/views/tariffs.txt

Obsah súborov je textovú reprezentáciu štruktúry konkrétneho objektu DB. Napríklad pre uložené procedúry bude obsah súboru kompletné určenie uložené procedúry začínajúce blokom CREATE OR REPLACE FUNCTION.

Ako je vidieť z tabuľky vyššie, cesta k súboru obsahuje informácie o type, schéme a názve objektu. Takýto prístup uľahčuje navigáciu v dumpe a kódovú kontrolu zmien v DB.

Prípona .sql pre súbory s kódom uložených procedúr je vybrané, aby IDE automaticky poskytovalo nástroje na interakciu s DB pri otvorení súboru.

Ako sledovať zmeny v štruktúre DB po uložení dumpu

Uložením dumpu aktuálnej štruktúry DB do VCS získavame možnosť overiť, či boli vykonané zmeny v štruktúre databázy po vytvorení dumpu. V knižnici schema-keeper na zistenie zmien štruktúry DB je predpokladaná funkcia verifyDump, ktorá bez vedľajších účinkov vracia informácie o rozdieloch.

Alternatívny spôsob overenia — znovu zavolať funkciu saveDump, zadajúc tú istú adresáru a overiť v VCS prítomnosť zmien. Keďže všetky objekty z DB sú uložené v samostatných súboroch, VCS ukáže iba zmenené objekty.
Hlavná nevýhoda tohto spôsobu — potreba prepisovania súborov, aby sme videli zmeny.

Ako prenášať zmeny v štruktúre DB do iných prostredí bez konfliktov a obrovských súborov migrácií

Vďaka funkcii deployDump môže byť zdrojový kód uložených procedúr upravovaný úplne rovnako ako bežný zdrojový kód aplikácie. Môžete pridávať/odstraňovať nové riadky v kóde uložených procedúr a okamžite posielať zmeny do systému správy verzií alebo vytvárať/odstraňovať uložené procedúry vytvorením/odstránením príslušných súborov v adresári s dumpom.

Napríklad na vytvorenie novej uložené procedúry v schéme public stačí vytvoriť nový súbor s príponou .sql v adresári public/functions, vložiť do neho zdrojový kód uložené procedúry, vrátane bloku CREATE OR REPLACE FUNCTION, potom zavolať funkciu deployDump. Podobne sa deje aj zmena a odstránenie uložené procedúry. Takto sa kód zároveň dostáva aj do VCS, aj do databázy.

Ak sa v zdrojovom kóde nejakej uložené procedúry objaví chyba alebo nezrovnalosť medzi názvami súboru a uložené procedúrou, potom deployDump sa nevykoná a zobrazí text chyby. Nesúlad uložených procedúr medzi dumpom a aktuálnou DB je nemožný pri použití deployDump.

Pri vytváraní novej uložené procedúry nie je potrebné ručne zadávať správny názov súboru. Stačí, aby mal súbor príponu .sql. Po zavolaní deployDump text chyby bude obsahovať správny názov, ktorý možno použiť na premenovanie súboru.

deployDump umožňuje meniť parametre funkcie alebo návratový typ bez ďalších akcií, zatiaľ čo pri klasickom prístupe by bolo treba
najprv vykonať DROP FUNCTION, a až potom CREATE OR REPLACE FUNCTION.

Žiaľ, existujú niektoré situácie, kedy deployDump nie je možné automaticky uplatniť zmeny. Napríklad ak sa odstráni spúšťacia funkcia, ktorá je používaná aspoň jednou spúšťou. Takéto situácie sa riešia manuálne pomocou migračných súborov.

Ak za prenášanie zmien v uložených procedúrach zodpovedá samotný schema-keeper, tak na prenášanie ostatných zmien v štruktúre je potrebné použiť migračné súbory. Napríklad dobrá knižnica na prácu s migráciami je doctrine/migrations.

Migrácie musia byť aplikované pred spustením deployDump. To umožňuje zaviesť všetky zmeny v štruktúre a riešiť problematické situácie, aby sa zmeny v uložených procedúrach nahrali bez problémov.

Podrobnejšie sa práca s migráciami popíše v nasledujúcich častiach.

Ako nastaviť proces paralelnej práce na projekte viacerých vývojárov

Je potrebné vytvoriť skript na úplnú inicializáciu DB, ktorý bude spustený vývojárom na jeho pracovnej stanici, čím sa privedie štruktúra lokálnej DB do zhody s uloženým v VCS dumpom. Najjednoduchšie je rozdeliť inicializáciu lokálnej DB na 3 kroky:

1. Import súboru s základnou štruktúrou, ktorý bude nazvaný napríklad base.sql
2. Aplikácia migrácií
3. Vyvolanie deployDump

base.sql — to je východiskový bod, na ktorý sa aplikujú migrácie a vykonáva sa deployDump, t.j. base.sql + migrácie + deployDump = aktuálna štruktúra DB. Takýto súbor možno vytvoriť pomocou utilitky pg_dump. Používa sa base.sql výhradne pri inicializácii databázy z nuly.

Nazvime skript na úplnú inicializáciu DB refresh.sh. Pracovný proces môže vyzerať nasledovne:

1. Vývojár spustí vo svojom prostredí refresh.sh a získa aktuálnu štruktúru DB
2. Vývojár začne pracovať na zadanom úlohe, modifikujúc lokálnu DB na potreby nových funkčností (ALTER TABLE ... ADD COLUMN atď.)
3. Po dokončení úlohy vývojár vyvolá funkciu saveDump, aby uložil do VCS zmeny vykonané v DB
4. Vývojár znovu spúšťa refresh.sh, potom verifyDump, ktorý teraz zobrazuje zoznam zmien na zaradenie do migrácie
5. Vývojár prenesie všetky zmeny štruktúry do migračného súboru, spúšťa opäť refresh.sh a verifyDump, a ak je migrácia správne zostavená, verifyDump vykáže absenciu rozdielov medzi lokálnou DB a uloženým dumpom

Popisovaný proces je kompatibilný s princípmi gitflow. Každá vetva vo VCS bude obsahovať svoju verziu dumpu, a pri zlúčení vetiev dôjde k zlúčeniu dumpov. V drvivej väčšine prípadov nie je potrebné vykonávať žiadne dodatočné akcie, ale ak boli v rôznych vetvách vykonané zmeny, napríklad v tej istej tabuľke, môže dôjsť ku konfliktu.

Zvážme konfliktovú situáciu na príklade: existuje vetva develop, od ktorej sú odvetvené dve vetvy: feature1 a feature2, ktoré nemajú konflikty s develop, ale majú konflikty medzi sebou. Je potrebné vykonať zlúčenie oboch vetiev do develop. Pre takýto prípad sa odporúča najprv vykonať zlúčenie jednej z vetiev do develop, a potom zlúčenie develop do zostávajúcej vetvy, pričom sa vyriešia konflikty v zostávajúcej vetve, po ktorých sa vykoná zlúčenie poslednej vetvy do develop. Počas fázy riešenia konfliktov môže byť potrebné upraviť migračný súbor v poslednej vetve, aby zodpovedal finálnemu dumpu, ktorý zahrnuje výsledky zlúčení.

Ako bezpečne nasadzovať väčšie množstvo zmien v štruktúre DB na produkčné prostredie

Vďaka prítomnosti dumpu aktuálnej štruktúry databázy vo VCS je možné skontrolovať produkčnú databázu na presnú zhodu s požadovanou štruktúrou. To zaručuje, že do produkčnej databázy sa úspešne preniesli všetky zmeny, ktoré navrhli vývojári.

Keďže DDL v PostgreSQL je transakčný, odporúča sa dodržiavať nasledujúci poriadok nasadenia, aby sa, v prípade neočakávanej chyby, "bezbolestne" vykonal ROLLBACK:

1. Začať transakciu
2. V transakcii vykonať všetky migrácie
3. V tej istej transakcii vykonať deployDump
4. Bez ukončenia transakcie vykonať verifyDump. Ak nie sú žiadne chyby, vykonať COMMIT. Ak sú chyby, vykonať ROLLBACK

Tieto kroky sa pomerne jednoducho integrujú do existujúcich prístupov k nasadeniu aplikácií, vrátane zero-downtime.

Záver

Vďaka vyššie uvedeným metódam je možné z projektov "PHP + PostgreSQL" vyťažiť maximálnu výkonnosť, pričom sa obetuje relatívne malé množstvo pohodlia pri vývoji v porovnaní s implementáciou celej obchodnej logiky v hlavnom kóde aplikácie. Navyše, spracovanie údajov v PL/pgSQL často vyzerá priehľadnejšie a vyžaduje menej kódu ako rovnaká funkcionalita napísaná v PHP.

Zdroj: habr.com