Nagyobb, eltérő indulási dátumú projekteknél gyakran nagyon sok módosítási kérelem jön létre. Minden éles indulás előtt meg kell győződni arról, hogy ezeket a módosításokat a „megfelelő” sorrendben szállítják. Ha a fejlesztői rendszerben hiányzik a tesztkörnyezet, akkor érvényes fejlesztői tesztek csak a minőségbiztosítási rendszerben végezhetők el, miáltal a szükséges módosítási kérelmek száma jelentősen megnő.

Itt az ideje figyelni a módosítási kérelmek sorrendjét, és abszolút kerülni az átfedéseket. Mert ha nem a megfelelő sorrendben kerül szállításra, fennáll annak a veszélye, hogy a már átdolgozott állapotú objektumok szállításra kerülnek, így a rendszerei végül eltérő állapotúak lesznek. Minél több szállítást kell felügyelni, és minél több különböző projekt vagy projektcsapat hozza létre ezeket a kérelmeket, annál bonyolultabb lesz a transzportmenedzsment.

Hogyan csökkentheti drasztikusan a transzportok számát a másolatokból történő transzportálással?

Itt jön a képbe az úgynevezett  „másolatok transzportja”, ami segít csökkenteni a módosítási kérelmek teljes számát.

Az alapötlet: a másolatok transzportja nem a teljes rendszerkörnyezeten keresztül történik. Míg a normál módosítási kérelmek egy adott transzport útvonalat követnek egy háromrendszerű környezetben, a másolatok csak a teszt rendszerbe kerülnek.

Emiatt a másolatok transzportjával az aktuális fejlesztési állapot (mindig) a teszt rendszerbe kerülhet. Ez az állapot ott teljeskörűen tesztelhető. A tesztek eredményeként végrehajtott módosítások ezután a „régi” módosítási kérelembe kerülnek beállításra, amely még mindig „nyitott” állapotban van.

Ideális esetben csak egy módosítási kérelemhez lesz szükség a projekthez.

Kevesebb transzport a másolatok transzportjának köszönhetően

A következő példa bemutatja a másolatok transzportjával való munka lehetőségét:

Feltételezzük, hogy kis projektünkben három tesztelési körre van szükség, mielőtt a változtatások életbe lépnek. A esetben normál transzport útvonalon dolgozunk. B esetben másolatok transzportjával.

Az A eset összesen 3 customizing és 3 workbench kérelmet használ. Minden tesztkörhöz szükséges customizing és workbench kérelem szükséges. 

Ez a következő lépéseket eredményezi:

  • Első beállítás és fejlesztés az 1. customizing és workbench kérelembe
  • 1. Kérelmek bejátszása a Q rendszerbe
  • Tesztelés a Q rendszerben első körben
  • Módosítások a fejlesztői rendszerben a 2. customizing és workbench kérelembe
  • 2. Kérelmek bejátszása a Q rendszerbe
  • A tesztelés második köre a Q rendszerben
  • Módosítások a fejlesztői rendszerben a 3. customizing és workbench kérelembe
  • 3. Kérelmek bejátszása a Q rendszerbe
  • Teszt befejezése, nem kell több módosítás
  • Az 1., 2. és 3. customizing és workbench kérelmek bejátszása az éles rendszerbe

A B esethez egy customizing és egy workbench kérelemre van szükség. A tesztkörök változásait másolatok átvitelével térképezzük fel. Ez a következő lépéseket eredményezi:

  • Első beállítás és fejlesztés az 1. customizing és az 1. workbench kérelemben
  • Másolatok szállítása a Q rendszerbe
  • Első tesztkör
  • Javítások az 1. customizing és az 1. workbench kérelemben
  • Másolatok szállítása a Q rendszerbe
  • A tesztelés második köre
  • Javítások az 1. customizing és az 1. workbench kérelemben
  • Másolatok szállítása a Q rendszerbe
  • Utolsó tesztkör
  • 1. customizing és 1. workbench kérelem szállítása az éles rendszerbe

Példánkban az éles rendszerben az import szállítások száma 66%-kal csökken. Természetesen itt csak egy apró és nagyon egyszerű példát használtunk. A százalékos érték azonban benyomást ad arról, hogy a szállítások száma milyen irányban alakulhat a másolatok szállítása révén.

Minden cégnél más a rendszer, a követelmények és a kiindulási helyzet, így a másolatszállítással való munka is eltérő megtakarítási potenciált eredményez. Amit még el kell mondanunk, hogy a szükséges workbench/customizing kérelmek száma drámaian csökkenni fog a másolatok szállítása során. Ez csökkenti a szállítások kezeléséhez szükséges erőfeszítéseket.

Az objektumzárolások a másolatok szállítása során megmaradnak

A másolásszállítás használatának másik előnye az objektum zárolások megőrzése a fejlesztői rendszerben. Ha egy ilyen objektumot beállítanak a fejlesztői rendszerben, akkor az egy adott workbench kérelemben zárolódik (1. kérelem).

Ha ezt a transzport kérelmet most feloldjuk és a teszt rendszerbe visszük, akkor az objektum zárolása feloldódik. Az objektum most hozzárendelhető egy új workbench kérelemhez (pl. 2. kérelem) a fejlesztői rendszerben, ha azt újra vagy tovább módosítják – pl. egy másik fejlesztés vagy egy másik projekt részeként.

Példánkban az 1. kérelem a vizsgált objektum egy régebbi verzióját tartalmazza. Most azonban a második projektnek életbe kell lépnie az első projekt előtt. Így a 2. kérelemmel a vizsgált objektum aktuális verziója kerül először az éles rendszerbe. Amikor az 1. projekt életbe lép, fennáll annak a veszélye, hogy objektumunk régi verziója kerül be az éles rendszerbe az 1. kérelemmel. 

Eredmény: Van egy „előző” és eltérő rendszerállapot az éles rendszerben. Emiatt kell a szállítási sorrendet szigorúan betartani.

A másolatok szállítása megkönnyíti ennek a sorrendnek a nyomon követését, mivel ideális esetben az eredeti workbench kérelem csak az élesbe történő szállításkor kerül továbbításra. Objektumunk ezért egész idő alatt zárva marad. Ha egy másik projekt részeként a zárolt objektumot is módosítani kell, a fejlesztő azonnal észreveszi a zárolást, és ezt egyeztetnie kell a másik csapattal.

Tovább hasznos információt a 1293449 SAP note-ban talál.

Kérdése van? Akkor forduljon hozzánk bizalommal. A kapcsolatfelvételi űrlapot itt találja.