Forráskódjaink tárolására és a változtatások nyílvántartására verziókezelő rendszereket használunk. De hogyan oldjuk meg több fejlesztővel a párhuzamos fejlesztést? Mi működik és mi nem vállalati környezetben? Keressünk választ együtt ezekre a kérdésekre.
A verziókezelő rendszerek már régóta léteznek. A kedvencünk a GIT is már 2005-ben debütált. Akit érdekel a történetük az okulhat a wikipédia erről szóló szócikkében. Version Control System (VCS)
A verziókezelés palettája
Több rendszer is létezik amiben a forráskódunkat nyílván tudjuk tartani. Ezek főleg logikailag különböznek egymástól.
Az SVN (Subversion) abban különbözik a Mercurial-tól vagy a GIT-től, hogy csak egy központi kódbázissal dolgozik. Ezzel ellentétben az utóbbi kettőnél helyi kódbázisokkal (repository) dolgozunk és ezek alapján szinkronizáljuk a változtatásokat a központi kódbázissal.
A Mercurial és a GIT nagyon hasonlóak egymáshoz. Fejlesztő válogatja miért gondolja az egyiket jobbnak a másiknál. Számomra GIT-el kezdődtek a verziókezelés kalandok annak idején, így ez is maradt az a rendszer amit behatóan ismerek és használok.
Scale like the pros
A GIT nagy előnye, hogy bármilyen mukafolyamatot is használunk, nagy valószínűséggel támogatni fogja.
Saját projektjeink otthona
Könnyedén használhatjuk saját projektjeink nyilvántartására és megosztására. Ehhez az elkészült vagy éppen készülő forráskódunk könyvtárában inicializáljunk egy kódbázist (repót) és a változtatások rögzítése után adjunk meg egy ‘origin’ szervert ahova fel tudjuk küldeni a forráskódot.
Még mindig sok olyan tárhely van ahol SSH elérést nem engedélyeznek, így igazán jó deploy folyamatot sem lehet az oldalunkon használni. De lehetséges, hogy nincs is ilyenre szükség egy apró projekt esetében. Ilyenkor a forráskódunk helyben és a szerveren is létezik és általában egy IDE szinkronizálja fel a szerverre a változtatásainkat.
Ebben az esetben nem szükséges a szerveren GIT-nek lennie, mert nyugodtan verziókövethetjük a helyi gépen lévő forráskódot is.
Workflow ilyenkor új projekt esetén:
- IDE-ben létrehozzuk az új projektet és az FTP kapcsolatot
- Inicializáljuk a GIT-et a helyi gépen
git init - Rögzítjük a módosításainkat
git addgit commit - Megadjuk a GIT szervert
git remote add origin(Bitbucket vagy Github használata javasolt, de használhatunk saját szervert is) - Feltöltjük a forráskódot
git push
Módosítás esetén csak rögzítjük azokat és feltötjük a szerverre. git add git commit git push Mivel egyedül dolgozunk kis projekteken így végig a ‘master’ branch-ot használhatjuk.
KKV környezet
Akkor kezd érkedes lenni a verziókezelés amikor már több fejlesztő is párhuzamosan használja ugyan azt a kódbázist. Ilyenkor már különböző fejlesztési módszertanok alkalmazása szükséges. Fontos az, hogy minden fejlesztő tisztában legyen ezekkel és tartsa magát a definiált szabályokhoz.
Deploy folyamat és tesztkörnyezet
KKV-k esetén már kiemelten fontos a biztonság és a megbízhatóság. Ezért mindenképpen olyan szervert válasszunk ami SSH elérhetőséggel rendelkezik és egy megbízható deploy folyamat felépíthető rá.
A deploy folyamat olyan automatizált parancsok futását takarja, amik a verziókezelő rendszerben tárolt forráskód alapján publikálják az új verziót a szerverre.
Továbbá érdemes szétválasztani a verziókezelőben az élő és a következő fejlesztésekkel bővített verzió forráskódját. Jó gyakorlat az, hogy a master branch a mindenkori élő oldal kódját tartalmazza, míg a development branch az aktuális tesztverziót.
Ebben az esetben egy automatikus folyamat az éles oldalt frissíti master branch alapján, és egy másik folyamat pedig a teszt környezetet a development branch alapján.
Free-for-all módszertan
Nagyjából ez a módszertan a módszertan teljes hiányát jelöli. Gyakorlatban ez azt jelenti, hogy mindenki a development branch alá dolgozik és oda rögzíti a módosításait. A szabály nélküliség kellemes szabadságot ad, ami bizonyos körülmények között pörgetheti a projektek végrehajtását.
Jól működhet olyan projektek esetén ahol:
- Nincs szükség párhuzamos fejlesztésre. Igaz több fejlesztő dolgozik rajta, de sosem egy időben.
- A fejlesztők külön fájlokon dolgoznak. Párhuzamosan dolgoznak a fejesztők, de sosem ugyan azon fájlokon, így a konfliktus esélye elhanyagolható.
- Gyakorlottak a fejlesztők a konfliktudok feloldásában.
Sok helyen látom gyakorlatban ezt a vadnyugati felfogást. Sajnos gyakran közvetlen a master branch-ba dolgoznak így a fejlesztők, aminek általában probléma és fejfájás a vége.
Habár rugalmas felfogás, de a könnyen bekövetkező káosz miatt nem javaslom ennek a módszertannak a használatát.
Developer branch módszertan
Ennek a módszertannak a lényege, hogy minden fejlesztő rendelkezik egy saját branch-al és a módosításait ebbe gyűjti. Majd ha elkészültek a módosítások, akkor git merge (vagy pull request) segítségével ezek átkerülnek a developer branch alá.
Jól működhet akkor ha:
- Lineáris fejlesztés esetés (agilis kizárva)
- Ha minden fejlesztőnek fix a feladata
- Ha az újrahasználható branch szerkezet opció
Ez is sok helyen gyakorlat, de gyakran szintén fejfájást okoz. A való életben bármennyire is el van tervezve egy projekt, mindig van váratlan módosítás vagy megváltozik a feladatok prioritása. Ilyenkor ez a módszertan nem tud rugalmasan alkalmazkodni a megváltozó igényekhez, és a fejlesztők a már rögzített változtatásaik visszavonására kényszerülhetnek.
Habár egyszerű szabályrendszer, de hiányzó rugalmassága miatt nem javaslom ennek a módszertannak a használatát.
Feature branch módszertan
A módszertan lényege, hogy egy-egy igényelt funkció külön branch-ok alatt kerül lefejlesztésre. Nagy előnye a rugalmassága, hiszen a fejlesztő könnyedén tud váltani a branchok között ha megváltozna a prioritás.
Jól működhet akkor ha:
- Sok fejlesztő dolgozik az adott projekten
- Egy fejlesztő több feladat megoldásán is dolgozik egyszerre
Egyetlen hátránya a módszertannak a skálázhatósága. Általában több mint 10 fejlesztő esetén ha nincs a talpán a vezető fejlesztő, akkor könnyen ez is káoszba fulladhat és minden release rémálommá válhat.
De általánosan kis méretű fejlesztői csapatoknak ez lehet az ideális szabályrendszer.
Nagyvállalati környezet
Itt kezd igazán érdekessé válni a verziókezelés, ha már egy rendszerünk olyan monumentális méretű, hogy különböző részein már akár fejlesztők százai is dolgozhatnak.
Kétségtelen, hogy ilyen méretű rendszereknél már előnyös lehet más CVS alkalmazása is. De a GIT is képes lehet ilyen méretű kódállomány kezelésére, csak a megfelelő megoldást kell megkeresni.
Daraboljuk fel
Igaz a GIT nagyon gyors, de sok fájl könnyen lelassíthatja. Ha logikus részekre fel tudjuk darabolni az alkalmazásunk, ezzel csökkentve a méretét, akkor így gyorsítani is tudjuk a verziókezelőt és csökkenteni a repónkénti branchok és fejlesztők számát.
Feature pack
Tervezett release-ek esetén könnyű meghatározni milyen funkcionalitást kell azoknak tartalmaznia. Ilyenkor ezeket a fejlesztéseket még mielőtt a developer branchba bekerülnének egy feature pack branchba merge-elik össze. Így ezek akár a fő ágtól külön is tesztelhetővé válnak és csak ezen tesztek után van esélyük a ‘staging’ branchba kerülniük. Egy release akár több feature pack-ot is tartalmazhat, így fogva össze a fejlesztők munkáját.
Code review
Nagyvállalatoknál megszokott, hogy valaki átnézi és jóváhagyja a fejlesztők munkáját. Erre tökéletesen alkalmazható a ‘pull request’ logikája.
A pull request egy merge előkészítés, ahol áttekinthetőek a merge által potenciálisan véghezvitt módosítások.
Hasznos eszközök
Nekem személy szerint a dedikált GIT kliensekkel és GUI-kal csak rossz tapasztalatom volt, így ezek használatát nem ajánlanám senkinek.
Ahogy látom két módon lehet használni produktívan a GIT verzikezelőt:
- IDE funkciókat kihasználva
- Csak parancssorból használva
Ha a kedvenc szerkesztőnk támogatja a verziókezelő rendszert vagy különféle pluginek telepítésével tudja támogatni azt, akkor kényelmes megoldás lehet ennek használata. Igaz nem minden esetben egyértelműek ezek használata, de egy kis gyakorlattal hatékony eszköz lehet.
Viszont ha teljes irányítást szeretnénk a verziókezelő felett, akkor kezeljük azt parancssorból. Igaz talán ez a legnehezebb módja a használatának, de mégis így látunk legjobban mögé a működésének. Sajnos hátránya is van, ugyanis nem a legegyszerűbb konfliktust kezelni a parancssorból.
