Egy vállalat, szervezet, vállalkozás a legnagyobb figyelmet mindig az aktuális adatainak elérésére, felhasználására és biztonságára fordítja. Ezeket az aktuális adatokat tartalmazó informatikai környezetet éles környezetnek, az adatokat pedig éles adatoknak nevezzük. Az éles környezeten azonban számos esetben változtatásokat kényszerülünk elvégezni, ilyen lehet egy új funkció bevezetése, egy funkció tesztelése, az alkalmazásszoftver vagy adatbáziskezelő újabb verziójának kipróbálása. Ezeket a folyamatokat az éles környezet egy másolatán célszerű elsőként megtenni és kipróbálni, hogy az éles, napi működést ne befolyásoljuk. Az éles környezetről készített másolatokat fejlesztői környezeteknek vagy tesztkörnyezeteknek nevezzük. Ezeken a környezeteken végezzük el az új funkciók fejlesztését, tesztelését, a szoftver vagy adatbáziskezelő verzióváltását, azaz valamennyi változtatást, amelyet az éles rendszeren való alkalmazás előtt ki szeretnénk próbálni. Fejlesztői és tesztkörnyezetből többet is készíthetünk hardver erőforrásainktól, szoftverlicenszeinktől függően. Ha ezek megengedik, más környezeteket is kialakíthatunk, akár önálló oktatási vagy integrációs környezetet. A továbbiakban a tesztkörnyezet szót fogom használni az éles környezet másolásával kialakított környezetre. Azt vizsgáljuk, hogy milyen tervezési előrelátással kell azt az informatikai infrastruktúrát kialakítani, amellyel a későbbiekben zökkenőmentesen tudunk tesztkörnyezetet kialakítani, üzemeltetni és használni.
Alapvető szabály, hogy mindig legyen legalább egy olyan környezet, amely a lehető legjobban hasonlít az éles környezetre. Értjük ezalatt, hogy az éles környezettel megegyező hardver elemekből épüljön fel, azonos erőforrások (memória, processzor, háttértár) álljanak rendelkezésre, az éles környezettel azonos alkalmazásokkal és adatokkal rendelkezzen, valamint az éles környezettel azonos módon legyen összekötve más kapcsolódó rendszerek tesztkörnyezeteivel. Ezek azért fontosak, hogy amikor az új vagy megváltozott funkciót teszteljük, akkor az éles környezettel megfelelő környezetben tesztelhessünk, mérni tudjuk az új vagy megváltozott funkció sebességét, figyelni és ellenőrizni tudjuk adataink mozgását más rendszerek felé és felől.
A fentiekből adódóan az informatikai infrastruktúra kialakításakor nem egy-egy környezet tesztkörnyezetéről érdemes beszélni, hanem szinteket, sávokat vagy síkokat érdemes létrehozni. Egy ilyen síkba tartozik valamennyi azonos funkciójú fejlesztői környezet, egy másik ilyen síkba tartozik valamennyi azonos funkciójú tesztkörnyezet, de egy ilyen síkot hozhatunk létre az éles környezetek számára is. Technológia szempontból ezeket a síkokat nevezhetjük vlan-oknak vagy olyan hálózatilag szeparált, elhatárolt alhálózatoknak, amelyekben az egyes környezetek csak saját síkjukon belül tudnak kommunikálni. Ezt az elhatárolást hálózati eszközök vagy szoftveres tűzfalak segítségével tudjuk biztosítani. Nem nehéz belátni, hogy legnagyobb előnye az éles és tesztkörnyezet elszeparálásából adódik. Nagyon fontos biztosítani azt, hogy egy tesztkörnyezet ne tudjon módosítani egy éles környezetet. Hiába marad egy frissen másolt tesztkörnyezet konfigurációjában egy kapcsolódó környezet éles elérése, a hardveres vagy szoftveres tűzfalszabály miatt a megmaradt hibás kapcsolat nem lesz működőképes.
De ha elszeparáljuk az éles környezetet a tesztkörnyezettől, akkor hogyan tudjuk az éles környezetről a tesztkörnyezetre másolni a szoftverkomponenseket és az adatokat, azaz hogyan tudjuk frissíteni a tesztkörnyezetet? Ezzel a feladattal már az infrastruktúra tervezésekor is számolni kell. A mai modern háttértárakkal már képesek vagyunk pár parancs kiadásával egy lemezterületet lemásolni egy másik lemezterületre, egy felhasználónak adott szerverek között ideiglenesen kinyithatjuk a tűzfalat a másolás idejére, vagy elkészíthetjük a tesztkörnyezetünket az éles környezet egy korábbi mentéséből is.
Az adott környezet szoftveres megoldásától függően előfordulhat, hogy az éles környezet másolásakor a kapcsolódó környezetek kapcsolatleírói (szerver neve, felhasználónév és jelszó) is másolásra került, így a tesztkörnyezet létrehozása után ezeket meg kell változtatni, hogy a kapcsolódó rendszer megfelelő síkban lévő környezetére mutasson. Erre és a későbbiekben felsorolt változtatásokra érdemes valamilyen scriptet, batchprogramot írni, hogy minden alkalommal minden változtatást elvégezzünk, illetve csökkentsük a változtatásokhoz szükséges időt és hibázási lehetőséget. Egy-egy ilyen scriptet felhasználhatunk több sík esetében is.
Az előző bekezdésben a külső kapcsolatokról beszéltem, de környezeten belül is számos olyan pont lehet, amelyen változtatásokat kell elvégezni a másolás után. Az éles környezetben használt technikai felhasználók jelszavait le kell cserélni, hogy azokat a fejlesztőknek, tesztelőknek ki tudjuk adni. Számos szoftver lehetőséget ad arra, hogy a végfelhasználó felületén fel tudjuk tüntetni, hogy az adott környezet éles vagy tesztkörnyezet, esetleg különböző színsémával tudjuk jelölni, ezeket is meg kell változtatnunk. Amennyiben a szoftver konfigurációjában fájlelérési útvonal szerepel, annak változtatásáról is gondoskodni kell.
Teszteléskor valószínű, hogy több funkciót fog egy tesztelő, rendszerszervező tesztelni, kipróbálni és így olyan jogosultságokra is szüksége lehet, amelyekkel az éles környezeten nem rendelkezett. Azonban ne adjunk meg több jogosultságot, mint amennyire feltétlenül szüksége van, illetve győződjünk meg arról, hogy az új jogosultsággal elért adatokhoz hozzáférhet-e, azok tudomására juthatnak-e. Ez különösen igaz lehet olyan esetben, amikor a fejlesztést egy külső szakértő végzi, akinek semmilyen jogosultsága sincs az éles környezethez és az abban tárolt adatokhoz. Emiatt érdemes bizonyos fejlesztői és tesztkörnyezeteken deperszonalizációt végrehajtani. Ez azt jelenti, hogy a személyes és kényes adatokat a fejlesztői és tesztkörnyezetben megváltoztatjuk, így például a személyek neveit, cégek elnevezéseit és adataikat. De mindig tartsuk szem előtt, hogy a tesztelésünk során a tesztadatok tükrözzék az éles adatok mennyiségét, eloszlását, jellemzőit, és hogy a megváltoztatott adatokkal tudjuk tesztelni az adott szoftverfunkciót.
Vállalatirányítási szoftver esetében, így például Oracle e-Business Suite esetében is, a másolás utáni beállítások, valamint a deperszonalizáció nagyon komplex feladat is lehet a szoftver moduljainak számossága és összefüggései miatt. Deperszonalizáció esetében ismerni kell az összes modult, a modulok felépítését, így tudjuk garantálni a deperszonalizáció után is az adatintegritást.
A fenti változtatásokra – ahogy korábban említettem - érdemes scriptet, batchprogramot, vagy legalább egy írásos forgatókönyvet készíteni, amelyet rendszeresen aktualizálunk.
Végül tekintsük át környezetünk technikai és funkcionális folyamatait. Amennyiben olyan folyamatunk van, amelyet a tesztkörnyezeten nem használunk vagy nem szabad használnunk, akkor konfiguráljuk át vagy kapcsoljuk ki. Ilyen lehet például, hogy a tesztkörnyezetet nem mentjük, külső emailcímre emailt nem küldünk, bizonyos időzített folyamatoknak nem kell futniuk.
Az előző bekezdésekben igyekeztem számos olyan pontra rávilágítani, amely egy szoftverkörnyezet létrehozásakor fontos szempont lehet. Számos problémát felvetettem egy tesztkörnyezet létrehozása kapcsán. Amennyiben Önöknél is problémát okoz egy ilyen környezet üzemeltetése, vagy egy új szoftveres megoldás bevezetésében gondolkodnak, szívesen állunk rendelkezésükre sok éves szakmai tapasztalatunkkal.