Weblabor

Manapság minden felelős fejlesztő használ verziókövető-rendszereket. Minden kódunk minden változását nyomonkövetjük, felülvizsgáljuk, analizáljuk. Elterjedt gyakorlat, aminek hasznosságát senki nem vonja kétségbe. Miért is annyira nagyszerű dolog ez? Sok egyéb mellett például azért, mert pár másodperc alatt képesek vagyunk visszaállni alkalmazásunk egy korábbi verziójára, legyen az két nappal, vagy akár két évvel korábbi állapot. Ez így nagyon jól hangzik, de tényleg képesek vagyunk rá?

Vegyük a következő élethelyzetet: régóta fejlesztett szoftverünk egy régebbi verziójában felbukkan egy hiba. A feladat egy új kollégához kerül, aki eddig csak a szoftver friss verzióin dolgozott. A verziókövetőből checkout-olja a megfelelő kódot, elindítja az alkalmazást, majd némi fejvakarás közepette szétnéz az irodában: „Srácok, van valakinek ehhez a verzióhoz passzoló adatbázisa?”

Amire ezzel a kis példával rá szeretnék mutatni, az az, hogy az alkalmazás maga több a puszta kódnál, esszenciális része az adatbázis is. Ennek ellenére azt a szigorú fegyelmet, amivel a kódunkat karban tartjuk, sokszor valahogy nem érezzük kötelezően érvényesnek az adatbázisunkra. Pedig az adatbázis verziókövetésének sok előnye van:

• egy-egy commit-ban a kód változása mellett rögtön látszik, hogy hogyan változott az adatbázisséma;
• ha minden változás megvan, akkor a referencia-adatbázis bármikor felépíthető;
• ugyanígy a kód bármelyik verziójához tartozó adatbázis bármikor felépíthető;
• ha minden változtatást megfelelően standardizált módszerrel tárolunk, akkor az adatbázis frissítése automatizálható.

Ha elfogadjuk, hogy ez nekünk jó, akkor felmerül a kérdés, hogy mégis hogyan is tegyük ezt meg. Ahogy mondani szokás, a lehetőségek tárháza végtelen: az interneten keresgélve sok módszert, leírást, eszközt találhatunk ennek a megvalósítására. Én most csak egy eszközt mutatnék be, ami nálunk jól bevált.

Liquibase

A Liquibase egy ingyenes, nyílt forráskódú, adatbázisfüggetlen változáskövető eszköz, ami jól használható az elterjedt verziókövető eszközökkel. Lényege, hogy a szükséges adatbázismódosításokat nem közvetlenül az adatbázison hajtjuk végre, hanem minden változást struktúrált módon, egy ún. changelog fájlban tartunk nyilván. Ezt a changelog fájlt aztán a Liquibase parancssoros alkalmazás segítségével vagy kódból, a Liquibase Java API-val tudjuk érvényesíteni. Ennek használata a következő előnyökkel jár:

• a changelog fájl feltölthető verziókövetőbe, ezáltal megvalósíthatjuk adatbázisunk verziókövetését;
• a Liquibase számon tartja, hogy mely változások kerültek korábban már érvényesítésre adatbázisunkon, és csak a szükségeseket futtatja.

Hogyan is néz ki ez a gyakorlatban?

A megszerkesztett changelog fájlunk (ennek felépítéséről részletesen később lesz szó) futtatása egy Oracle adatbázison például a következőképpen néz ki:

liquibase                                 \
--classpath=lib/ojdbc14.jar               \
--driver=oracle.jdbc.OracleDriver         \
--url=jdbc:oracle:thin:@localhost:1521:XE \
--username=user                           \
--password=secret                         \
--changeLogFile=changelogMaster.xml       \
update

A fenti példában a --classpath-t kivéve minden paraméter kötelező. A --driver paraméter adja meg az adatbázishoz tartozó driver nevét, amit használni akarunk. A classpath az az útvonal, ahol a szükséges fájlokat tároljuk (mint pl. az adatbázis driver-e). A --changeLogFile paraméter adja meg a futtatandó changelog fájl nevét. Az --url paraméter a JDBC adatbáziskapcsolat-sztringje, ami (a --username és a --password paraméterekkel kiegészülve) az adatbázis eléréséhez szükséges minden információt tartalmaz.

