056.2 Lecke 1
Tanúsítvány: |
Open Source Essentials |
---|---|
Verzió: |
1.0 |
Témakör: |
056 Kollaboráció és kommunikáció |
Fejezet: |
056.2 Forráskódmenedzsment |
Lecke: |
1 of 1 |
Bevezetés
Bárki, aki valaha is szerkesztett már szöveges dokumentumot egy csapat tagjaként, ismeri az együttműködéssel kapcsolatos problémákat: melyik verzió az aktuális? Hol van ez a verzió elmentve? Éppen most szerkeszti valaki? Ki milyen megjegyzéseket vagy változtatásokat tett a szöveghez — mikor és miért? Eredményként gyakran a dokumentumuk különböző változatait kapjuk, legrosszabb esetben pedig a változatok olyan gyűjteménye jön létre, amelyet senki sem ismer.
Most képzeljünk el egy több száz fájlból álló szoftverprojektet, amelyen fejlesztők a világ minden tájáról dolgoznak, új funkciókat fejlesztve, hibákat javítva, részeket leválasztva és azokon külön dolgozva, és így tovább. Egy ilyen fejlesztési folyamat megfelelő eszközök nélkül már nem kezelhető.
A forráskódmenedzser (soruce code management — SCM), más néven verziókezelő rendszerek (version control system — VCS) vagy revíziókezelő rendszerek (revision control systems — RCS) speciális szoftverek, amelyek erre nyújtanak megoldást. Ez kiküszöböli a fentebb vázolt problémákat.
A szoftverfejlesztés világában az SCM alapvető pillérként védi a kódbázis integritását. Képzeljük el úgy, mint egy szorgalmas őrt, aki aprólékosan nyomon követi a forráskód minden egyes változtatását és módosítását az idők során.
Forráskódmenedzsment-rendszer és a repository
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.
Commitok, tagek és branchek
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).
![branches](images/branches.png)
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.
Subrepositoriek
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 forráskódmenedzser-rendszer általános használata
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:
-
Az SCM szoftver telepítése, ha az még nincs az operációs rendszerben.
-
A teljes projekt egyszeri átvitele a helyi rendszerre, más néven klónozás (cloning).
-
Ettől a lépéstől kezdve lokálisan dolgozik (egy vagy több branchen, ha szükséges), és pusholja a változtatásokat a repositoryba.
-
A következő munkamenet előtt lehúzza (pull) legfrissebb verziót a repositorybó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.
Gyakori verziókezelő rendszerek
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.
Gyakorló feladatok
-
Nevezzük meg az SCM-rendszerek három fő jellemzőjét!
-
Ismertessük a tagging (címkézés) fogalmát az SCM-rendszerekben, és magyarázzuk el, miért fontos ez a szoftver releasek kezelésében!
-
Mi a különbség egy SCM rendszer esetén a branch és a subrepository között?
Gondolkodtató feladatok
-
Hasonlítsuk össze a Git és a Subversion (SVN) architektúráját és workflowját!
-
Mi az az “index” vagy “staging area” a Gitben?
-
Vázoljuk fel a Git trunk-alapú branchelési stratégiáját!
-
Az alábbi SCM rendszerek közül melyik nyílt forráskódú?
Git
Mercurial
Subversion
GitHub
Bitbucket
GitLab
Összefoglalás
Ez a lecke a forráskódmenedzser rendszerek központi szerepét ismertette a modern szoftverfejlesztésben. Megtanultuk az alapvető kifejezéseket és a rendszer használatának módjait, beleértve a repositoryt, a brancheket, a tageket és a mergeket.
Válaszok a gyakorló feladatokra
-
Nevezzük meg az SCM-rendszerek három fő jellemzőjét!
-
A forráskód módosításainak naplózása
-
A fejlesztők forráskódhoz való (egyidejű) hozzáférésének kezelése
-
A fájlok vagy a teljes projekt bármely fejlesztési állapotának visszaállítása
-
-
Ismertessük a tagging (címkézés) fogalmát az SCM-rendszerekben, és magyarázzuk el, miért fontos ez a szoftver releasek kezelésében!
A címkézés az a gyakorlat, amelynek során a kódbázisban található egyes commitokhoz leíró címkéket vagy neveket rendelünk, amelyek a projekt történetének fontos pontjait, például releaseket vagy mérföldköveket jelölnek. Ezek a címkék kényelmes megoldást kínálnak a kódbázis egyes verzióira való hivatkozáshoz és a projekt időbeli fejlődésének nyomon követéséhez.
-
Mi a különbség egy SCM rendszer esetén a branch és a subrepository között?
A branch egy párhuzamos fejlesztési vonal a projektben, például hibajavítás vagy új funkciók fejlesztése céljából, amelyet általában visszamergelnek a fő branchbe, amint a feladattal végeztek. A subrepository vagy sumbmodul egy független projekt, amelynek repositoryját egy projektbe integrálják, hogy hozzáférjenek annak kódbázisához. A subrepository mappaként jelenik meg a projekt könyvtárfájában, és független marad.
Válaszok a gondolkodtató feladatokra
-
Hasonlítsuk össze a Git és a Subversion (SVN) architektúráját és workflowját!
A Git egy elosztott verziókezelő rendszer (distributed version control system — DVCS), amely lehetővé teszi, hogy minden fejlesztő rendelkezzen a kódbázis teljes másolatával, és akár offline is dolgozhasson a forráskódon. A Git széles körű népszerűségre tett szert a fejlesztők körében a gyorsasága, rugalmassága és robusztus branching és merging képességei miatt. Az SVN egy központosított VCS, a verziótörténet egy központi szerveren található. Központosított jellege és kiforrott funkciókészlete miatt továbbra is népszerű bizonyos vállalati környezetekben.
-
Mi az az “index” vagy “staging area” a Gitben?
Az index vagy a staging area egy köztes réteg a projekt helyi munkapéldánya és a szerveren lévő aktuális verzió között. Ez egy olyan fájl, amelyben a felhasználó következő commitjához szükséges összes információ tárolódik.
-
Vázoljuk fel a Git trunk-alapú branchelési stratégiáját!
A trunk-alapú fejlesztés olyan stratégia, amely a változások gyakori integrálását hangsúlyozza a fő kódbázisba (trunk). A fejlesztők rövid életű funkcióbrancheken dolgoznak, és ezeket naponta többször mergelik a trunkba, így biztosítva a folyamatos integrációt és a gyors visszajelzést.
-
Az alábbi SCM rendszerek közül melyik nyílt forráskódú?
Git
X
Mercurial
X
Subversion
X
GitHub
Bitbucket
GitLab
X