Fejlesztői, tesztelési, éles fázisok munkamenete a Drupalban.

Úgy gondolom a webes fejlesztésben igazi áttörést jelent az a fajta szemlélet amit ez a cikk mutat be. Azt hiszem nem csak a Drupal fejlesztők vehetik hasznát a cikkben található ötleteknek, de ezt majd leírjátok úgy is. A cikk eredetije a DevelopmentSeed oldalán jelent meg Adrian Rossouw "tollából": http://developmentseed.org/blog/2009/jul/09/development-staging-producti... Néhány helyen igencsak meggyűlt a bajom a fordítással, ha valakinek van javaslata szívesem veszem azt is, ne tartsátok vissza magatokat.

Bárki aki már fejlesztett egy komplexebb Drupal oldalt megerősítheti a következőket: Amíg az oldal elindítása viszonylag egyszerű feladat ezzel szemben a folyamatos karbantartás már igencsak trükkös munka tud lenni éles működés esetén. A dolgot bonyolíthatja, ha több mint egy fejlesztő dolgozik a projekten és a fejlesztés során egyedi módszertan szerint járnak el.
A következő példa rávilágít a probléma lényegére és egy konkrét eseten keresztül mutatja be hogyan használd a Context, Features és Spaces modulokat amiket itt a Develpment Seednél fejlesztünk.

Egy oldal építése

