056.2 Lecke 1

A forráskódmenedzsment-rendszer a szoftverprojekt szíve. Bár fontos munka folyik a fórumokon és egyéb helyeken is, az SCM rendszer képviseli a projekt történetét és jelenlegi állapotát, mint élő entitást.

A forráskód repository egyfajta digitális műhelye a projektnek. Ahogyan egy fizikai műhely egy munkadarab gyártásához szükséges összes szerszámot és tárgyat tárolja, a repository egy szoftverprojekthez kapcsolódó összes fájlt, dokumentumot és kódot. Strukturált környezetet biztosít a projekt eszközeinek szervezéséhez és kezeléséhez.

Az információkat általában könyvtárfa formájában tárolják. Az SCM-rendszerek jellemzően kliens-szerver modellt használnak, ahol bármely felhasználó lehúzhat (pull) adatokat a tárolóból, és fel is tölthet (push) oda. A rendszer nyomon követi, hogy ki és mikor hajtott végre egy-egy változtatást, így biztosítva az átláthatóságot és az elszámoltathatóságot a csapaton belül.

Képzeljük el, hogy egy projekten dolgozunk több fejlesztővel együtt, és hibát fedezünk fel a kódban. Egy SCM segítségével könnyedén megvizsgálhatjuk a változatok közötti változásokat, hogy pontosan meghatározhassuk a hibáért felelős kódváltozást.

Mivel a rendszer megjegyzi a fájlok minden egyes verzióját, ahogy azok változnak, a felhasználó hozzáférhet bármelyikhez, és visszaállíthatja a korábbiakat (például abban az esetben, ha a módosítások hibásak lennének). A repository tehát egyfajta archívum is, amely hozzáférést biztosít a projektben valaha végrehajtott minden változtatáshoz, valamint a projekt állapotához annak történetének bármely pillanatában.

Az SCM-rendszerek úgy takarítanak meg tárhelyet, hogy a fájl módosításait követik nyomon, ahelyett, hogy minden egyes módosításkor eltárolnák a teljes fájlt. Ez a hatékony módszer biztosítja azt, hogy a korábbi verziók túlzott erőforrás-igény nélkül is elérhetők legyenek.

Számos eszköz, például a continuous integration/continuous delivery (CI/CD), és a tesztelés is az SCM-rendszer körül forog. Az emberek ezen a rendszeren keresztül építik a reputációjukat is, mivel hozzájárulásaik mindenki számára láthatóvá válnak. A forráskódmenedzsment tehát nem csupán a változások nyomon követéséről szól; a kódbázis integritásának megőrzéséről és a fejlesztők közötti együttműködés elősegítéséről, biztosítva, hogy a projektek a dinamikus és folyamatosan változó környezetben is fejlődni tudjanak.

Népszerű SCM rendszer például a Git, a Subversion és a CVS. Sok más szoftverfunkcióhoz hasonlóan az SCM-et is gyakran speciális gyártók biztosítják. Más szóval, ez egy Software as a Service (SaaS) vagy “felhő” szolgáltatás: A felhasználók a helyi rendszereiken rendelkeznek a szoftverrel a saját módosításaik kezeléséhez, de a változtatásokat egy központi repositoryba töltik fel, amely biztosítja a felhőre jellemző funkciókat, például a 24/7 üzemidőt, a biztonsági mentéseket és a biztonságos hozzáférést.

Fejlesztők milliói használják a felhőszolgáltatásokat, különösen a GitHubot. A GitLab egy nyílt forráskódon alapuló alternatíva. Mind a GitHub, mind a GitLab lehetővé teszi, hogy az emberek a gyártó felhőalapú repositoryjaiban dolgozzanak, vagy telepítsék az SCM-rendszer helyi verzióját. Az ilyen környezetben végzett munka egyik előnye a hírnév, amelyet a “star” rendszereken keresztül szerezhetünk, amik lehetővé teszik a felhasználók számára, hogy egymás munkáját értékeljék. A felhőszolgáltatások olyan extra érdekességekkel bővültek, mint a változtatási kérelmek nyomon követése, az értékelési rendszerek, a wikik és a fórumok.