Mint látható, futtatáskor elég sok adatot kötelezően meg kell adnunk. Hogy mégse kelljen ezt minden alkalommal begépelnünk, használhatunk egy properties fájlt, amiben ezeket a szükséges információkat felsoroljuk.

# liquibase.properties

classpath:     lib/ojdbc14.jar
driver:        oracle.jdbc.OracleDriver
url:           jdbc:oracle:thin:@localhost:1521:XE
username:      user
password:      secret
changeLogFile: changelogMaster.xml

Ha liquibase.properties-nek nevezzük el, és a Liquibase alkalmazással egy mappába tesszük, akkor futtatáskor automatikusan ezeket az adatokat fogja használni. Más esetben a következő szintakszissal érhető el:

liquibase --defaultsFile=<útvonal>/<fájlnév>.properties update

Ha mindent megfelelően adtunk meg, akkor a Liquibase az első sikeres futtatás legelején létrehoz az adatbázisunkban két táblát DATABASECHANGELOG és DATABASECHANGELOGLOCK néven. Ez az egyetlen alku, amit a Liquibase használatához meg kell kötnünk: erre a két táblára szüksége van mindenképpen. Cserébe az adatbázis tudja magáról, hogy melyik változás lett már futtatva rajta és pontosan mikor.

A changelog fájl felépítése

Eredetileg a changelog fájlok csak XML típusúak lehettek. Ma már a Liquibase támogatja emellett a YAML, JSON és a (speciális kommentekkel ellátott) SQL típusokat is. Jelen cikkben az XML típust használva fogom bemutatni egy changelog fájl felépítését.

A changelog fájl tartalmazza a változásokat (changes/refactorings), amiket végre szeretnénk hajtani. Minden változtatáshoz, amit megtehetünk tartozik egy Liquibase change. Ezeket a change-eket changeSet-ekbe kell szerveznünk. Minden changeSet kötelezően rendelkezik egy id és egy author paraméterrel, valamint tartalmaz egy vagy több change-et. change-ek csak changeSet-en belül létezhetnek.

Egy példán keresztül talán szemléletesebb, hogy is működik ez. Tegyük fel, hogy üres adatbázisunkban létre szeretnénk hozni egy user táblát, id, login és created mezőkkel. Ebben az esetben a changelog fájlunk a következőképpen fog kinézni:

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
>
    <changeSet author="botond" id="create_user_table">
        <createTable tableName="user">
            <column name="id" type="integer"/>
            <column name="login" type="VARCHAR(255)"/>
            <column name="created" type="TIMESTAMP"/>
        </createTable>
    </changeSet>
</databaseChangeLog>

Ez a példa csak egy a sok támogatott change közül: az alapvető műveletektől, mint tábla/oszlop létrehozása, törlése, az elsődleges és külső kulcsok, különböző megszorítások létrehozásán át egészen szekvenciák, indexek és tárolt eljárások létrehozásáig, módosításáig (és tovább) terjed a lista.

Adattartalom kezelése

A Liquibase nem áll meg a sémadefiníciós utasításoknál. Tegyük fel, hogy az előbb létrehozott táblánkba szeretnénk felvenni egy developer nevű felhasználót, hogy tudjuk tesztelni a fejlesztett alkalmazásunkat. Ezt persze megtehetjük bármelyik adatbáziskezelővel, de ilyenkor a többi fejlesztő is arra kényszerül, hogy kézzel hozza létre a felhasználót. Ehelyett használhatjuk az insert utasítást. Ekkor a changelog fájlunk a következőképpen fog kinézni:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
>
    <changeSet author="botond" id="create_user_table">
        <createTable tableName="user">
            <column name="id" type="INTEGER"/>
            <column name="login" type="VARCHAR(255)"/>
            <column name="created" type="TIMESTAMP"/>
        </createTable>
    </changeSet>
    <changeSet author="botond" id="insert_developer_user">
        <insert tableName="user">
            <column name="id" value="1" />
            <column name="login" value="developer" />
            <column name="created" valueDate="2013-07-30T16:30:42" />
        </insert>
    </changeSet>
</databaseChangeLog>

Az egyedi insert-ek mellett lehetőségünk van nagyobb adatmigrációra is a loadData és a loadUpdateData utasításokkal. Ezek az utasítások – az oszlopok egyeztetése után – képesek CSV fájlokból feltölteni az adatbázist.

Előfeltételek megadása