Ez a történet arról szól hogyan kavarodik össze az oldal építése közben Zak, Sara és Ben. Ne aggódj, a végén megtalálják az instant megoldást. (Az eredeti szövegben a Kool-Aid szó szerepel: http://en.wikipedia.org/wiki/Kool-Aid ) Ez lesz a Features?

Zak (egy webfejlesztő) és Sara (egy dizájner) együtt építenek egy közösségi oldalt a kedvenc indiaifüggetlen művészüknek(hívjuk őt Bennek). Az eredeti projekttervük előírja, hogy legyen egy blog, egy fórum és egy képgaléria az oldalon. Mivel Zak tapasztalt Drupal fejlesztő a Drupal platformot választják a szájt alapjául. Beállítanak egy fejlesztői szervert, mely lehetővé teszi a közös munkát és eldöntik, hogy a változtatások kezelésére a Subversion rendszert fogják használni.

A szájt építéséhez a következőket teszik:

  1. Összeállítanak egy gyűjteményt a kiegészítő modulokból, mint pl. views, cck és számos kevéssé ismert egyéb modul.
  2. Megtervezik és elkészítenek egy speciális sminket a szájt részére.
  3. Elkészítetenek számos nézetet és tartalom típust, hogy az oldal tartalmait a Drupal felhasználói felületével lehessen kezelni.

Az első két lépés eredménye könnyedén betolható a subversion tárolóba. Ha elégedettek vele akkor egyszerűen csak publikálják a kódot a teszt rendszerre és az adatbázis mentést pedig betöltötik a teszt rendszer adatbázisba. Ezután adnak Bennek hozzáférést az oldalához, hogy ellenőrizhesse a munkájukat.
Ben számos hibát talál, amit Zak és Sara javítanak és újra publikálják azokat a teszt szájton.
Ezt a pár lépést ismételik néhányszor. Végül Ben boldog lesz, hisz az új oldala pár nap alatt elkészül a kód előállításától, az adatbázis feltöltésén át a nyilvános oldal megjelenítéséig.

Funkció hozzáadás és módosítás

Az oldal pár hét alatt élesedik és nagyszerűn működik is. Ben azonban szól Zaknak és Saranak, hogy módosítsanak pár dolgot az oldalon.

Az új követelmények a következőek:

  • Egy turné naptár hozzáadása, amiben meg lehet mutatni a turné időpontokat
  • Egy új szekció létrehozása ami az albumokról tartalmaz információkat
  • Új funkcionalitás hozzáadása a képgalériához. Ezek:
    • Minden felhasználó tölthessen fel képeket
    • Ezeket tudják azután koncertekhez csatolni

Nos az oldal most élesben működik és a felhasználók folyamatosan adják hozzá a tartalmat. Ahhoz, hogy a változtatásokat érvényre juttassák a következőket kell tenni:

  1. A teszt rendszerre egy az éles rendszerről származó adatbázis mentést kell tenni.
  2. Hozzá kell adni pár közösségi modult. Ezek a Node Reference és Data API modulok.
  3. Hozzá kell adni egy új tartalom típust amivel az album információkat kezelik majd.
  4. Módosítani kell a meglévő tartalom típusokat és hozzá kell adni azokhoz a plusz mezőket.
  5. Hozzá kell adni pár nézetet a naptár megjelenítéséhez.
  6. Az új oldal elemek miatt a sminket is módosítani kell.

A második és hatodik lépés eredményét a subversion tárolóba kell beküldeni, hisz ezek csak kód szinten jelentenek változást.
Amikor már elégedettek a változtatásaikkal, a kódot és az adatbázist felmásolják a teszt szerverre. Ben egyáltalán nem elégedett, mivel a teszt szerver nincs szinkronban teljesen az éles adatbázissal. A teszt szerver szerepe, hogy az éles környezetben lehessen kipróbálni az új funkciókat. Mivel az éles adatok folyamatosan bővülnek és a harmadik, negyedik és ötödik lépés változásai csak az adatbázisra vannak hatással ezért ezt a szerepet nem tudja maradéktalanul ellátni a tesztkörnyezet.
Zak kénytelen az éles rendszer utolsó mentését használni a fejlesztői rendszeren és minden változtatást kézzel újra megcsinálni rajta. Amikor elkészül újrarakja a tesztrendszert is. Ezután Ben még mindig elégedetlen néhány változtatással. Természetesen minden egyes jóváhagyott változtatás után meg kell ismételniük az egész folyamatot.
Amikor Ben elégedett a módosításokkal akkor az éles rendszert karbantartás üzemmódba kapcsolják, készítenek róla egy másolatot, megismétlik a változtatásokat a fejlesztői rendszer legutolsó állapotán, átvezetik a változtatásokat a teszt szerverre, csinálnak egy végső tesztet és végezetül lecserélik az éles oldalt. Mindenképpen karbantartás üzemmódba kell kapcsolniuk az éles rendszert, hogy megállítsák az éles rendszer adatainak folyamatos változását és egy stabil célállapotot tudjanak elérni a verzióváltáshoz.
Zak, Sara, és Ben véletlenül belefutnak abba - az egyébként részükről még átbeszéletlen – kérdésbe, ami a leggyakrabban előforduló probléma a Drupal fejlesztők körében manapság.

Hogyan oldják meg a fejlesztői → teszt → éles üzem munkamenet problémáját?

Drupal szájtot építeni egyszerűbb mint valaha. Ahogy a Drupal egyre többet tud, úgy lesz egyre könnyebb beállítani egy rendszert, mely nagyon kevés programozással képes megoldani a legtöbb problémát. A másik oldala ennek a nagyszerű dolognak, hogy egyre több és több beállítás kerül végül az adatbázisba. Mivel az adatbázis verzió követése ideálisan nem megoldható ez a művelet egy nagyon komplex problémává válik különösen akkor amikor az oldal éles állapotban működik.
Ideális fejlesztés esetén mindkét irányba szükségünk lesz az adatcserére. A tartalmakat el kell juttatni a teszt és a fejlesztői szerverhez, míg a beállításokat érvényre kell juttatni a teszt és az éles szerveren egyaránt.
A probléma megoldása, ha a beállításokat valahogyan a kódba juttatjuk. Sarát, a grafikust nem érinti a probléma, mivel az ő smink módosításai közvetlenül a subversion tárolóba kerülnek, de ezt az előbbi példán is megfigyelhetted.

Kód a következő előnyökkel rendelkezik:

  • Könnyen verzió követhetővé tehető
  • Tudsz benne hibát keresni (az eredeti angol: It can be debugged)
  • Tudod „diffelni”, összehasonlítani a különböző állapotokat. (Az eredeti angol: It can be „diffed”)
  • Az eredmény reprodukálható
  • A beállításokat és a tartalmakat szét tudjuk választani

Oké, de ehhez mi köze a context modulnak?

Az adatbázist jelenleg arra van használva, hogy tároljuk benne a beállításokat mindenfajta kontextus nélkül és azokat az adatokat melyek semmifajta jelentést nem hordoznak. Tulajdonképpen egy nagy fekete dobozba dobálunk bele minden fontos szerkezeti összetevőt. Ez nem teszi könnyűvé az információ kinyerését.
A probléma egy lehetséges megoldása, ha Zak engedélyezi a Context modult a fejlesztői rendszeren és az oldal funkcióit különálló részekre osztja. A példánkban például a következőkre: galéria, fórum és blog kontextusra. A Context modul egy eszköz amivel kinyerheted a beállításokat az adatbázisból. Az előbbi problémákra és számos másra is nagyon jól használható és erőteljes eszköz ez. Ráadásul az oldal tervezésénél is hasznát veszed, hisz egyfajta térképet ad a funkciók specifikálásához.

Most hogy Zaknek megvannak a kontextusai, miben tudja őt segíteni a Features modul?

A Feauters modul lehetővé teszi, hogy bármelyik ilyen kontextushoz amit meghatároztál létrehozz egy szabványos Drupal modult ami tartalmazza a szükséges dolgokat. A modul amit a Features generál egy szabványos Drupal modul lesz ami hozzáadja az adott funkcionalitást a rendszerhez. Ráadásul ezzel Drupal szinten tudod kezelni a verziókat, függőségeket és számos egyéb valóban átláthatatlan problémát ami a teszteléshez és a fejlesztés során adódik.
Miután kiexportálja ezeket a kontextusokat, Zaknek olyan Drupal moduljai lesznek, melyek teljes funkcionalitással valamint verziókezeléssel rendelkeznek. Minden egyes kontextushoz tartozik tehát egy modul, melyek segítségével könnyedén telepítheti és frissítheti a létező rendszerét ezekkel, természetesen hozzáadva a függőségek miatt szükséges modulokat is. Zak ezeket a változtatásokat beküldheti a subversion tárolójába. Mivel a beállítások modulok segítségével kerülnek átvezetésre a kód legutolsó verzióját tudja majd használni az éles adatbázis adataival együtt a teszt szerveren. Ezzel rengeteg időt spórol és lehetővé teszi, hogy könnyedén karbantartsa az oldalt amíg világ a világ miközben jobb szolgáltatást tud nyújtani a klienseinek.
Amennyiben szeretnél többet megtudni, hogy hogyan használd a Feature és Context modulokat a fejlesztői munkád támogatására, mindenképpen hallgasd meg Alex Barh BOF előadását a Drupalcon Párizs rendezvényen.

Hozzászólások

Nagy vagy PP! Köszi a postot és a fordítást, nekünk igen hasznos útmutató, küldöm is tovább a srácoknak a linket :)

