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 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. 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 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 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 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. 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. 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ó ] a gyors, párhuzamos tesztelés lehetővé tétele érdekében. Például az automatizált felhasználói felületi tesztek ] 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. A nagymértékben automatizált és párhuzamosított tesztkörnyezetek jelentősen hozzájárulnak a gyors szoftverfejlesztéshez.
Stádium 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. 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 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 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.
Jegyzetek
Fordítás
Kapcsolódó szócikkek Integrált fejlesztői környezet Szoftverfejlesztés
Kategória:Szoftverfejlesztés