A repositoryk tartalmazhatnak személyes és céges projekteket egyaránt, vagyis nem feltétlenül kizárólag vállalati használatra szolgálnak. Bármely programozó, aki bele akar kezdeni egy fejlesztésbe, vagy egy nyílt forráskódú projekten akar dolgozni, másolva és módosítva azt az igényeinek megfelelően, megteheti. Ezekben az esetekben fontos szigorúan ellenőrizni, hogy ki férhet hozzá a repositoryhoz.

A verziókezelést és a forráskód-kezelést körülvevő terminológia megértése alapvető fontosságú a használatában való eligazodáshoz. A következő szakaszokban közelebbről megvizsgálunk néhány ilyen fogalmat és kifejezést.

A fejlesztő minden egyes alkalommal létrehoz egy commit-ot, amikor egy módosítást feltölt a repositoryba. A commitok a kódbázisban egy adott időpontban végrehajtott változtatások pillanatfelvételeit jelentik. Minden commit olyan metaadatokat tartalmaz, mint a szerző neve, egy időbélyeg és egy tájékoztató üzenet, amely a változásokat magyarázza. A commitok segítségével a fejlesztők nyomon követhetik a kódbázis fejlődését és megérthetik az egyes változtatások történetét.

Képzeljünk el egy webes alkalmazáson dolgozó fejlesztőcsapatot! Minden alkalommal, amikor módosításokat hajtanak végre a kódbázisban, létrehoznak egy commitot, hogy dokumentálják a változtatásokat. Például, ha valaki új funkciót ad hozzá az alkalmazáshoz, létrehozhat egy commitot a következő üzenettel: “Added user authentication feature.” (Felhasználói hitelesítés funkció hozzáadva.). Ez a commit rögzíti a kódbázis állapotát a funkció bevezetése után.

Amikor egy fejlesztő kijavít egy hibát, a commit üzenet általában a hiba azonosítószámára utal a projekt hibakövetési rendszerében.

A tag-ek (címkék) névre szóló hivatkozások bizonyos commitokra. Általában a projekt történetének jelentős pontjait jelölik, például releaseket vagy mérföldköveket. A tagekkel a kódbázis fontos verzióit lehet megjelölni és hivatkozni rájuk, megkönnyítve ezzel a projekt történetének kezelését és a benne való navigációt.

A branch-ek (ágak) akkor jönnek szóba, amikor a fejlesztőknek különböző feladatokon kell egyidejűleg dolgozniuk. A branchek független fejlesztési vonalak, amelyek eltérnek a fő kódbázistól. Lehetővé teszik a fejlesztők számára, hogy elszigetelten dolgozzanak a funkciókon vagy javításokon anélkül, hogy befolyásolnák a fő kódot, amíg készen nem állnak az integrációra. Segítenek megszervezni a fejlesztést és megkönnyítik a csapattagok közötti együttműködést.

Ha például az egyik fejlesztő egy új funkció hozzáadásán dolgozik, míg egy másik egy hibát javít, mindketten külön bancheket hozhatnak létre a változtatások elkülönítése érdekében. Ha a munkájuk befejeződött, a brancheiket tudják egyesíteni (merge) a fő kódbázisba (Branches).

Amikor több ember dolgozik ugyanazon a fájlon, vagy egy másik branchre checkolja be a változtatásokat, előfordulhat, hogy két ember változtatott ugyanazon a soron egy fájlban. Amikor a második változtatást végző személy megpróbálja becheckolni a változtatást, a rendszer conflict-ra figyelmeztet.