Korrekt fordítás, köszönöm. Remélem hasonlóval találkozok még itt a blogodon ;)

A Kool-Aid szo sokkal tobbet takar egy egyszeru italnal
http://en.wikipedia.org/wiki/Drinking_the_Kool-Aid
http://www.urbandictionary.com/define.php?term=drink+the+kool-aid

gyakran hasznaljak olyan egyenekre akik mar belemerultek a Drupal vilagaba
http://www.lullabot.com/blog/lullabot-going-drupal-design-camp-boston-we...
"learning about Drupal or you've already drank the Kool-Aid"

megszallottsag, fanatizmus ami a Drupalosokra eleg jellemzo. Rakattansz, nem birod abbahagyni, minden egyeb webes eszkozt elutasitasz, es meg kozben mindenkit probalsz megfertozni. nem igy van?

de nem tudom hogyan forditanam az eredeti szoveget magyarra, hogy a mondat kozben ertheto is maradjon. ugyhogy szerintem jo igy..

Wow köszi!

Ez tényleg jónak tűnik, ki fogjuk próbálni - főnöki utasításra. De mi van a spaces-el. Az valahogy kimaradt.

A fordítás meg tök jó.

Azt én se tudom. Gondolkodtam rajta, hogy kihagyom a fordításból, de hát így kerek az egész. Mindhármat érdemes kipróbálni, de nekem azt javasolták inkább az OpenAtriummal érkezőt próbáljam ki mert az van maximálisra csiszolva. A don találhatónak vannak függősége és az OA-ban meg össze vanak csomagolva az összetartozó egyéb modul(cck, views stb.) verziókkal.