Az előbb láttunk egy példát arra, hogy tesztfelhasználót hoztunk létre Liquibase használatával. Igen ám, de mi a helyzet, ha ez az igény csak később jelentkezett? Elkészítettük a táblát létrehozó utasítást, feltöltöttük verziókövetőbe, a fejlesztő kollégák futtatták, és tegyük fel, van, aki már létre is hozott magánál developer nevű felhasználót. Nyilván szeretnénk elkerülni, hogy problémát okozzunk egy újabb developer nevű felhasználó létrehozásával. Szerencsére a Liquibase erre is kínál megoldást, a preConditions elem használatával. Minden changeSet elején definiálhatunk előfeltételeket, hogy milyen esetben futtassa a Liquibase az adott changeSet-et. A mi esetünkben például vizsgálhatjuk, hogy a user táblában van-e már developer nevű felhasználó. Ezzel kiegészülve a changelog fájlunk már így néz ki:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
>
    <changeSet author="botond" id="create_user_table">
        <createTable tableName="user">
            <column name="id" type="INTEGER"/>
            <column name="login" type="VARCHAR(255)"/>
            <column name="created" type="TIMESTAMP"/>
        </createTable>
    </changeSet>
    <changeSet author="botond" id="insert_developer_user">
        <preConditions onFail="MARK_RAN">
            <sqlCheck expectedResult="0">SELECT COUNT(*) FROM user WHERE login = 'developer'</sqlCheck>
        </preConditions>
        <insert tableName="user">
            <column name="id" value="1" />
            <column name="login" value="developer" />
            <column name="created" valueDate="2013-07-30T16:30:42" />
        </insert>
    </changeSet>
</databaseChangeLog>

Jelen esetben az történt, hogy az sqlCheck elem segítségével azt mondtuk, a fenti lekérdezés futtatásakor a várt érték a 0. Ha ezt az értéket kapjuk, a changeSet futtatásra kerül. Az sqlCheck mellett számos másik elemet is használhatunk, az and és or elemekkel pedig összetett kifejezésekké kombinálhatjuk őket.

Vegyünk észre még egy érdekességet: a preConditions elemnek megadhatjuk az onFail paraméter segítségével, hogy mi történjen, ha a feltétel nem teljesül. Jelen esetben azt mondtuk a MARK_RUN értékkel, hogy ha az előfeltétel nem teljesül, akkor hagyja ki a changeSet-et és jelölje meg futtatottként. Mondhattuk volna azt is, hogy a teljes changelog futtatását szakítsa meg (ez az alapértelmezett), de azt is, hogy ezúttal hagyja ki, de következő futtatásnál próbálja újra.

Környezet

Az előbb láttuk, hogyan írhatunk feltételtől függő change-t fejlesztéshez használt felhasználó létrehozására. De mi a helyzet abban az esetben, ha a feltételünk nem fogalmazható meg ilyen egyszerűen SQL utasítás formájában? Például hogyan tudnánk megoldani, hogy a fejlesztéshez használt felhasználónk csak a fejlesztői adatbázisokon jöjjön létre? Az ilyen helyzetek megoldására létezik a changeSet-ek context paramétere. Ennek segítségével minden changeSet-re külön beállíthatjuk, hogy milyen környezetben szeretnénk, ha lefutna. A changelog fájl futtatásakor pedig (akár parancssorosan, akár Java API-val futtatjuk) megadhatjuk, hogy milyen környezetben vagyunk éppen.

Példánknál maradva tehát, ha szeretnénk egy „development” nevű környzetet kialakítani, akkor changelog fájlunk a következőképpen alakul:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
>
    <changeSet author="botond" id="create_user_table">
        <createTable tableName="user">
            <column name="id" type="INTEGER"/>
            <column name="login" type="VARCHAR(255)"/>
            <column name="created" type="TIMESTAMP"/>
        </createTable>
    </changeSet>
    <changeSet author="botond" id="insert_developer_user" context="development">
        <preConditions onFail="MARK_RAN">
            <sqlCheck expectedResult="0">SELECT COUNT(*) FROM user WHERE login = 'developer'</sqlCheck>
        </preConditions>
        <insert tableName="user">
            <column name="id" value="1" />
            <column name="login" value="developer" />
            <column name="created" valueDate="2013-07-30T16:30:42" />
        </insert>
    </changeSet>
</databaseChangeLog>

A properties fájlunk pedig így néz ki:

# liquibase.properties

