Telepítési környezet
A szoftver telepítésekor a környezet olyan számítógépes rendszer vagy rendszerek összessége, amelyben egy számítógépes program vagy szoftverkomponens telepítése és végrehajtása történik. Egyszerű esetekben, mint például egy program fejlesztése és azonnali végrehajtása ugyanazon a gépen, egyetlen környezettel, de ipari felhasználás esetén a fejlesztési környezet (ahol a változtatások eredetileg készültek) és a termelési környezet (amit a végfelhasználók használnak) elkülönül, gyakran több lépcső van a kettő között. Ez a strukturált folyamat lehetővé teszi a szakaszos bevezetést (rollout), tesztelést és a visszaállítást probléma esetén..
A környezetek mérete jelentősen eltérhet: a fejlesztői környezet jellemzően egy egyedi fejlesztői munkaállomás, míg a termelési környezet lehet egy adatközpontokban lévő, földrajzilag elosztott gépekből álló központ, vagy a virtuális gépek a felhőalapú számítástechnikában. A kód, az adatok és a konfiguráció párhuzamosan is telepíthető, és nem kell kapcsolódnia a megfelelő szinthez - például a gyártás előtti kód kapcsolódhat egy termelési adatbázishoz.
Architektúrák
[szerkesztés]A telepítési architektúrák jelentősen eltérnek egymástól, de általánosságban a szintek a fejlesztési (DEV) és a termelési (PROD) szintek között helyezkednek el. Egy gyakori négyszintű architektúra a fejlesztés, tesztelés, modell, gyártás (DEV, TEST, MODL, PROD), a szoftvert sorrendben telepítik mindegyikre. Másik gyakori környezetek közé tartozik a minőség-ellenőrzés (QC) az átvételi teszteléshez; a homokozó vagy kísérleti (EXP) a kísérletekhez, amelyeket nem szándékoznak a termelésbe bevinni és a katasztrófa-helyreállítás, ami azonnali tartalékot biztosít a termeléssel kapcsolatos problémák esetén. Egy másik gyakori architektúra a fejlesztés, a tesztelés, az elfogadás és a gyártás (DTAP).
Ez a nyelv különösen alkalmas szerverprogramokhoz, ahol a szerverek egy távoli adatközpontban futnak, a végfelhasználó eszközén futó kódok, például alkalmazások (apps) vagy a kliensek esetében a felhasználói környezetre (USER) vagy a helyi környezetre (LOCAL) lehet hivatkozni.
A környezetek közötti pontos meghatározások és határok eltérőek - a teszt a fejlesztés részének tekinthető, az átvétel a teszt és a szakasz része, vagy különálló stb. A fő szintek sorrendben haladnak végig, az új kiadásokat sorban telepítik (roll out vagy push) mindegyikre.[1][2] Ha vannak kísérleti és a helyreállítási szintek, azok kívül esnek ezen a folyamaton - a kísérleti kiadások terminálisak, míg a helyreállítás jellemzően a termelés régi vagy duplikált verziója, amelyet a termelés után telepítenek. Problémák esetén vissza lehet állni a régi kiadásra, a legegyszerűbben úgy, hogy a régi kiadást úgy kezeljük, mintha új kiadás lenne. Az utolsó lépés, a termelésbe való telepítés ("pushing to prod") a legérzékenyebb lépés, mivel bármilyen probléma azonnali hatást gyakorol a felhasználókra. Emiatt ezt gyakran másképp kezelik, legalábbis gondosabban felügyelik. Egyes esetekben szakaszos bevezetéssel vagy csak egy kapcsoló átkapcsolásával, ami lehetővé teszi a gyors visszaállítást. A legjobb, ha elkerüljük az olyan elnevezést, mint a minőségbiztosítás (QA), a QA nem szoftvertesztelést jelent. A tesztelés fontos, de különbözik a QA-tól.
Néha a telepítés ezen a rendszeres folyamaton kívül történik, elsősorban sürgős vagy viszonylag kisebb változtatások biztosítása érdekében, anélkül, hogy teljes kiadást igényelne. Ez állhat egyetlen javításból, egy nagyobb szervizcsomagból vagy egy kisebb azonnali javításból.
A környezetek nagyon különböző méretűek lehetnek: a fejlesztés jellemzően egy fejlesztő munkaállomása (bár több ezer fejlesztő is lehet), míg a gyártás sok, földrajzilag elosztott gépből állhat, a tesztelés és a minőség-ellenőrzés lehet kicsi vagy nagy, attól függően, hogy milyen erőforrásokat fordítanak rájuk, a folyamat pedig egyetlen géptől (a kanárihoz hasonlóan) a gyártás pontos másolatáig terjedhet.
Környezetek
[szerkesztés]Az alábbi táblázat a felosztott szintek listáját ismerteti.
| Környezet / réteg neve | Leírás |
|---|---|
| Helyi | A fejlesztő asztala / munkaállomása |
| Fejlesztés / Törzs | Fejlesztői szerver, amely homokozóként működik, ahol a fejlesztő egységtesztelést végezhet. |
| Integráció | CI célt állít fel, a fejlesztői tesztelés mellékhatásainak teszteléséhez |
| Tesztelés / Teszt / Minőség-ellenőrzés / Belső elfogadás | A környezet, ahol az interfész tesztelése történik. A minőség-ellenőrző csoport biztosítja, hogy az új kód ne legyen hatással a meglévő funkciókra, és teszteli a rendszer főbb funkcióit, miután az új kódot a tesztkörnyezetben telepítették. |
| Staging / Stage / Modell / Előkészítés / Külső ügyfélátvétel / Demó | A termelési környezet tükörképe. |
| Gyártás / Élő | Kiszolgálja a végfelhasználókat, ügyfeleket. |
Fejlesztés
[szerkesztés]A fejlesztői környezet (dev) az a környezet, amelyben a szoftver módosításait fejlesztik, a legegyszerűbben az egyén fejlesztő munkaállomása. Ez több szempontból is különbözik a végső célkörnyezettől - a cél nem feltétlenül egy asztali számítógép (lehet okos telefon, beágyazott rendszer, fej nélküli gép egy adatközpontban stb.), és még ha hasonló is, a fejlesztői környezet olyan fejlesztői eszközöket tartalmaz, mint a fordító, az integrált fejlesztőkörnyezet, a könyvtárak és a támogató szoftverek különböző vagy további verziói, amelyek a felhasználói környezetben nincsenek jelen.
Revíziós ellenőrzéssel összefüggésben, különösen több fejlesztő esetén, finomabb megkülönböztetéseket kell tenni: a fejlesztőnek a forráskód egy másolata van a gépén, majd a változtatásokat az adattárba küldi, a fejlesztési módszertantól függően a törzsbe vagy egy ágba. Az egyéni munkaállomáson lévő környezetet, amelyben a változtatásokat kidolgozzák és kipróbálják, helyi környezetnek vagy homokozónak is nevezhetjük. A forráskód adattári másolatának tiszta környezetben történő elkészítése külön lépés, az integráció (a különböző változtatások integrálása) része, és ezt a környezetet nevezhetjük integrációs környezetnek vagy fejlesztési környezetnek. A folyamatos integrációban ez gyakran történik, akár minden egyes revízió esetén. A forráskód szintű koncepció a "változtatás átadása a tárolóba", majd a törzs vagy ág építése megfelel a kiadásra való áttérésnek a helyi, egyéni fejlesztői környezetből az integrációba (clean build). Egy rossz kiadás ennél a lépésnél azt jelenti, hogy egy változtatás tönkretette a kész kódot és a kiadás visszafordítása megfelel attól a ponttól összes változtatás visszafordításának, vagy csak a tönkretett változtatás visszafordításának, amennyiben ez lehetséges
Tesztelés
[szerkesztés]A tesztkörnyezet célja, hogy lehetővé tegye az emberi tesztelők számára az új és a módosított kód gyakorlását, akár automatizált ellenőrzésekkel, akár nem automatizált technikákkal.[3] Miután a fejlesztő elfogadta az új kódot és konfigurációkat a fejlesztési környezetben végzett egységtesztelésen keresztül, az elemek egy vagy több tesztkörnyezetbe kerülnek.[4] A tesztelési hiba esetén a tesztkörnyezet képes eltávolítani a hibás kódot a tesztplatformokról, kapcsolatba lépni a felelős fejlesztővel, és részletes teszt- és eredménynaplót szolgáltatni. Ha az összes teszt sikeres, a tesztkörnyezet vagy a teszteket ellenőrző folyamatos integrációs keretrendszer automatikusan továbbíthatja a kódot a következő telepítési környezetbe.
Különböző tesztelési típusokhoz különböző típusú tesztkörnyezeteket javasolnak, amelyek egy része vagy egésze virtualizálható[5] ] a gyors, párhuzamos tesztelés lehetővé tétele érdekében. Például az automatizált felhasználói felületi tesztek[6] ] több virtuális operációs rendszeren és kijelzőn (valós vagy virtuális) is végezhetőek. A teljesítménytesztekhez szükség lehet egy normalizált fizikai alaphardver-konfigurációra, hogy a teljesítménytesztek eredményei idővel összehasonlíthatóak legyenek. A rendelkezésre állási vagy tartóssági tesztek a virtuális hardver és a virtuális hálózatok hiba-szimulátoraitól függhetnek.
A tesztek a tesztkörnyezet kifinomultságától függően lehetnek soros (egymás után) vagy párhuzamos (néhány vagy az összes egyszerre). Az agilis és más, nagy termelékenységű szoftverfejlesztési gyakorlatok egyik jelentős célja a szoftvertervezéstől vagy specifikációtól a gyártásba kerülésig eltelt idő csökkentése.[7] A nagymértékben automatizált és párhuzamosított tesztkörnyezetek jelentősen hozzájárulnak a gyors szoftverfejlesztéshez.
Stádium
[szerkesztés]A stádium vagy elő-gyártási környezet egy olyan tesztelési környezet, amely pontosan hasonlít a termelési környezetre. A lehető legjobban igyekszik tükrözni a tényleges termelési környezetet, és kapcsolódhat más termelési szolgáltatásokhoz és adatokhoz, például adatbázisokhoz.[8] A stádium, az elő-gyártási környezet egy olyan környezet, amely a tesztelésre szolgál. Például a szerverek nem helyben, hanem távoli gépeken futnak (mint a fejlesztő munkaállomásán a DEV során, vagy egyetlen tesztgépen a teszt során), ami a hálózatépítés rendszerre gyakorolt hatását teszteli.
Az átmeneti környezet elsődleges célja a telepítési/konfigurációs/migrációs szkriptek és eljárások tesztelése, mielőtt azokat a termelési környezetre alkalmaznák. Ez biztosítja, hogy a termelési környezet minden nagyobb és kisebb frissítése megbízhatóan, hibamentesen és minimális idő alatt készüljön el.
A stádium/állapot, másik fontos felhasználási területe a teljesítménytesztelés, különösen a terhelés tesztelése, mivel ez gyakran érzékeny a környezetre.
A körülményeket (stádium) egyes szervezetek arra is használják, hogy az új funkciókat kiválasztott ügyfelek számára előzetesen bemutassák, vagy a külső függőségek éles verzióival való integrációkat validálják.
Termelés
[szerkesztés]A termelési környezetet élő környezetnek is nevezik, különösen a szerverek esetében, mivel ez az a környezet, amellyel a felhasználók közvetlenül érintkeznek.
A termelésbe való telepítés a legérzékenyebb lépés; ez történhet az új kód közvetlen telepítésével (a régi kód felülírásával, így egyszerre csak egy példány van jelen), vagy egy konfigurációs módosítás telepítésével. Ez többféleképpen történhet: a kód új verziójának párhuzamos telepítése és a kettő közötti váltás egy konfigurációváltással; a kód új verziójának telepítése a régi viselkedéssel és egy funkciójelzővel és a váltás az új viselkedésre egy konfigurációváltással történik, amely a jelző felcserélését végzi vagy pedig különálló kiszolgálók telepítése (az egyik a régi kódot futtatja, a másik az újat), és a forgalom átirányítása a régiről az újra a forgalomirányítás szintjén végrehajtott konfigurációváltással. Ezek egyszerre vagy fokozatosan, szakaszosan is elvégezhetők.
Egy új kiadás telepítése általában újraindítást igényel, kivéve, ha gyors csere lehetséges, és így vagy a szolgáltatás megszakítását (ami a felhasználói szoftverek esetében szokásos, ahol az alkalmazások újraindulnak), vagy redundanciát, vagy a példányok lassú újraindítását a terheléselosztó mögött, vagy az új szerverek idő előtti indítását jelenti, majd a forgalom egyszerű átirányítása az új szerverekre.
Amikor egy új kiadást a termelésbe telepítünk, ahelyett, hogy azonnal az összes példányra vagy felhasználóra telepítenénk, először egy példányra vagy a felhasználók egy részére telepítjük, majd az összesre vagy fokozatosan, szakaszosan telepítjük, hogy az utolsó pillanatban felmerülő problémákat kezelni tudjuk. Ez hasonló a stádiumhou, kivéve, hogy ez ténylegesen a termelésben történik és a szénbányászat analógiájára canary release-nek nevezik. A többi kiadás egyidejű futtatása miatt ez bonyolultabb, és azért, hogy elkerüljék a kompatibilitási problémákat általában gyorsan véget ér.
Keretrendszerek integrációja
[szerkesztés]A Fejlesztés, Stádium és a Termelés ismert és dokumentált környezeti változók az ASP.NET Core-ban. A definiált változótól függően más-más kódot hajtanak végre és más tartalmat rendelnek egymáshoz, valamint más biztonsági és hibakeresési beállításokat alkalmaznak.[9]
Jegyzetek
[szerkesztés]- ↑ Traditional Development/Integration/Staging/Production Practice for Software Development. Disruptive Library Technology Jester, 2006. december 4.
- ↑ Development Sandboxes: An Agile 'Best Practice'. www.agiledata.org
- ↑ June 2, Priti: Test Automation Best Practices and Tips (amerikai angol nyelven). Insights on Latest Technologies - Simform Blog, 2019. december 17. (Hozzáférés: 2021. június 17.)
- ↑ Ellison: Software Testing Environments Best Practices. Software Testing Magazine. Martinig & Associates, 2016. június 20. (Hozzáférés: 2016. december 2.) „"Once the developer performs the unit test cases, the code will be moved into QA to start testing. Often you will have a few environments for testing. For example you will have one set up for system testing and another that is used for performance testing and yet another that is used for user acceptance testing (UAT). This is caused by the unique needs for each type of testing."”
- ↑ Dubie: How to keep virtual test environments in check. Network World, Inc.. IDG, 2008. január 17. (Hozzáférés: 2016. december 2.) „"Virtual server technology makes it easy for enterprise companies to set up and tear down test environments in which they can ensure applications will run up to par on production servers and client machines."”
- ↑ Use UI Automation To Test Your Code. Microsoft.com. Microsoft. (Hozzáférés: 2016. december 2.) „"Automated tests that drive your application through its user interface (UI) are known as coded UI tests (CUITs). These tests include functional testing of the UI controls. They let you verify that the whole application, including its user interface, is functioning correctly. Coded UI Tests are particularly useful where there is validation or other logic in the user interface, for example in a web page."”
- ↑ Heusser: Are you over-testing your software?. CIO.com. IDG, 2015. július 7. [2017. június 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. december 3.) „"Release candidate testing takes too long. For many agile teams, this is the single biggest challenge. Legacy applications start with a test window longer than the sprint."”
- ↑ Sharma, Anurag. Test Environment Management. ITSM Press, 11. o. (2018. november 2.). ISBN 9781912651269
- ↑ Use multiple environments in ASP.NET Core (amerikai angol nyelven). docs.microsoft.com. (Hozzáférés: 2019. április 5.)
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Deployment environment című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.