Sziasztok, a Kool-Aid kapcsán megkérdeztem az amerikai fejlesztőtársamat. Ő azt mondja, hogy a ezzel a kifejezéssel vicces, nem túl bántó formában szokták a dogmatikus, buta vagy gyermeki ösztönökkel bíró embereket illetni, ennek megfelelően a gyakori "don't drink the Kool-Aid" azt jelenti, hogy "ne halgass rájuk" vagy "ne higyj el mindent amit ők mondanak" (ennek megfelelően a "drank the Kool-Aid" kb. "megette a bolondgombát"). Különösen választások idején szoktak ezzel viccelni. Néha ezt használják a vallások, pl. a közös méreg útján elővezetett öngyilkosságot elkövető csoportokkal, vagy akár még a keresztény közösséggel kapcsolatban is.

Itt viszont egészen másról, a szó eredeti jelentéséről van szó: van egy népszerű TV hírdetés, amiben a Kool-Aid kabalafigurája bohóckodik a gyerekekkel, aminek a vége, hogy nevetnek és isznak egyet az italból. Vagyis a fordítás olyasmi lenne, kb. "Azért ne aggódj, a végén megkapják a bambit."

Nem mondom, hogy most már mindent kristálytisztán értek, de köszönet a fordításért!!

Régóta érdekel a téma, jó lenne még töbet tudni erről: pl. csinálhatna valaki egy-két előadást erről az idei, hazai Drupal Konferencián (mert az lesz, ugye)! ;o))

Köszönet mégegyszer!

talaltam egy typot az utolso elotti sorban :D
eredeti:
"munkád támogatására, mindenképpen hallgasd meg Alex Barh BOF előadását a Drupalcon Páris rendezvényen."
A Párizs-ból kimaradt a z.

Köszi, javítva. Persze mondhattam volna, hogy de hát ez a neve a rendezvénynek. ;)

pp

szép darab. gratula. sajna-bajna a features -nek nincs 6.x verziója egyátalán. :(

Én találtam hibát egy-két összetettebb mondat fordításában, de a mondanivaló nem torzult, szóval hagyjuk, inkább gratulálok, hogy összehoztad!

Csak egy dolgot hoznék fel, ha már a Kool-Aidet is kitárgyaltuk, mert vicces félreértés:
Az "indie artist" az nem indiai művész, az indie az independent rövidítése, és azok a rockzenészek tartoznak bele, akik azért nem szerződnek a nagy kiadókhoz, hogy minél jobban a saját kezükben tarthassák a karrierjük alakulását (http://hu.wikipedia.org/wiki/Indie_rock).

Egyébként nemrég olvastam az IBM egyik Drupallal foglalkozó fejlesztőjének a blogján (véletlenül akadtam rá, most nem is találom), hogy ők minden beállítást egy saját modul install fájljába írnak update függvénybe ágyazva. Ez olyasmi, mint az install profilok használata. Az update függvény ugyebár nem csak az adott modullal kapcsolatos dolgokat tudja változtatni, és az update.php segítségével még lépkedni is lehet a verziók között. Ez azt jelenti, hogy a megrendelőnek könnyedén bemutathatunk több változatot a böngészőt el sem hagyva. Csak persze macerás, de ez is egy alternatíva.

LOL, ezen nagyot kacagtam, jól félre lett ez fordítva akkor. ;)

Az IBM-es cikkhez meg annyit(én sem találtam), hogy mindenki így csinálja, de a Features az legyártja ezeket a modulokat. Éppen az benne a zseniális, hogy nem kell hozzá programoznod. Klikk-klikk-klikk és már kész is a modul ami update-el. Ez ugye az elméleti alap ez jelenleg csak bizonyos keretek között működik. Tessék letölteni és kipróbálni az OpenAtriumot!

pp

Új hozzászólás