Felhőbeli adatbázis tesztelése

Kezdjük ezzel, mert talán ez a legegyszerűbb, persze most már a többi sem lesz nehéz... A célunk itt az, hogy meggyőződjünk róla, hogy amelyik adatbázist elérjük a lokális alkalmazásból, azt használja a felhőben lévő alkalmazásunk is. Ehhez nem kell mást tennünk, mint elindítani a lokális alkalmazás kiszolgálását a "production" paraméterekkel:

php artisan serve --env=production

Ugye az .env.production fájlunk tartalmazza a felhőbeli adatbázis elérésének paramétereit, ezért kell így elindítani az alkalmazásunkat. Utána nyissuk meg a következő URL-t a böngészőben: http://127.0.0.1:8000/admin/posts

Előbb be kell jelentkeznünk az email: darthvader@deathstar.ds és jelszó: 4nak1n párossal. Sikeres bejelentkezés esetén kattintsunk rá a "Hello World"-ös blogbejegyzés címére. Írjuk át a Title mező értékét "Hello World 2"-re majd alul az "Update" gombra kattintsunk. Ennek hatására frissült a blogbejegyzés címe a felhőbeli adatbázisban. De ellenőrizzük ezt le a felhőbeli alkalmazásunkkal is: http://laravel-blog-azure-v2.azurewebsites.net/

A képen látható, be is kereteztem, hogy a felhőbeli alkalmazás webcímén már a Hello World 2 nevű blogbejegyzés látszódik, tehát egyértelműen kijelenthetjük, hogy működik az azonos, felhőbeli adatbázishoz való kapcsolódás.

Felhőbeli adatbázistábla bővítése és frissítése

Terveim szerint a következő blogbejegyzésemben lesz szó az adatbázis migrációról bővebben. Eddig is migráltunk már többször, ami annyit jelentett, hogy a projektünkben lévő, gyakorlatilag adatbázis tábla leíró PHP fájlok segítségével a rendszer egy parancs kiadása után létrehozta az adatbázisban is a táblákat úgy, hogy nekünk egyetlen SQL utasítást sem kellett írnunk. Most is ezt fogjuk tenni, de nem egy új táblát fogunk létrehozni, hanem egy meglévőt fogunk bővíteni egy új oszloppal: a posts adattáblát fogjuk bővíteni egy published mezővel. Írjuk be ezt a VSCode terminal-jába:

php artisan make:migration add_published_to_posts --table=posts

Ennek hatására létre fog jönni egy új fájl a database / migrations mappában. Az új fájl neve egy időbélyeggel fog kezdődni, azzal a dátummal és idővel, amikor létrehoztuk a fájlt, a fájlnév második része a kiadott parancsból adódik: add_published_to_posts.php. Azt már láttuk korábbi bejegyzésben, hogy ha Controller-t hoztunk létre ilyen utasítás segítségével, akkor az volt a "nyereségünk", hogy nem egy üres fájl jött létre, hanem a Controller sablonjának megfelelő PHP fájl, így kevesebbet kellett bele kódolnunk, kisebb volt az esély a hibázásra. Most is segít nekünk ez az utasítás, számos dolgot elhelyez ebbe az új fájlba, az egyik legfontosabb is, ami a kiadott parancs utolsó kapcsolójához tartozik, ez ugye az, hogy a posts adattáblához érkezik majd a módosításunk.

Nem fogok most belemenni a migrációs fájlok működésébe, de helyezzünk el egy utasítást a fájlban. Az up() metóduson belül (és nem a down() metóduson belül) a Schema::table utasításon belül fogjuk elhelyezni az új utasításunkat:

Schema::table('posts', function (Blueprint $table) {
  $table->boolean('published')->default(false);
});

Az itteni középső utasításról van szó. Ez annyit fog tenni, hogy a posts táblához hozzáad egy published nevű boolean típusú mezőt, aminek az alapértelmezett értékét false-ra állítja. A down() metóduson belül helyezzük el ezt:

Schema::table('posts', function (Blueprint $table) {
  $table->dropColumn('published');
});

A Laravel kódja szerencsére nagyon jól olvasható, így kivehető, hogy ez az utasítás majd kitörli ("eldobja") a published nevű mezőt a posts táblából.

Ezután következhet a migráció a felhőbeli adatbázisba:

php artisan migrate --env=production

Egy megerősítést kér, ahogy látjuk is ezen a képen, yes-szel kell válaszolni és utána végrehajtja a migrálást.

