Írta: tom1964h

Bevezetés a verziókezelésbe#

Beszéljünk arról, hogy hogyan dolgozunk együtt másokkal. Ugyanis a programozás világában - vagy inkább a szoftverfejlesztés világában, hiszen ebben nem csak programozók vesznek részt - nagyon fontos, hogy együtt tudj dolgozni másokkal a csapatodon belül, vagy akár más csapatokkal.

Hogy néz ki ez a való életben? Akár kicsi, akár nagy cégnél dolgozol, alapvető, hogy elég pár embernek hozzáférést biztosítani a kódhoz, és az is nagyon fontos, hogy ez védve legyen az illetéktelen és/vagy hozzá nem értő felhasználóktól. Itt az “illetéktelen” alatt nem feltétlenül azt kell érteni, hogy a konkurens cég embere vagy egy mezei felhasználó ne férhessen hozzá, de gondoljunk arra, hogy az egyik igazgató - aki lehet hogy nem ért semmit a programozáshoz - nehogy hozzáférést kapjon ahhoz a kódhoz, amit napi szinten frissítetek. Ebben lehet egy csomó félkész vagy nem teljesen működő kód.

Nagyon fontos annak a felismerése, hogy egy fejlesztés során különböző embereknek különböző interakcióba lépnek egymással és a termékkel. A produktum lehet bármi: lehet egy szakdolgozat, egy többszerzős tudományos munka, egy regény kézirata, egy zeneszám kottái, egy weboldal, tudásbázis, wiki-oldalak, forráskódok, konfigurációs file-ok, egy Java-FX alkalmazás, lehet egy Java szerver, vagy bármi más szoftvertermék mobiltelefonra vagy laptopra. Az üzembiztonság javítására sokféle módszertant dolgoztak ki, hogy maga ez a folyamat rendszerezetten menjen végbe és a produktum megbízhatóan leszállítható legyen.

_{A szoftverfejlesztési módszertani keretekben alkalmazott három alapvető megközelítés (Wikipedia)}

A profi, kiterjedt, távoli elérésű szoftverek korában ráadásul a fejlesztésnek soha nincs vége, folyamatos gondozást igényel a projekt, számos alprojektre bomlik, új verziók készülnek, stb. Erre a helyzetre is készültek pl. CI/CD módszertanok, amit számos eszköz, pl. a GitHub vagy a Docker vagy a Kubernetes vagy akár az Amazon AWS támogat.

A repository - tároló#

Ismerkedjünk meg a repository fogalmával, ami egy tárhely, egy virtuális raktár. Ez eltárolja a munkánkat, de annál többet is tesz, mint egy egyszerű raktár: rendszerez és hozzáférést biztosít. A repository helyes működése leginkább egy személyi asszisztenshez hasonlítható. A többféle értelemben használt repository-ra itt a software repository megjelölés vonatkozik. Ezzel összefüggésben említhetjük a information repository fogalmát, amely alatt inkább digitális könyvtárat értünk, illetve a knowledge base-t, azaz a tudásbázist, amellyel itt nem foglalkozunk.

Tételezzük fel, hogy egy nagyon egyszerű projekten dolgoztok hárman, egy weboldal készül, ami 3 db html fájlból áll: az index.html, ami megjelenik a szervereden (egy webszerveren). Ez az index.html tartalmaz linkeket is - mondjuk egy menüben - ami átirányít a kapcsolat.html-re, illetve van benne egy “rólunk” menü is. Mindenkinek külön feladatai vannak:

• te megírod a kezdőképernyőt,
• a Flóra megírja a “rólunk” szekciót,
• és valaki (Peti) pedig a “kapcsolat” menüponton dolgozik.

Hogyan lehetne ezt nagyon egyszerű módon csinálni? Ha egy közös tárhelyre töltitek fel az állományokat, akkor könnyen előfordulhat, hogy kell valamit módosítani, ami mégse lett olyan jó, hanem a kettővel előbbi verzió mégis megfelelőbb lehet. Ha nincs nálad a régi verzió helyi másolata (local copy), akkor a régi jó tartalom elveszett.

Erre a problémára találták fel a veriókezelést. A Git vagy az SVN vagy bármilyen verziókezelő rendszer pont azért lett kifejlesztve, hogy ebben nekünk segítsen. A verziókezelő rendszerek fogják a fájlokat és azt mondják: ami most van nekem, egy adott könyvtárban (repository-ban) (egy tárolóban) megtalálható, azt egy verzónak tekintem (a repository-t általában repó szóval rövidítik).

Ha úgy dönt Peti barátod, hogy módosít a kapcsolat.html-en és ezt elküldi, a verziókezelő rendszer megkapja: “el-commit-olták” (tehát elküldték neki ezt a módosítást), elmenti ezt az új fájlt, de őrzi még a régit is!

Mert ha bármelyik programozó vagy a projektmenedzser (egy adott projektben ő szokta ezeket irányítani általában) úgy veszi észre, hogy a friss nem megfelelő (hibás, nem tetszik a színe, a szaga, tönkretesz más dolgokat, félreértés az egész, stb stb), akkor bármikor vissza tudunk állni az előző verzióra, amiben még a régi fájl volt. Ezt a repository őrzi rendezetten.

Nagy fejlesztéseknél a programozási feladat hamar komplex lehet, hiszen amikor egy újabb verziót hozunk létre, akkor összekeverjük a mostani változatot egy régi változat kódrészletével. Fontos megőrizni a visszakereshetőséget és a visszaállíthatóságot, mert nagyobb projektek esetén nem mindig tudhatunk róla sajnos, hogy a módosítás, amit elvégeztünk egy projekten az milyen hatást gyakorol mások munkájára.

_{teammunka Git segítségével: a központi repo másolatait a fejlesztők gépei is őrzik}

A verziózás - versioning#

A szoftverek fejlesztésének és értékesítésének szabályos életciklusa van. Ebben lényeges elemek a fejlesztési irányok kijelölése, majd a fejlesztési időszak lezárása, a különböző verziók kialakítása, a szoftver-kiadás és a hibakezelés. Maga a verzió kifejezés is sok értelmet kapott már a fejlesztésben, pl.:

• a kereskedelmi szoftvertermékeket (operációs rendszereket, irodai eszközöket és játékszoftvereket egyaránt) marketing és más szempontok szerint nevezik el sokszor, a versioning gyakorlata cégenként eltérő lehet;
• megint más a belső verziószámozás;
• a napi programozói rutin ehhez képest projektekre és azon belül elemi fejlesztési lépésekre bomlik, amelyek elnevezése / jelölése sokszor teljesen eltérhet a nyilvános verziószámozásoktól.