Release: Az utolsó kritikus állomás

Mikor dőlhetünk hátra és élvezhetjük a megérdemelt munka gyümölcsét? Talán akkor, ha az alkalmazásunk adott verzióját kitettük az éles környezetbe? Talán. Nem árt azért meggyőződni arról, hogy ami a fejlesztői-tesztelői környezetekben jól működött, az az élesen is rendben megy. Úgy néz ki, vár még ránk egy utolsó ellenőrzés.

Számos szoftvertermék esetében, de különösen igaz a SaaS környezetre, internetes szolgáltatásokra, hogy a tesztelés, a QA szerepe nem ér véget a különböző “házi” tesztkörnyezetekben (fejlesztői, tesztelői, béta stb.) végrehajtott sikeres tesztekkel. Csak akkor tekinthetjük befejezettnek a folyamatot, és a release végére csak akkor tehetünk pontot,  ha meggyőződtünk arról, hogy az “éles” környezetben a felhasználókat kiszolgáló szerverek mindegyike megfelelően működik, mindenhol ugyanaz a tartalom és elvárt állapot van.

Hogy miért is olyan hangsúlyos lépés ez? A release-procedúra során több olyan kritikus pont is van, amely miatt a fejlesztői-tesztelői környezetekben, több lépcsőben elvégzett legalaposabb tesztelés ellenére is zátonyra futhatunk az utolsó szakaszban. Azonban nem feltétlenül termékhibák, kódolási hibák miatt, hiszen azoknak már a korábbi szakaszokban napvilágra kellett kerülniük, hanem sokkal inkább a kiszolgáló szerver és környezet viselkedése, vagy a rossz feltöltési stratégia okozhat kellemetlen pillanatokat.
Elég ha belegondolunk, hogy a join.me szolgáltatásért például négy adatközpontban (három tengerentúli és egy európai) mintegy 100 webszerver felel, és ugyanezen webszerverek más LogMeIn-termékeket is kiszolgálnak. A join.me szerviz maga (a marketing célú oldalak nélkül) pedig több mint ezer állományból áll, és közel 150 megabyte terjedelmű. 100 webszerveren meggyőződni arról, hogy minden tökéletesen működik, mindezt úgy, hogy a teljes deployment folyamatra kb. 2 óra áll rendelkezésre – első hallásra nagy kihívás, de mégsem olyan ördöngös dolog.

Folyamatos integráció

A sikeres feltöltés zálogának megtalálásához vissza kell ugranunk a fejlesztési-tesztelési folyamat elejére: a szoftverfejlesztési projektek egyik legnehezebb részét az teszi ki, hogy a már meglévő fejlesztéseket és az újonnan elkészülteket integráljuk.  Agilis fejlesztés esetén, aminek egyik jellemzője gyakran a nagyon gyors, néhány napos fejlesztési-tesztelési-release ciklus, a fejlesztési-tesztelési fázisban a Continuous Integration (CI) – azaz a folyamatos integráció – módszerét alkalmazva a fejlesztőcsapat tagjai az általuk írt kódot legalább napi rendszerességgel integrálják a korábbi fejlesztések közé, ez lényegében napi többszöri integrálást jelent.

Minden új kód integrálása során automatizált tesztek ellenőrzik, hogy a rendszerbe való illesztés során okozott-e valamilyen hibát az új kódrészlet, és ennek eredményeként a lehető leghamarabb visszajelzést ad az integráció eredményéről. A különböző szoftverfejlesztési modellekhez vagy egy konkrét termékhez való branching stratégiát, best practice-t nehéz egyértelműen meghatározni, de számos ehhez hasonló oldal és cikk segíti az eligazodást: http://msdn.microsoft.com/en-us/library/bb668955.aspx