Néhány VCS egyszerűen nem engedi meg a fejlesztőnek, hogy akkor checkoljon be egy fájlt, ha az conflictot tartalmaz a repositoryban lévő aktuális verzióval. A fejlesztőnek meg kell néznie az aktuális verziót, és ki kell találnia, hogyan oldja fel a conflictot, majd be kell checkolnia egy új verziót.

A felhőalapú rendszerek merge vagy pull requesteket biztosítanak. Ezeket egy olyan fejlesztő hozza létre, aki egy lokális rendszeren vagy branchen dolgozott, és úgy gondolja, hogy a változtatásai alkalmasak arra, hogy azokat beépítsék egy másik branchbe. A cél-branch fejlesztői döntenek arról, hogy elfogadják-e a kérést.

Gyakran előfordul, hogy egy másik, független projekt (pl. egy médialejátszó) kódjára van szükség egy szoftverprojekt (pl. egy komplex weboldal) fejlesztéséhez. Ahelyett, hogy a médialejátszó kódját részben vagy egészben átmásolnánk a saját projektünkbe, sok VCS kínálja a subrepositoryk, más néven submodulok funkciót.

Példánkban a médialejátszó repositoryja a weboldaléba van integrálva, mint egy subrepository. Ezután külön mappaként jelenik meg a könyvtárfában. Ez azt jelenti, hogy a médialejátszó kódbázisa teljes mértékben elérhető, de független marad. Szükség esetén akár a médialejátszó eredeti repositoryjából is frissíthető.

Ez a képesség értékesnek bizonyul a számos függőséget tartalmazó bonyolult projektek kezelésében vagy harmadik féltől származó könyvtárak és keretrendszerek kódbázisba történő integrálásában. Az almodulok javítják a projektszervezést és megkönnyítik az együttműködést, mivel lehetővé teszik a fejlesztők számára, hogy hatékonyan dolgozzanak egymással összekapcsolt kódbázisokon keresztül.

A projekt minden résztvevője egy identitás létrehozásával kezd, amely általában a résztvevő egyedi e-mail címéhez kapcsolódik. Egy felhőalapú rendszer fiókokon keresztül kezeli az identitásokat, ahogyan azt a közösségi médiaoldalak és más szervezetek is teszik.

Az új fejlesztők egy SCM rendszer használatakor a következőkön mennek keresztül:

A projektvezetők döntik el, hogy kiben bíznak meg, és kinek adnak hozzáférést a repositoryhoz. A vezető fejlesztők fontos feladata eldönteni, hogy a többi közreműködő által benyújtott változtatások mikor kerülhetnek be a fő branchbe.

A felhőalapú rendszerekben a projekt tulajdonosa szabályozhatja a repository hozzáférhetőségét azáltal, hogy a láthatóságot nyilvános vagy privát állapotra állítja. A nyilvános repositoryk az interneten bárki számára olvasási hozzáférést biztosítanak. A privát repositoryk viszont kizárólag a tulajdonosra, valamint azokra a személyekre korlátozzák a hozzáférést, akikkel a tulajdonos kifejezetten megosztotta azt, szervezeti repositoryk esetében pedig a szervezet meghatározott tagjaira.

Képzeljünk el egy fejlesztőcsapatot, amely egy e-kereskedelmi weboldalon dolgozik. Úgy döntenek, hogy hozzáadnak egy új funkciót, amely lehetővé teszi a vásárlók számára, hogy nyomon kövessék a rendeléseiket. A funkció megvalósításához létrehoznak egy feature branchet, például order-tracking néven, ahol a szükséges kódmódosításokon dolgozhatnak anélkül, hogy a fő kódbázist befolyásolnák. Amint a funkció elkészült és tesztelve lett, ezt az branchet mergelik a fő development branchbe további integráció és tesztelés céljából.

A fő development branch központi hubként szolgál, ahol az összes új funkciót összegyűjtik a teszteléshez. Ha például több fejlesztő egyidejűleg dolgozik különböző funkciókon, akkor a fejlesztési branchbe mergelhetik a funkció brancheket, hogy minden zökkenőmentesen működjön együtt. Ez az integrációs folyamat segít az esetleges conflictok vagy kompatibilitási problémák korai felismerésében és megoldásában.

