Fejlesztés Drupal-ban

A fejlesztés röviden feature-ök (magyarul fícsőr) és saját modulok gyártásából és szerverekre való feltöltéséből áll. A dolog nagy előnye, hogy a megrendelőnek megmutathatjuk az új fejlesztéseket anélkül, hogy "élesíteni" kellene őket, illetve a megrendelő is egyfolyamatosan működő oldalt láthat (ez a stage).

A következő dolgokra lesz szükségünk:

  • Lokális fejlesztői környezet
  • Verziókezelő rendszer, ami a git
  • Verziókezelő szerver ami a lehet a Github vagy, ha sok időnk és kevés pénzünk van akkor a Gitlab.
  • Szerver, amin két virtuális domain van: stage és prod
  • ssh, drush elérés a szerveren, meg persze a localhoston.

A fejlesztést elkezdjük a helyi gépen, letöltünk egy Drupal-t, felinstalláljuk, esetleg letöltjük hozzá a kedvenc moduljainkat. Egyenlőre csak olyan modulok kerüljenek be, amiket az élesen is látni akarunk. Például a coder vagy a stage_file_proxy modulokat egyenlőre ne. Én a drupal.org-ról letöltött modulokat a sites/all/modules/contrib, a sajátokat a sites/all/modules/custom és a features-öket pedig a sites/all/modules/features könyvtárba szoktam pakolni. Szerencsére ezt nem én találtam ki, így a drush és a features modul is tud ezekről a dolgokról.

Egy adott pillanatban, amikor már úgy érezzük, hogy van egy működő alap site-unk, az egészet feltoljuk a git-be. A Github-on lehet zárt repókat is használni, viszont ez pénzbe kerül kb. projectenként $2 havonta. Használhatjuk a Gitlab-ot is, viszont azt fel kell tenni valahova, és persze nem tud annyit, mint a Github. Hogyan mehet ez az egész arról itt egy leírás. A stage-en kell csinálni egy clone-t. Ahhoz, hogy mindez automatán mehessen érdemes ssh kulcsokat generálni. A settings.php-t kivételesen kézzel kell szerkeszteni az adatbázis-kapcsolathoz.

Az adatbázis szinkronizálásához én létrehoztam egy 'aliases.drushrc.php' file-t a sites/all/drush könyvtárba.

<?php
  $aliases['dev'] = array(
  'root' => '/a/helyi/eleres/konyvtara,
); 
$aliases['stage'] = array(
  'root' => '/a/tavoli/eleres/konyvtara', 
  'remote-host' => 'ftp.szuperszerver.com',
  'path-aliases' => array(
     '%drush-script' => '/usr/local/bin/drus'
  )
);

Ekkor elméletileg egy drush sql-sync @dev @stage Kiszinkronizálja az adatbázist. A szerveren érdemes csinálni egy hasonlót @stage és @prod-al, hogy oda is tudjunk szinkronizálni, ott ugyanezeket a lépéseket kell megtenni, szintén egy adott pillanatban. Ezeket azért érdemes megcsinálni, mert elvileg folyamatosan fogunk szinkronizálni, csak éppen fordítva. Amíg csak a @stage van meg, akkor onnan, amikor pedig a prod is, akkor először a prod-ról a stage-re, majd onnan a dev-re (ami a local gép). De csak akkor, amikor már kész vannak a feature-eink. A file-ok szinkronizálásához a stage_file_proxy modult érdemes használni, de lehet folyamatosan rsync-elni is.

Az adatbázist tarthatjuk git-ben, erre is vannak eszközök, például a drush sql-dump, illetve a Drupal Git Backup Drush script. Ez utóbbival akár táblánként lehet lementeni az adatbázist. Persze az a jó, ha az egész site teljesen adatbázisfüggetlen tud lenni, tehát egy teljesen szűz drupal installal bekapcsolgatva a modulokat, sminket és a feature-öket ugyanazt a site-ot kapjuk, mint amit fejlesztettünk.

Fontos, hogy vannak dolgok, amik nem kompatibilisek a feature modullal, ilyenek például a blokkok. Ha lehet ilyeneket ne használjunk (blokkok helyett lehet használni a Panels everywhere-t). Ha változókat is be kell állítani arra ott a Strongarm modul. Viszont, ha már semmiképpen nem mennek a dolgok, akkor az egyes feature .module file-jaiba irogathatunk, vagy írhatunk nekik .install file-okat, amikben szinte korlátlanok a lehetőségek, persze mindezt megtehetjük saját modulokban is. Ilyenkor ne felejtsük lefuttatni az update.php-t.

Lakótelepen kinézel az ablakon, akkor Panels Everywhere

Tehát, ha megvagyunk egy feature-el, vagy egy meglévőn változtatunk, mentsük le a feature-t (a features modul automatikusan le tudja menteni a sites/all/modules/features könyvtárba, ez az advanced options részben van. Ezután git add, git commit, git push. Ha többen is dolgozunk rajta, akkor előtte egy git pull, de a rendszer szól, ha valami változás volt a szerveren. Ha megvolt a push, akkol a szerveren mehet egy git pull, és máris szépen működik minden. Elvileg. Szerintem jó lehet, ha a stage és a prod ugyanazon a szerveren van, így minimális lesz köztük a különbség tehát elég jól tudjuk tesztelni az oldalt. A stage-en mindig teszteljük kikapcsolt devel modullal is az oldalt, mert a prod-on már nem lehet bekapcsolva! Ha valamelyik feature-ünk különösen jól sikerült, azt meg is oszthatjuk a közösséggel.

Ha minden készen van, a saját megnyugtatásunkra készítsünk egy install profile-t ebben a drush generate-makefile lehet nagy segítségünkre. Írhatunk még hookokat, amik automatikusan lefutnak egy-egy pusholáskor (pld. automatikusan pull-oznak), de ez legyen a házi feladat :) Itt van hozzá egy leírás: https://help.github.com/articles/post-receive-hooks.

Összegezve, bár így kissé lassabbnak tűnik a fejlesztés, viszont nem kell mindent kétszer-háromszor beállítani vagy felülírni az élesen lévő tartalmakat, csak mert változtatunk valamit fejlesztés közben, ráadásul gyakorlatilag újra tudjuk generálni az egész oldalt.

Új hozzászólás

Plain text

  • A HTML jelölők használata nem megengedett.
  • A webcímek és email címek automatikusan kattintható hivatkozásokká alakulnak.
  • A sorokat és bekezdéseket a rendszer automatikusan felismeri.
By submitting this form, you accept the Mollom privacy policy.