055.2 Lecke 1

A felhasználók által leginkább elvárt egyik tulajdonság szoftver stabilitása. Az első kérdés, amit sokan feltesznek egy új release (kiadás) hallatán, az, hogy “Mennyire stabil?”. Más szóval, megbízhatóan fog-e működni, vagy összeomlik, elrontja az adatokat, vagy hibás eredményeket produkál?

A stabilitás egy spektrumon mérhető, és sokan szívesen használnak egy szoftvert akkor is, ha még vannak benne hibák. A fejlesztőcsapatok azonban hajlamosak a dolgokat egyszerűen kezelni, és binárisan beszélnek stabil (stable) és nem stabil (unstable) kiadásokról.

A stabilitás egyszerre utal a szoftver hibáira másrészt annak valószínűségére, hogy a kívülállók számára látható módon megváltozik. A fejlesztők instabilnak tekinthetik egy szoftverkönyvtár egyik kiadását, mert például megváltoztatták a programozók által hívott funkciókat (vagyis mert a programozóknak a következő releaseig esetleg újra kell írniuk a szoftverüket). A felhasználó szempontjából azért is lehet instabil egy szoftver, mert a fejlesztők eltávolítottak egy funkciót.

Van valami oka annak, hogy kiadnak egy instabil verziót? Igen: értékesek, mert a felhasználók a projekt korai szakaszában kipróbálhatják az új funkciókat, és tesztelhetik hibakeresés céljából.

Azért, hogy a legfontosabb ügyfelek kipróbálhassák, a legtöbb projekt releaseli a szoftver nagyon korai változatait; ezeket nevezik alfa releasenek. Ezeket senki sem használhatja valódi munkára — csak tesztelésre szolgálnak. Valójában a tesztelőknek olyan számítógépeken kell futtatniuk őket, amelyeken nem végeznek fontos munkát, mert az ezekben a releasekben található hibák ténylegesen károsíthatják a számítógépen tárolt adatokat.

Amikor a szoftver már közel van ahhoz, hogy stabilnak minősüljön, a projekt általában kiad egy újabb tesztverziót, az úgynevezett béta releaset. Ezeket továbbra is csak tesztelni lehet, nem szabad őket éles (production) környezetben használni.

Mind az alfa-, mind a béta-kiadások esetében a fejlesztők rendelkezésére áll egy folyamat a hibák bejelentésére és a hibák kijavítása érdekében tett lépések nyomon követésére.

Egyes projektek tartalmaznak még egy szakaszt a béta és a stabil release között, amikor a fejlesztők már minden hibát kijavítottak, és úgy gondolják, hogy a termék kész. Ez a verzió a release candidate (kiadásra jelölt), amit megmutatnak a kulcsfontosságú ügyfeleknek vagy érdekelteknek, hogy megtervezhessék, hogyan használják majd az új funkciókat.

Végül, néhány projekt olyan funkciókat is beépít, amelyek nem teljesen stabilak, mert fontos felhasználók kérték őket. A fejlesztők célja, hogy a felhasználók kipróbálják ezeket a funkciókat, és elmondják, hogy tetszenek-e nekik, mielőtt a fejlesztők véglegesítenék az interfészeket, és energiát fektetnének a funkciók stabilizálására.

A legtöbb projekt a backward compatibility-re (visszafelé kompatibilitás) törekszik, ami azt jelenti, hogy nem próbálja eltávolítani a régebbi verziókban meglévő funkciókat vagy képességeket. A kompatibilitás több szinten is létezhet. Ha például a fejlesztők fenntartják a backward compatibilityt az alkalmazásprogramozási interfésszel (API) kapcsolatban, akkor azt ígérik, hogy a régi forráskód továbbra is működhet, de lehet, hogy újra le kell fordítani. Ha a hardvergyártók vagy az operációs rendszer fejlesztői fenntartják a visszafelé kompatibilitást az alkalmazás bináris interfészére (ABI) vonatkozóan, akkor azt ígérik, hogy ezen felül a régi futtatható fájlok a hardver új verzióin is futtathatók.

Később megnézzük, hogyan kezelik a projektek a backward compatibility hiányát, amikor úgy döntenek, hogy a régi interfész valóban nem működik az új funkciókkal vagy környezetekkel, amelyeket támogatniuk kell.

A szoftver ideális esetben egyre jobb és jobb lesz, ahogy a fejlesztők felfedezik és kijavítják a problémákat. Idővel azonban a szoftver környezetében bekövetkező változások miatt a funkciók nem működnek, valamint olyan új hibák is felfedezésre kerülnek, amelyek korábban rejtve maradtak.

Az új verziók gyakran kombinálják a biztonsági és hibajavításokat új funkciókkal. Lehet, hogy nekünk ezek az új funkciók nem kellenek (sőt, lehet, hogy jobban tetszik valamelyik régi, amit a fejlesztők eltávolítottak, hogy helyet csináljanak az újaknak), de az emberek általában azért frissítenek az új verzióra, hogy megkapják a biztonsági javításokat, amelyek megvédik őket a rosszindulatú támadásoktól.