Ahhoz, hogy le tudjuk ellenőrizni, hogy ténylegesen megvalósult-e ez a migrálás, ismét az Azure Portal-hoz kell navigálnunk. A Portal-on belül válasszuk ki a "laravel-blog-azure-v2" webes alkalmazást. Kiválasztás után a bal oldali menüben a korábban is használt "Deployment Tools" szekcióban az "Advanced Tools" menüpontban a "Go -->" linkre való kattintás után újra elérkezünk az alkalmazásunk fejlesztési eszközöket felsoroló weboldalához. Indítsuk el az SSH-t a fenti menüpontra való kattintással. Ismét szükségünk lesz majd a MySQL felhasználónevünkre és a jelszavunkra, úgyhogy remélhetőleg mindenki elmentette ezt, hogy itt majd tudjuk használni:

mysql -u bossysausage3 -h server197968907.mysql.database.azure.com -P 3306 -p

Itt az én felhasználónevem (és szerver nevem) látszódik, ami után kérdezi a rendszer a jelszót is. Sikeres azonosítás után lekérdezhetjük az érintett (bővített) posts adattábla szerkezetét és azt várjuk, hogy a published mező benne legyen.

DESCRIBE laravel_blog_db.posts;

Az eredmény:

Látható a published mező az utolsó sorban a mezők felsorolásában. Ez tehát működik. Örülünk.

Üzleti logika, nézet frissítése

Célul tűzhetjük ki ennek kapcsán, hogy csak az a blogbejegyzés jelenjen meg a főoldalon, amelynek a "published" mezője true-ra van állítva. Jelenleg ugye alapértelmezetten minden érték a published mezőben false és csak egy darab blogbejegyzésünk van az alkalmazásban ("Hello World 2" névre hallgat ez). Mire van szükségünk a változtatások érvényre juttatásához? Megjegyzés: mivel a mostani blogbejegyzésnek nem az a célja, hogy bonyolultabb üzleti logikát vagy nézeteket programozzunk, ezért itt csak felsorolom, hogy miket kellene leprogramozni a helyes működés megvalósításához, de itt most ténylegesen nem csinálom meg őket.

1. A blogbejegyzés létrehozási és szerkesztési oldalán is el kell helyeznünk egy checkbox-ot, amelyet ha kipipálunk és mentünk / frissítünk, akkor blogbejegyzés published mezője legyen a true, ha nem pipálunk ki és mentjük, akkor legyen false.
2. A Post model fájlban a $fillable tömbhöz hozzá kell adni a 'published' mezőt.
3. Az Admin/PostController fájlban a létrehozáshoz (store) és a frissítéshez (update) hozzá kell adni az űrlapon keresztül megkapott published mező értékét és így elmentésre kerül az adatbázisban.
4. A kezdőoldalon kilistázott Post gyűjteményt szűkíteni kell aszerint, hogy csak a published true értékű adatsorokat listázza ki az adatbázisból. És ennyi... ezeket kellene leprogramozni a helyes működéshez.

Most viszont mi "csak" arra törekszünk, hogy ha van legalább egy megváltozott fájlunk a legutóbbi git push óta, akkor azt a lokális helyről feltöltsük a felhőbe. Viszont sajnos az új migrációs fájlunk, amit itt létrehoztunk, annyira nem látható (semmilyen) eredményt produkál a weboldal kinézetében, így módosítsunk még egy fájlt: resources / views / layoutes / app.blade.php -t nyissuk meg és 23. sorba, amelyben a container osztályú div van, írjunk oda valamilyen tetszőleges szöveget a sor végére, én ezt írom oda: "Gludovátz Attila tesztel...", az eredmény pedig lokálisan (127.0.0.1:8000) itt látható a böngészőben:

A célunk most az, hogy ez a nézetbeli aprócska módosítás felhőbeli alkalmazásnál is ugyanúgy jelenjen meg.

Két megváltozott fájlunk van most már, ezeket szeretnénk szinkronizálni Git segítségével. Az utasítások, amelyeket végre kell hajtanunk a VSCode terminal segítégével, a következők (a commit szövege természetesen abszolút lehet más, mint nálam... illetve figyeljünk arra, hogy melyik branch-en vagyunk: én a master-en voltam, így a 3. utasításba azt írtam bele):

1. git add .
2. git commit -m "Test commit (new migration file, updated row in layout view)"
3. git push azure master

Legutóbbi utasítás hatására végrehajtódik a módosítások szinkronizálása a felhőbeli git repository-ba.

A felhőbeli webes alkalmazás pedig valóban frissült, amit a böngészőben ellenőrizhetünk is:

Ezzel a blogbejegyzéssel most egy kicsit lezárjuk a felhőbeli munkánkat, és majd ismét lokálisan folytatjuk, legelőször ahogy említettem a migrációs fájlok témakörét fogom ismertetni. Persze, aki továbbra is szeretne a felhőben dolgozni a blogbejegyzéseim nyomán, az abszolút megteheti ezt, ingyenesen is.