A Continuous Integration folyamathoz számos szoftvereszköz áll rendelkezésre, esetünkben például a CruiseControl, mint CI szerver és a Perforce, mint verziókövető rendszer. A folyamatos buildelés és tesztelés azonnal megtörténik, amint változtatások kerülnek a verziókövető rendszerbe: alapszabály, hogy az elkülönülő, a különböző területeken, különböző új funkciókra, változtatásokra irányuló fejlesztések különböző Perforce branchekbe kerülnek, de valamennyi branch közös tulajdonsága, hogy a releaselt (nevezzük Live) állapottal folyamatosan frissítésre kerülnek.

Mindez a gyakorlatban annyit jelent, hogy minden egyes release-elt változtatás a termékben a release után azonnal visszakerül a termékhez tartozó fejlesztői branchekbe, biztosítva azok konzisztenciáját,  és a fejlesztők így mindig a legfrissebb állapotra dolgoznak. Egészen eddig a pontig a fejlesztés-tesztelés infrastruktúrája és menete jól automatizálható.

A release engineer feladatai

Gyakran előfordul azonban, hogy egy release-be több különböző feature branchben végzett fejlesztés is bekerül, és egy fájlt különböző branchek is érintenek. Arról, hogy ezek a release előtt egy vágányra fussanak, az esetleges konfliktusok feloldódjanak, valamint a tesztkörnyezetekben valóban az az állapot álljon elő, amit kiadni szándékozunk (azaz ne kerüljön bele kiadásra még nem kész egyéb fejlesztés, és ne is maradjon ki olyan, ami a release része), az automatizált CI eszközökön és folyamatokon túl egy release engineer gondoskodik. Az ő feladata, hogy az adott release-hez tartozó Perforce job, azaz a változtatásokat tartalmazó changelistek alapján előállítsa a tesztkörnyezetekben azt az állapotot, ami a környezetfüggő beállításoktól, konfigurációs fájloktól eltekintve megegyezik az éles környezetben található állapottal, valamint a release-elni kívánt változtatásokkal. Félkész vagy más, jövőbeni release tárgyát képező változtatásoknak itt már nincs helye.

A QA feladata, hogy az ezt követő tesztekkel bizonyítsa az integrálás sikerességét, a termék működőképességét. A release mérnök egyébként szándékosan a tesztelői csapat egy képzett tagja és nem fejlesztő, hiszen ezeknél a teendőknél a sikerhez szükség van minden olyan tulajdonságra, amit egy jó tesztelő magáénak tudhat.

A release engineer további feladata, hogy különféle eszközök (Perfoce makrók, fájl komparátorok, build gép) segítségével összeállítsa azt a fájlcsomagot, amit azután a release során a webszerverekre feltöltünk.

Miért is van erre szükség? Megtehetnénk ugyanis, hogy *.*, azaz a website teljes tartalmát másoljuk fel minden egyes alkalommal, de valóban szükséges ez, ha a fájloknak mindössze néhány százaléka változik?

Mit töltünk fel?

Érthető módon arra kell törekednünk, hogy azokat, és csakis azokat az állományokat töltsük fel a webszerverekre, amelyek valóban a tervezett release részei. Még ha az aktuális változtatás az összes fájl mindössze néhány százalékát érinti is, tapasztalatom szerint egy csapat egy-két hetes munkájának eredménye akár több tíz, akár száz megabyte lehet. Ez a ma már egyébként kicsinek tűnő szám mégis sok akkor, ha a feltöltést végző csapatnak egy másik földrészen lévő szerverekre kell eljuttatni a változtatásokat, valamint a szerverek közötti DFS-alapú fájlreplikáció munkáját is megkönnyítjük, ha kevesebb és kisebb csomaggal kell dolgoznia. Egyúttal ha kizárjuk azokat a komponenseket és fájlokat, amelyek nem érintettek a változások által, tovább csökkentjük az esetleges tévedések kockázatát (pl. valamilyen oknál fogva mégiscsak egy régebbi verzió kerülne feltöltésre egy olyan fájlból, ami egyébként nem része a release-nek).

Ugyancsak a relase engineernek kell figyelnie az olyan konfigurációs fájlokra, amelyek az éles és tesztkörnyezetben különböz(het)nek (ilyenek az adatbázis connection sztringek, debug kapcsolók), egy ilyen kavarodás ugyanis nagyon könnyen a szolgáltatás hibás működéséhez vagy leállásához vezethet.

