Kiadáskezelés

A kiadáskezelés a szoftverváltoztatások éles környezetbe való átmenetének tervezésével, ütemezésével és ellenőrzésével foglalkozó tudományág. Magában foglalja a kiadás tartalmát, annak ellenőrzését, telepítését, utólagos monitorozását, és a folyamat visszafordítását, ha valami rosszul sül el. Célja, hogy a beépített verzióról az éles verzióra való átmenetet rutinszerűen, ne pedig eseménydúsan tegye lehetővé.

Az ezen a területen a legkövetkezetesebb megállapítás ellentmond az intuíciónak. A nagy kiadások biztonságosabbnak érződnek, mert egyetlen gondosan kezelt eseménybe koncentrálják a kockázatot, de a kézbesítési teljesítménykutatásokból származó bizonyítékok az ellenkezőjére utalnak: a gyakori kis kiadások alacsonyabb hibaszázalékot és gyorsabb helyreállítást eredményeznek. Egy nagy kiadás számos változtatást foglal magában, így amikor valami meghibásodik, az okot nehéz izolálni, és a visszagörgetés mindent elvet, nem pedig az egyetlen hibás változtatást.

A telepítési automatizálás az az alap, amely lehetővé teszi a gyakoriságot. A manuális telepítési eljárások lassúak, inkonzisztensek és hibalehetőségeket rejtenek magukban, a kiadásonkénti költségük pedig nyomást gyakorol a kötegelt módosításokra, ami pontosan a nagyobb, de nagyobb kockázatot hordozó kiadásokat eredményezi. A folyamat automatizálása, hogy a telepítés megismételhető és észrevehetetlen legyen, megszünteti a felhalmozódás ösztönzését.

A telepítés és a kiadás szétválasztása az a technika, amely a leginkább megváltoztatja a kockázati profilt. Ha a kódot egy jelző mögé épített letiltott funkcióval éles környezetben telepítjük, majd külön engedélyezzük, az azt jelenti, hogy a kód kiszállításának technikai művelete és a funkciók üzleti közzétételének művelete már nem esik egybe. A telepítés során felmerülő problémákat a felhasználók érintése nélkül észlelhetjük, és a funkciók fokozatosan elérhetővé tehetők, majd azonnal visszavonhatók anélkül, hogy bármit is újra telepítenénk.

A fokozatos kitettség természetes módon következik ebből az elkülönítésből. A forgalom kis százalékára történő kiadás, a hibaszázalékok és az üzleti mutatók monitorozása, valamint a fokozatos bővítés a felhasználók egy töredékére korlátozza bármely probléma hatókörét. Ez lényegesen hatékonyabb, mint a kiterjedt, kiadás előtti tesztelés, a csak valós termelési körülmények, terhelés és adatok mellett megjelenő problémaosztályok kiszűrésében.

A visszagörgetési képességet ellenőrizni kell, nem pedig feltételezni, és sok szervezet itt fedez fel problémát a legrosszabb pillanatban. Egy dokumentált, soha nem végrehajtott visszagörgetési eljárás gyakran szükség esetén kudarcot vall, különösen adatbázis-migrációk esetén, ahol a sémaváltozás nem egyszerűen visszafordítható. A visszagörgetés gyakorlása és a migrációk visszafelé kompatibilis megtervezése, hogy az előző verzió továbbra is működjön, teszi valóssá a biztonsági hálót.

A kiadás utáni monitorozás a folyamat része, nem pedig különálló feladat. A kiadás nem akkor fejeződik be, amikor a telepítés sikeres; akkor fejeződik be, amikor a rendszer valós forgalomban megfelelően működik. Ha előre meghatározzuk, hogy mely indikátorokat, mennyi ideig és milyen küszöbértéken keresztül figyeljük a rendszert, az a kiadás utáni időszakot egy homályos éberségből egy meghatározott lépéssé alakítja, amelyhez döntés is tartozik.

A kiadásokkal kapcsolatos kommunikáció fontosabb, mint azt a csapatok várnák, különösen akkor, ha a változások láthatóak az ügyfelek számára, vagy olyan belső felhasználókat érintenek, akiknek fel kell készülniük. A támogató csapatoknak tudniuk kell, hogy mi változott, mielőtt az ügyfelek kérdeznének, és a be nem jelentett felületváltozások aránytalanul nagy mennyiségű kapcsolatfelvételt generálnak a méretükhöz képest. Egy rövid, megbízható értesítés, amely eléri a kérdésekre válaszoló embereket, kevésbe kerül, és megakadályozza a kiszámítható fennakadásokat.

Mivel a kiadási gyakorlatot ugyanúgy meghatározza az alapul szolgáló szállítási infrastruktúra, mint a folyamat, a fejlesztés általában mérnöki beruházást igényel, nem pedig eljárásbeli változtatást. A gyakorlatban ez a rendszeren belül történik. termékfejlesztésa kibocsátás utáni monitoring a ... révén végzett mérésekre támaszkodik. adatelemzés így az üzleti hatást is figyelembe veszik, ne csak a technikai állapotot, és a számos szolgáltatást futtató szervezeteknél a szabványok jellemzően a teljes szervezet tulajdonában vannak. IT osztály ahelyett, hogy csapatról csapatra haladnánk.