Vannak, akik a szoftverek régi verzióit használják, és nem hajlandóak frissíteni. Ennek oka általában az, hogy az új verzió tönkretesz valamit, ami eddig működött náluk. Amikor a vállalatok pénzt kérnek a frissítésekért, néhány ügyfél nem hajlandó frissíteni, mert nem akarja kifizetni a plusz pénzt, de a nyílt forráskódú szoftvereknél ritkán kell fizetni a frissítésekért.

A fejlesztők a régi verziók felhasználói igényeket úgy elégítik ki, hogy a régi verziókban lévő hibákat javítják, anélkül, hogy a szoftvert tönkretevő funkciókat adnának hozzá. Természetesen a fejlesztők ezt nem tehetik meg örökké, mert ez időt és energiát von el az új munkától. Eljön az idő, amikor megtagadják a régi verzió javítását, és azt mondják a felhasználóknak, hogy vagy frissítsenek, vagy készítsenek saját javításokat.

A hibák és biztonsági hiányosságok kijavítását a szoftver supportjának (támogatás) nevezik. Ez különbözik a helpdeskek és más, a felhasználókat a szoftver megértésében segítő személyek által nyújtott támogatástól. A release menedzsment szempontjából a supported release az, amikor a fejlesztők megígérik, hogy kijavítják a hibákat, míg az unsopported release az, amikor nem teszik meg.

Megjegyzendő, hogy a “support” fogalma leginkább a vállalatok vagy nagy szervezetek által készített szoftverekre vonatkozik. A kisebb nyílt forráskódú projektek, amelyek nagymértékben függnek az önkéntesektől, gyakran csak azt ígérik, hogy a lehető legtöbbet teszik a hibák kijavításáért és az új verziók kiadásáért. Nem látják szükségét annak, hogy a régi verziókat javítsák. Mivel a kód nyílt forráskódú, azok a felhasználók, akik nem akarnak frissíteni, fizethetnek valakinek a régi verzió javításáért.

Ha van support, a fejlesztők közzétesznek egy ütemtervet, amelyben jelzik, hogy meddig támogatják az egyes verziókat. A dátumot, amikor a támogatás megszűnik, a szoftver életciklusának végének (end of life — EOL) nevezik. A felhasználók az EOL-ig megtarthatják a régi verziót, és számíthatnak a hibák kijavítására, de az EOL után frissíteniük vagy kockáztatniuk kell.

A nagyobb projektek, mint például a GNU/Linux Debian disztribúciója, hosszú távú támogatású (long term support — LTS) verziókat kínálnak. Ez egyszerűen azt jelenti, hogy a fejlesztők bizonyos számú évig folyamatosan javítják a hibákat. Azok az ügyfelek, akik nagyra értékelik a stabilitást, valószínűleg félnek telepíteni a sok változtatást tartalmazó szoftverek verzióit, ha a változtatások miatt olyan folyamatok sérülnek, amelyekre az ügyfelek támaszkodnak. Az ilyen ügyfelek, különösen a nagy intézmények, szeretik az LTS verziók biztonságát.

A fejlesztők igyekeznek jóval előre megtervezni, hogy milyen változtatásokat szeretnének végrehajtani egy terméken. A kereskedelmi cégeknél a marketingesekkel beszélnek, akik szűrik és összefoglalják, amit az ügyfelek mondanak nekik. A nyílt forráskódú projektek inkább a fejlesztők és a felhasználók által benyújtott ötletekre támaszkodnak, amelyeket egy issue tracker nevű adatbázisban rögzítenek. Ha ki kell javítani egy hibát, vagy egy új funkciót szeretnénk, akkor kitöltünk egy issue-t. A fejlesztők ezután rangsorolják a változtatásokat, és eldöntik, hogy melyiket ki fogja kezelni.

Hogyan választják ki és rangsorolják a változtatásokat? Ez zűrös folyamat lehet. A nyílt forráskódú projektek jó projektmenedzserei azonban ösztönzik a széles körű hozzájárulást, miközben biztosítják, hogy megszülessenek a döntések. Egyes projektek még konferenciákat is tartanak, ahol a résztvevők megvitatják a prioritásokat.

Egy közzétett roadmap (ütemterv) tartalmazza a fejlesztésekre és változtatásokra vonatkozó terveket. Ez több kiadásra és több évre is kiterjedhet. Minden egyes lépést mérföldkőnek (milestone) nevezünk, és lehet, hogy céldátum is társul hozzá, de lehet, hogy nem.

A releasek ütemezésének két alapvető módja van: idő- és funkcióvezérelt. Egy projekt ígérhet rendszeres időközönként — például félévente — egy releaset, és tartalmazhat mindent, ami addigra elkészül. Alternatív megoldásként a projekt ígérhet bizonyos funkciókat egy kiadásban, és hagyhatja, hogy a fejlesztők annyi időt szánjanak a funkciók befejezésére, amennyire szükségük van.

Ahogy közeledik a kiadás időpontja, a release menedzser meghatározza az alfa, béta és stabil releasek időpontját. A csapattagok rendszeresen áttekintik a hibajelentéseket, és igyekeznek úgy megtervezni a munkájukat, hogy ezeket a mérföldköveket tartani tudják.

A release befejezéséhez a projektnek fel kell hagynia az új funkciókkal kapcsolatos ötletek elfogadásával, és a meglévő funkciók megfelelő működésére kell összpontosítania. Ezt a pillanatot nevezzük feature freeze-nek (funkció befagyasztás).