Fontos – és jogos – elvárás, hogy a feltöltéseknek, website-frissítéseknek  – amelyek nem ritkán heti 2 alkalommal is történnek – egy 24/7 elvárt rendelkezésre állású szolgáltatás esetén a felhasználók felé transzparensnek kell lennie, nem tehetjük ki minden egyes alkalommal a “Karbantartás miatt a szolgáltatás szünetel” üzenetet. Több adatközpont, szerver esetén természetesen a load balancer segítségünkre van, hogy a forgalmat kizárjuk azokról a szerverekről, amelyeken éppen dolgozunk, azonban ilyenkor is számolnunk kell azzal, hogy azok a felhasználók, akik már az adott szerverre kerültek, egy ideig még ott is maradnak, és az egész folyamatból ők is csak a pozitív változásokat észlelhetik.

Feltöltés utáni feladatok

A csomag feltöltése utáni első lépésként a szerverek közötti fájlreplikáció ellenőrzésére a release engineer egy hash tesztet futtat, azaz egy alaposan tesztelt referenciaszerver tartalmával veti össze a frissített szerverek tartalmát: ezzel az egyszerű módszerrel könnyen kiderül, ha a fájlreplikációba hiba csúszott. A kézi és automatizált tesztek szintén a referenciaszerveren zajlanak, a hash-ellenőrzés, és a következőkben taglalt diagnosztikai oldalak a továbbiakban már elegendőek.

Természetesen a több tíz vagy akár száz webszerver tételes, egyenkénti végigtesztelése – főleg manuális módszerekkel – kivitelezhetetlen, mégis felelőtlenség lenne legyintenünk azzal, hogy ha egy szerver jó, a többi is biztosan az: már a fejlesztés során gondoskodnunk kell arról, hogy a kritikus beállítások, funkciók például diagnosztikai célú oldalak meghívásával ellenőrizhetőek legyenek.

Amint a feltöltés befejeződött, indulhatnak az automatizált tesztek, és néhány perc alatt az összes szerveren meghívva a diagnosztikai oldalakat képet kapunk arról, hogy minden lényeges dolog a helyén van-e. Ilyenkor derülhetnek ki olyan “apróságok”, hogy például 25 webszerverből mindössze egy nem úgy viselkedik, mint a többi, és application pool újraindítást igényel, mert a fájlreplikáció miatt egy fájl “később ért oda”, vagy a dll cache nem frissült. De éppen emiatt azon az egy szerveren egy kritikus funkció nem működik jól.

Hogy mit is tartalmazzon egy ilyen diagnosztikai oldal, nyilvánvalóan a termék és az alkalmazott technológiák ismeretében lehet meghatározni, de a környezeti és egyéb konfigurációs beállítások listázása, fontosabb funkciók legalább OK-NOT OK szintű meghívása mindenképpen hasznos. Egy kiragadott példaként említve a join.me website diagnosztikai oldala visszaadja sok egyéb mellett a letölthető join.me alkalmazás valódi verziószámát közvetlenül az msi és exe fájlokból kiolvasva , az adatbázis-kapcsolatokat, az egyéb site-okra és szolgáltatásokra való hivatkozások listáját, URL-jét, a lényeges IIS-beállításokat, ezáltal gyakorlatilag másodpercek alatt átlátjuk, minden lényeges a helyén van-e.

Összefoglalás

Végezetül szeretném hangsúlyozni, hogy a tesztelés szerepe és feladata, hogy az alkalmazott technikákban, eszközökben ne vakon megbízzon, hanem hatékony módon, de ellenőrizze azokat, és meggyőződjön a végeredményről. A fentiekben ismertetett néhány pont is azt mutatja, hogy ilyen esetekben a QA feladata is sokkal inkább a folyamatok felügyelete, mint konkrét terméktesztelés.

Szerző: Kukla László