classpath:     lib/ojdbc14.jar
driver:        oracle.jdbc.OracleDriver
url:           jdbc:oracle:thin:@localhost:1521:XE
username:      user
password:      secret
changeLogFile: changelogMaster.xml
contexts:      development

Ha több környzetet is kialakítottunk, futtatáskor vesszővel elválasztva többet is felsorolhatunk. Amelyik changeSet-hez nem adtunk meg környzetet, az minden esetben le fog futni, aktuális környezettől függetlenül. Ha futtatásnál nem adtunk meg semmilyen környezetet, akkor minden changeSet lefut, context paraméterüktől függetlenül.

Adatbázisfüggetlenség

Korábban említettem, hogy a Liquibase adatbázisfüggetlen. Ez így nem teljesen igaz, valójában inkább csak annak tűnik, hiszen több mint 15 adatbázist támogat, többek között MySQL-t, Oracle-t, SQLite-ot, PostgreSQL-t stb. Éppen ez az egyik indok, amiért érdemes az XML formátumú changelog fájlt használni: a Liquibase az éppen használt adatbázis függvényében állítja össze a megfelelő konkrét SQL utasításokat. Így ugyanazt a changelog fájlt tudjuk használni még olyan extrém esetekben is, ha pl. az éles rendszer Oracle adatbázison, a fejlesztői rendszerek MySQL adatbázison, az integrációs tesztek pedig Derby-n futnak.

De nem veszítjük el ezt az adatbázisfüggetlenséget azáltal, hogy oszlopok létrehozásakor konkrét típusokat adunk meg? A válasz az, hogy sajnos de. Hiszen pl. Oracle esetén VARCHAR helyett VARCHAR2 használata javasolt, a PostgreSQL használ BOOLEAN típust, míg sok más adatbázis nem és így tovább. Ám erre a problémára is van megoldás.

A Liquibase a property elem használatával támogatja paraméterek dinamikus behelyettesítését. Ez a gyakorlatban azt jelenti, hogy a környezettől és/vagy adatbázistól függően deklarált property-re a changelog fájlban bárhol hivatkozhatunk a ${<property név>} szintaxissal, akár típusok megadásánál is. Tehát ha pl. Oracle-lel és Apache Derby-vel is kompatibilissé szeretnénk tenni korábbi changelog fájlunkat, akkor azt például a következőképpen tehetjük meg:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd"
>
    <property name="integer" dbms="oracle" value="NUMBER(38,0)" />
    <property name="integer" dbms="derby" value="BIGINT" />
    <property name="varchar" dbms="oracle" value="VARCHAR2" />
    <property name="varchar" dbms="derby" value="VARCHAR" />
    <changeSet author="botond" id="create_user_table">
        <createTable tableName="user">
            <column name="id" type="${integer}"/>
            <column name="login" type="${varchar}(255)"/>
            <column name="created" type="TIMESTAMP"/>
        </createTable>
    </changeSet>
    <changeSet author="botond" id="insert_developer_user" context="development">
        <preConditions onFail="MARK_RAN">
            <sqlCheck expectedResult="0">SELECT COUNT(*) FROM user WHERE login = 'developer'</sqlCheck>
        </preConditions>
        <insert tableName="user">
            <column name="id" value="1" />
            <column name="login" value="developer" />
            <column name="created" valueDate="2013-07-30T16:30:42" />
        </insert>
    </changeSet>
</databaseChangeLog>

Mi az, amit a Liquibase nem tud?

A fent leírtak még csak a jéghegy csúcsa: írhatnék még arról, hogy milyen hasznos, hogy a legtöbb changeSet adatbázison történő futtatás után is automatikusan visszavonható a rollback paranccsal. Vagy arról, hogy milyen egyszerű már meglévő adatbázist is Liquibase alapúvá tenni a generateChangeLog utasítással. Vagy hogy futtatáskor jelzi, ha valamelyik changeSet tartalma az utolsó futás óta megváltozott. De ezekre most nem térek ki, mert akinek sikerült felkelteni a figyelmét az eddigiekkel, az valószínűleg ezekre a funkciókra már hamar rá fog találni, ezért inkább rátérnék arra, hogy mik a Liquibase hiányosságai, hátrányai.

