KonstantinuszKft. 2011
1 Tartalomjegyzék 1 Tartalomjegyzék... 2 2 Bevezetés... 3 3 A fejlesztés, tesztkörnyezet kialakítása... 4 3.1 Verzió követés... 5 4 Új verzió tesztelése... 6 5 Frissítés... 7 5.1 Adat szerkezet módosítás... 7 5.2 Adat konverzió... 8 5.3 Hibás frissítés... 9 6 Oktatás... 10 2 / 10
2 Bevezetés Az esettanulmányban a szoftver frissítés olyan példákon keresztül ismertetem amelyekben az adatbázis és maga a működő program elkülöníthető, akár hardware tekintetében is másik gépen fut, vagy ennek a lehetősége megvan. Találkoztam olyan programokkal ahol az adatok csak nehézkesen választhatóak el magától a programtól. Ezen programok frissítése még nehezebb, hiszen figyelni kell, hogy a frissítés ne írja felül az adatokat tartalmazó fájlokat. Ilyen szoftvereknél nem lehet az új verzió minden fájljával felül írni a régieket, hiszen az új verzió tartalmazza az üres adatbázis fájlt. Nem csak a frissítések esetén hanem a szoftverfejlesztés során is fontosnak tartom megfelelő tesztkörnyezet kialakítását. Jó tesztkörnyezettel megelőzhetjük azt hogy frissítés után még több időt kelljen eltölteni azzal, hogy a programot tovább lehessen használni. Amikor egy szoftver új verzióját vezetjük be valahova minig körültekintően kell eljárni. Az esetek többségében, általában csak kissebb változás történik ami nem érinti az adat szerkezetet. Ekkor viszonylag egyszerű a dolog feltelepítjük az új programot az ugyanúgy csatlakozik az adatbázishoz. A frissítés után minden működik tovább. Ilyenkor akár az is megengedhető, hogy frissített és nem frissített kliensek egyszerre használják a rendszert Amikor azonban a rendszer adatszerkezetében jelentős változás van, vagy jelentős működésbeli eltérés van akkor közel sem ilyen egyszerű a frissítés. Ilyenkor adatkonverzióra is szükség van vagy valamilyen módon meg kell oldani, hogy a régi adatok használhatóak legyenek. Erre is természetesen több megoldás létezik. 3 / 10
3 A fejlesztés, tesztkörnyezet kialakítása Ahhoz, hogy a későbbiekben könnyű legyen a szoftver frissítés ahhoz, már a fejlesztés elején célszerű bizonyos lépéseket megtenni. Más lépéseket kell megtenni a különböző programozási nyelveken. Amikor elkezdjük egy rendszer fejlesztését az első kódsorokat általában nem oda készítjük ahol majd futni fog, ez bizonyos nyelvek esetén eleve kizárt. Ha fordító programos nyelvben (pl.:c++, JAVA, stb.) készítünk rendszert akkor nyilvánvalóan nem azon a gépen fogjuk futtatni ahol a fejlesztést végezzük. Az interpreteres nyelvek (pl.: PHP) esetében ezt megtehetnénk, azonban nem javasolt. Mindenképpen javaslom teszt környezet kialakítását, ez mindenképpen hardware szinten különüljön el az élesben működtetett rendszertől. Ahhoz, hogy teszt rendszer valóban elérje rendeltetését olyanra kell kialakítani mint amilyen környezetben az élő rendszert fogjuk üzemeltetni. Mikor jó egy teszt környezet? Közel azonos hardware (Ha nem is pont azonos de a generációja legyen azonos, különben nem derül ki ha a programnak túl nagy lett a processzor igénye). Azonos operációs rendszer (32bites vagy 64bites, service pack). Azonos hálózati kapcsolat (Ha az éles rendszerben valamiért például WIFI kapcsolatot használunk akkor a teszt környezetben is legyen ilyen lehetőség) Megjelenítésre használt monitor (itt olyan problémák lehetnek, hogy kisebb felbontásnál nem fér ki a táblázat, vagy ha nagyobb felbontásban használják nem olvashatóak a betűk) Csak olyan szolgáltatások fussanak ami az élő rendszeren is futni fog. Találkoztam olyan esettel, amikor a rendszert olyan környezetbe telepítették ahol két magos processzorral rendelkező számítógépek voltak. Előtte a programot azonban csak egy magos környezetben tesztelték. Két magos környezetben a szoftver és az adatbázis között 30 másodperces késleltetés volt. Ez azt jelentette, hogy minden lekérdezés, adatfelvitel minimum 30 másodpercig tartott. Ez gyakorlatilag használhatatlanná tette a rendszert. 4 / 10
3.1 Verzió követés Verzió követés nincs szoros összefüggésben a frissítéssel, azonban megkönnyítheti a dolgunkat. Illetve megkönnyítheti a csapatmunkát is, és nyomon tudjuk követni, hogy mi változott két verzió között. Itt több féle megoldás létezik, vagy használunk mi magunk valamiféle verziókövető rendszert (pl.: CVS, SVN), vagy egyszerűen időnként egy külön könyvtárba átmásoljuk a teljes rendszert. Utóbbi esetben sajnos emberi hiba léphet fel ha elfelejtjük, vagy véletlenül felülírunk olyan korábbi verziót amit nem akartunk felülírni. Akár azt a megoldást is követhetjük, hogy jegyzeteljük, hogy milyen változásokat csináltunk meg és ehhez mely forrás fileokat módosítottuk. Ez természetesen könnyebb verzió követő rendszerrel, és lecsökken az emberi hiba okozta probléma lehetősége. A gyakorlatban a régi verziók megőrzése későbbiekben nagy hasznunkra lehet. Ha a rendszert egy vagy két éve használjuk és szemetet találunk az adatbázisban, akkor célszerű meghatározni, hogy csak a régi verziókban keletkezhetett vagy az új verzióban is keletkezik. Ha megtaláljuk egy régebbi verzióban azt a kódot ami miatt a szemét keletkezett, akkor készíthetünk vagy kiegészíthetjük a meglévő szemét gyűjtögető algoritmusunkat, hogy kiszűrje a jövőben. 5 / 10
4 Új verzió tesztelése Amikor elkészültünk egy új verzióval akkor hozzáfoghatunk a teszteléséhez. Ha hibát észlelünk akkor ne végezzük el a frissítést. A tesztelést célszerű, ha nem azok végzik akik a rendszert programozták, hanem vagy külön tesztelőket megkérünk erre, vagy az ügyféllel teszteltetjük. Az ügyféllel való tesztelés azért lehet problémás, mert egy összetett rendszert tesztelni a vezető nem ér rá, aki használni fogja az alkalmazott és nem érdekli, olyan szinten, hogy biztosan megtalálja a problémákat. Ez a fajta tesztelés ezért problémás, és általában nem éri el a célját. Célszerű minden funkciót végig tesztelni mert hiába nem módosítottunk egy funkción attól, még lehet, hogy ahonnan az adatokat kapja, az megváltozott és nem jó adatot vagy megfelelő formában kap. Amikor tesztelünk egy rendszert, akkor figyeljünk arra oda, hogy milyen adatok vannak a teszt rendszerben. Célszerű a teszt rendszerbe az élőből az adatokat átmásolni és úgy is tesztelni. Találkoztam olyan problémával, hogy az új verzió a teszten működött, a frissítés után pedig az éles rendszer lassú lett és meg is kellett állítani. A probléma az volt, hogy a teszt rendszerben 100-120 ügyfél adat volt. Az élő rendszerben viszont 2 000 000 ügyfél adata volt. Az egyik lekérés pedig egy rekurziót tartalmazott, ami az összes ügyfelet bejárta volna, és ezt az éles rendszer hardware-e nem bírta és a felénél megszakadt, ettől adatvesztés is történt. Ha az új verzió telepítése sikeres volt és az új verzió működőképes, akkor kell meghatározni az élő rendszer frissítésének idejét. Ehhez esetenként az ügyféllel is kell egyeztetni, hogy addig ne használják, vagy esetleg ki kell menni helyszínre, ami nagyobb szervezést is igényelhet. 6 / 10
5 Frissítés Alapvetően mire a frissítésre kerül sor a tesztkörnyezeten már mindent kipróbáltunk, lehetőleg a teljes frissítési folyamatot. Arra azért figyeljünk, hogy hány gépen kell elvégezni a frissítést, és ez alapján becsüljük meg, hogy mennyi ideig nem lesz használható a szoftver. A cégek gazdasági érdekei miatt nem engedhetik meg magunknak, hogy 1 vagy 2 napra rendszerfrissítés miatt bezárjanak, ezért általában ezeket a munkákat hétvégén kell elvégeznünk. Frissítés után az élő rendszeren is végezzünk el egy apró tesztelést, ilyenkor nem kell minden részletre kitérni, de célszerű meggyőződni arról, hogy rendben sikerült a frissítés. Ha nem sikerül a frissítés mert az éles környezet valamiért annyira más (vírus, azóta telepítettek valamit) akkor célszerű lehet biztonsági mentésből vissza állítani az előző verziót, és elhalasztani a frissítést. Ez persze csak végső megoldás. Találkoztam olyan megoldással, ahol a szoftverkészítő minden évben új verziót ad ki, ami gyökeresen eltér az előzőtől. Azért, hogy ne kelljen frissítéssel és adatkonverzióval bajlódni egyszerűen az új verzió egy teljesen másik szoftver. Vagyis a 2008 as évre van egy külön programja és a 2009es évre is van egy külön programja az ügyfélnek. Ez elsőre jó megoldásnak tűnhet, a probléma azonban az, hogy semmilyen adatmozgatást nem végez a két rendszer között, ezért az alapadatokat, pl.: termékek újra fel kell vinni a rendszerbe. Ez több száz vagy ezer termék esetén problémás lehet. 5.1 Adat szerkezet módosítás Előfordul, hogy a frissítés során az adatbázisba új mezőt kell felvennünk. Ilyenkor célszerű összeállítani egy szkriptet ami hozzáadja vagy eltávolítja a megfelelő oszlopokat a rendszerből. Ilyen esetben meg kell akadályozni, hogy valaki a szoftver régi verziójával csatlakozzon az adatbázishoz mert ez beláthatatlan következményekkel járhat. A fejlesztés folyamán kell megteremteni annak feltételét, hogy a program meg tudja kérdezni mi a legújabb verzió, és ez alapján dönteni tudjon, hogy elindulhat-e vagy sem. Amennyiben lehetséges akkor automatikusan frissülhet is. Nagy szoftvergyártók ezt szokták alkalmazni, olyan esetekben amikor a szoftver használói sokan vannak. Automatikus és kötelező frissítéssel az alábbi szoftvertípusoknál találkozhatunk: 7 / 10
Üzenet küldő kliensek (MSN, Skype) Online játékok Vállalat irányítási rendszerek (jellemzően csak adott cégen belül) Ezekben mind az a közös, hogy új verziónál változhat az kommunikáció módja (melyik porton történik, új titkosítást alkalmaznak, stb.), vagy új üzenetek érkezhetnek a központtól, vagy a kliensek új verzióitól. Ha megengednék, hogy régebbi verzióval is csatlakozni lehessen az akár a központi szerver(ek) leállását is okozhatja. Mint minden esetben itt is fontos, hogy készítsünk biztonsági mentést, hogy probléma esetén vissza tudjuk állítani az eredeti állapotot. 5.2 Adat konverzió Ez általában akkor szükséges ha sok szerkezeti átalakítás történt a rendszerben és a régi adatok kellenek csak teljesen más rendszer szerint. Tipikus példa erre, hogy eredetileg volt ügyfél ami egy cég egy kapcsolat tartóval, utána azt kérik, hogy végtelen számú kapcsolat tartó tartozhasson hozzá. Ez esetben a jelenlegi táblákban szereplő adatok egy részét, át kell helyezni új táblába ahonnan a rendszer használja. Itt mindenképpen vegyük figyelembe, hogy különböző adatmennyiség esetén mennyi ideig tart a konverzió, ez bizonyos esetekben több percbe vagy akár órákba telhet. Konverzió esetén problémát jelenthet, ha eddig nem megfelelő adatokkal töltötték ki a rendszert és így a mostani átalakításnál a konverzió közben olyan adatokat kéne elmenteni amik nem lehetségesek. Ennek egyik formája, hogy egy webshop vásárlónak volt megszólítása, neve, címe. Az új verzióban maradnak ezek a tulajdonságok de kikötjük, hogy a megszólítás innentől választható a Dr. és P.H.D. közül. Ilyenkor szokott kiderülni, hogy sokan a megszólításba beírták a teljes nevüket, a név mezőt pedig nem töltötték ki, vagy csak a kereszt nevüket írták be. Ekkor ha konverzió során egyszerűen üresnek vesszük azt ahol nem Dr. vagy P.H.D. van, akkor lehet, hogy elveszítjük néhány embernél a név értékét, vagy csak a kereszt neve lesz meg. 8 / 10
5.3 Hibás frissítés A hibás frissítés alatt több dolgot lehet érteni. A program új verziójának van valami hibája Az új verzió jó, de valami hiba miatt (a célgépen futó egyéb programok miatt) működés képtelen Valamelyik adatkonverziós script nem futott le vagy futott végig. Ezzel a problémával leggyakrabban automatikus frissítéseknél szembesülhetünk. Ha manuálisan frissítjük a szoftvert, akkor mivel utána le is teszteljük ezért ott hamarabb rájöhetünk ha gond van és akár el is halaszthatjuk a frissítést. A legnagyobb probléma, ha olyan hibát tartalmaz a frissítés ami meggátolja a további automatikus frissítéseket, és ezáltal manuálisan kell az új verziót telepíteni. Ez rengeteg, plusz munkát, időt és energiát igényel. Ha nem kell helyszínre kimenni akkor is lefoglalhatnak minket az ügyfelek akik telefonálnak, hogy nem megy a rendszer. Az, hogy egy frissítés valamilyen szempontból hibás viszonylag gyakori jelenség, még a legnagyobb szoftvergyártókkal is előfordul, hogy az új verzió összeakad egy programmal, vagy megnő a memória igénye és a régebbi gépeken nem fut. 9 / 10
6 Oktatás Ha az új verzió új funkciókat tartalmaz, akkor azokat általában valamilyen módon le kell oktatni a felhasználóknak. A frissítéssel egyidőben a felhasználói kézikönyv új verzióját is el kell készítenünk és eljuttatni a felhasználóhoz. Az is előfordulhat, hogy valamelyik folyamat rögzítésének a módja megváltozik. Ez esetben is ismertetni kell a felhasználókkal, hogy hogyan tudják használni az új verziót. Vállalat irányítási rendszer esetében nem, azonban online játékok, böngészők, esetében szokás úgynevezett béta verziókat kiadni amelyen a felhasználó megtanulhatja az új funkicókat (illetve tesztelheti a rendszert). Így elkerülhető, hogy a ritkán használt, de fontos funkciók hibáival vagy változásaival akkor találkozzon a felhasználó amikor tényleg szükséges lenne. Az alábbi helyzetben nagy gondot okozhat ha csak a kézikönyvben szerepel a változás: Vállalat irányítási rendszerben minden ki lehet tiltani egy felhasználót végleg, hogy ne tudjon vásárolni. Ha az új verzióban ez a gomb olyan helyre kerül, ahol régen más gomb volt a felhasználó véletlenül megnyomhatja. Ha nem rögzül benne még mielőtt az új verziót használná, akkor jó eséllyel az élő rendszerben is hibázni fog ami a cégnél kiesést okozhat, vagy az ügyfelének az elvesztését. 10 / 10