Amikor eljön az ideje annak, hogy kiadják az e-kereskedelmi weboldal új verzióját, a csapat létrehoz egy release branchet a development branchről, például v2.0-t. A zökkenőmentes release érdekében a kódbázis stabilizálására, az utolsó pillanatban felmerülő hibák kijavítására és alapos tesztelésre összpontosítanak. Amint a release elkészül, a release branch kódját élesítik, és a ciklus kezdődik elölről.

A legismertebb verziókezelő rendszerek a Git, a Subversion (más néven SVN) és a CVS. Ezek mindegyike nyílt forráskódú.

A Git egy elosztott verziókezelő rendszer, amelyet széles körben használnak a szoftverfejlesztésben és más területeken. A Git használatakor minden fejlesztőnek megtalálható a saját számítógépén a kódbázis egy teljes másolata.

Ez a decentralizált megközelítés lehetővé teszi a fejlesztők számára, hogy offline dolgozzanak és zökkenőmentesen együttműködjenek anélkül, hogy központi szerverre támaszkodnának. Vagyis a fejlesztők egymástól függetlenül dolgozhatnak különböző funkciókon vagy javításokon, és változtatásaikat zökkenőmentesen egyesíthetik. Még ha a központi szerver offline is megy, a fejlesztők folytathatják a munkát, és megoszthatják egymással a frissítéseket.

Vegyük például a Linux kernel fejlesztését, amely kezdetben a BitKeeper nevű központi verziókezelő rendszerre támaszkodott. Amikor a BitKeeper ingyenes státuszát visszavonták, Linus Torvalds és a Linux közösség kifejlesztette a Git-et, mint elosztott alternatívát. Ez a döntés lehetővé tette a nem-lineáris fejlesztést és az olyan nagy projektek hatékony kezelését, mint a Linux kernel. A Git sikere a Linux kernel esetében — egy rendkívül összetett projekt több ezer fejlesztővel és számtalan branchhel — prezentálja a Git erejét és skálázhatóságát.

A legtöbb szoftverfejlesztés manapság a Git-et használja. Rendkívül népszerű SaaS termékek épülnek rá.

A Git úgy kezeli a conflictokat, hogy a fejlesztőnek egy fájlt ad a módosított sor mindkét verziójával, egyértelműen megjelölve, hogy a sorok a fájl melyik verziójából származnak. A fejlesztőnek el kell döntenie, hogyan oldja fel a conflictot, és be kell checkolnia a fájl koherens verzióját.

A Subversion (SVN) valószínűleg a legnépszerűbb SCM rendszer volt a Git feltalálása előtt. A Gittől eltérően a Subversion centralizált: a verziótörténet egy központi szerveren található. A fejlesztők ezen a szerveren végzik el a változtatásokat, így biztosítva azt, hogy mindenki a kódbázis legfrissebb verziójával dolgozik.

Tegyük fel, hogy egy olyan csapat tagjai vagyunk, amely egy Subversiont használó projekten dolgozik. Minden alkalommal, amikor változtatásokat kell végrehajtanunk a kódbázisban, csatlakozunk a központi SVN-kiszolgálóhoz, hogy ellenőrizzük a kód egy működő példányát. Ez biztosítja, hogy a projekt legfrissebb verziójával dolgozunk. Miután elvégeztük a módosításokat, commitoljuk azokat a szerverre, frissítve a központi repositoryt a változtatásokkal. A központosított munkafolyamat segít fenntartani a következetességet, és biztosítja, hogy mindenki ugyanazokért a célokért dolgozik.

A Subversion előtt a CVS egy nagyon népszerű, központosított verziókezelő rendszer volt. Tervezési problémái voltak, ezek vezettek a Subversion, mint alternatíva megtervezéséhez.