Hátránynak lehet esetleg tekinteni, hogy meg kell barátkozni a korábban említett két új tábla létezésével. Emellett ugye meg kell ismerkedni a Liquibase saját „nyelvével”. Ezen kívül más hátrány nálunk nem ütötte fel a fejét, ebből is látszik, hogy gyakorlatilag csak előnyökkel jár a használata.

Ami hiányosságot esetleg lehet említeni, az sem igazán komoly probléma: az XML szerkesztése általában lassúnak érződik. Hiába a megfelelő XSD és IDE használata, típusok értékét például így sem lehet automatikusan kiegészíteni, ráadásul gyakran nagyon hasonló utasításokat kell sokszor egymás után írni, és ilyenkor nagyon csábító a copy-paste használata, amivel könnyű apró hibákat bevezetni. Az itt leírtak lényegében mind visszavezethetőek egyetlen hiányosságra: a Liquibase-nek nincs grafikus felülete. Ez az, amit most megpróbálunk pótolni, ugyanis létrehoztunk egy NetBeans plugin-t, amivel kényelmesen, grafikus felület segítségével használhatjuk a leggyakoribb Liquibase funkciókat.

Liquiface

A Liquiface elnevezés úgy érezzük, jól kifejezi, hogy próbálunk „arcot adni” a Liquibase-nek. A projekt alapötlete pár éve született egy a Webstar Csoport-on belüli 24 órás FedEx nap nevet viselő programozási versenyen, később pedig belső önképzésként folytattuk (Takács Viktor, Marics Tamás és én, Adorján Botond). Az általunk megálmodott széles funkcionalitás sok részére azonban még így sem jutott idő. Szerencsére a cégvezetés is hasznosnak látta a projektet, ezért kaptunk a megvalósításra további erőforrásokat, így végül eljutottunk a most bemutatkozó 1.0-ás verzióig.

Mit tud a Liquiface?

Röviden megfogalmazva igyekszik kényelmi funkciókkal kiegészíteni a Liquibase eszköztárát. Ezt például azzal éri el, hogy a közvetlen XML szerkesztés helyett kényelmesen, varázslók által vezetve hozhatjuk létre a leggyakoribb Liquibase change típusokat. Ennek köszönhetően azok is könnyen megismerkedhetnek a Liquibase hasznosságával, akiknek nincs kedvük vagy idejük a szerkezetét megtanulni.

Új tábla létrehozása

Ennyinél azonban nem álltunk meg: hiszen nem csak az a fontos, hogy képesek legyünk elkészíteni egy Liquibase change-t, legalább annyira hasznos, ha rögtön látjuk is, hogy mit csináltunk. Ezért a Liquiface szimulálja nekünk az adatbázis struktúráját, megjelenítve benne minden táblát és kapcsolatot. Mivel adatbázisunk nagyra nőhet, ezért lehetőség van többfajta szűrésre és bizonyos megjelenítések kikapcsolására is.

Adatbázis megjelenítése Liquiface-en

Ha pedig készen vagyunk a szerkesztéssel, változtatásainkat elmenthetjük új fájlba vagy hozzáadhatjuk már létezőhöz. Emellett a NetBeans-ben definiált adatbáziskapcsolatok segítségével lehetőségünk van arra is, hogy rögtön adatbázison futtassuk a változásokat.

Changelog mentése

A most kiemelt funkciók csak a Liquiface által nyújtott könnyebbségek sarokkövei. Akit részletesebben érdekel, pontosan milyen egyéb képességekkel vérteztük fel, az tovább tájékozódhat a Liquiface használati útmutatóban vagy letöltheti a NetBeans portálról, és maga is kipróbálhatja.

Összefoglalás

Az adatbázisok verziókövetésének általános elveitől a Liquibase eszközön keresztül eljutottunk egészen a Liquiface plugin-ig. Én mindenkit arra biztatnék, aki még nem teszi, kezdje el verziókövetni az adatbázisok változásait is. Az is van olyan fontos, mint a kód, ne kezeljük mostohán! A bemutatott eszközök pedig erre egyszerű és gyors módot szolgáltatnak. Remélem, aki még nem találkozott velük, annak sikerült felkeltenem az érdeklődését! Aki pedig kipróbálja a Liquiface-t, attól azt kérném, segítse a munkánkat: mondja el nekünk véleményét, meglátásait, hogy olyan irányba folytathassuk a plugin fejlesztését, ami minden felhasználójának megelégedésére szolgál!

A bélyegképen Tony Sava fényképe látható.