Projekteszközök, verziókezelés

Projektmenedzsment eszközök

Szoftvereszközök

A fejlesztőcsapat munkáját megfelelő szoftvereszközökkel kell alátámasztani

  • projektmenedzsment eszközzel (project tracking system), amely támogatja a dokumentálást és a feladatok követését
  • fejlett tervezőeszközzel (case tool), ahol a fejlesztés folyamata és a felelősség is nyomon követhető
  • integrált fejlesztőkörnyezettel (IDE)
  • verziókövető rendszerrel (revision control system), amely lehetővé teszi a programkód változásainak követését
  • folytonos integrációs (continuous integration) rendszerrel, amely biztosítja a hibák korai kiszűrését

A projektmenedzsment eszköz lehetőséget ad az alábbiakra:

  • fejlesztés ütemtervének, kockázatainak meghatározása
  • fejlesztés egyszerű és folyamatos dokumentálásának lehetősége és generálása
  • feladatok, tevékenységek rögzítése, követése
  • a tesztelés során előfordult hibák rögzítése, a javítási folyamat követése
  • integrált verziókezelés és forráskód böngészés
  • webes vagy grafikus felület, amely biztosítja a könnyű használatot, és bárhonnan való elérést

Ütemterv és időzítés

A szoftver lehetőséget ad, hogy a projekt ütemtervét elkészítsük, és azt folyamatosan szem előtt tarthassuk

  • definiálhatunk mérföldköveket (milestone), amelyre adott feladatokat el kell végezni
  • a fejlesztők külön-külön láthatják a saját feladataikat, menedzselhetik annak előrehaladását
  • beoszthatjuk a fejlesztési lépések erőforrásait
  • definiálhatunk függőségeket a programrészek között
  • kezelhetjük az egyes fejlesztési lépések időbeli lefolyását, előrevetíthetjük a tervezettől való eltérések hatásait az erőforrásokra, illetve a további fejlesztési időkre

Feladat és hibakövetés

A rendszerek lehetőséget adnak a tervezők számára feladatok kitűzésére, valamint a tesztelők számára a programban fellelhető hibák jelzésére

  • a feladatokat úgynevezett cédulák (ticket, issue) segítségével írhatóak ki
    • jelölhetnek új funkcionalitást (feature), hibát (bug), egyéb fejlesztési feladatot (task), vagy dokumentációs feladatot (documentation)
    • megadható a leírása, felelőse, határideje
    • kommentálhatóak, lezárhatóak, újra kinyithatóak
  • a cédulák biztosítják a fejlesztési és tesztelési folyamat naplózását

Projektvezető szolgáltatások

A projektvezető szolgáltatások (project hosting services) általában rendelkezésre bocsátanak több projektfejlesztő eszközt

  • projektmenedzsment, kód tárolás, kód megtekintés, verziókövetés, dokumentáció (Wiki), levelezési lista, adatbázis hozzáférés
  • általában nyílt forráskódú szoftverek esetén ingyenes a szolgáltatás
  • pl.:GitHub, GitLab, SourceForge, Bitbucket
  • egyes szolgáltatások bizonyos programozási nyelvek, vagy témakör köré csoportosulnak (pl. mozdev)

Verziókezelés

A szoftverek méretének és komplexitásának növekedésével létrejött szoftverkrízis következményeként megnövekedett:

  • a programok forráskódjának mérete,
  • a szoftverprojektek megvalósításához szükséges idő,
  • és szükséges programozói erőforrás.

A szoftveripar fejlődésével egyre több alkalmazás készült

  • a fejlesztések életciklusa gyakran nem ért véget a program első publikus verziójának kiadásával,
  • karbantartási és további fejlesztési fázisok követték.

A szoftverprojektek méretben, komplexitásban, időben és a résztvevő fejlesztők számában is növekedni kezdtek.

Történeti háttér

Mivel az implementáció tehát több lépésben, és sokszor párhuzamosan zajlik, szükséges, hogy az egyes programállapotok, jól követhetőek legyenek, ezt a feladatot a verziókövető rendszerek (revision control system) látják el

  • pl. CVS, Apache Subversion (SVN), Mercurial, Git
  • egy közös tárolóban (repository) tartják kódokat
  • ezt a fejlesztők lemásolják egy helyi munkakönyvtárba, és amelyben dolgoznak (working copy)
  • a módosításokat visszatöltik a központi tárolóba (commit)
  • a munkakönyvtárakat az első létrehozás (checkout) után folyamatosan frissíteni kell (update)

Funcionalitás

A verziókövető rendszerek lehetővé teszik:

  • az összes eddig változat (revision) eltárolását, illetve annak letöltési lehetőségét
  • a fő fejlesztési vonal (baseline, master vagy trunk) és a legfrissebb változat (head) elérését, új változat feltöltését annak dokumentálásával
  • az egyes változatok közötti különbségek nyilvántartását fájlonként és tartalmanként (akár karakterek szintjén)
  • változtatások visszavonását, korábbi változatra visszatérést
  • konfliktust okozó módosítások ellenőrzését, illetve megoldását (resolve)
  • a folyamat elágazását, és ezáltal újabb fejlesztési folyamatok létrehozását, amelyek a fő vonal mellett futnak (branch), valamint az ágak összeillesztését (merge)
    • az összeillesztés rendszerint utólagos manuális korrekciót igényel
    • az összeillesztésnek rendszerint automatikusan illeszti a módosított tartalmakat kódelemzést használva, ez lehet 2 pontos (two-way), amikor csak a két módosítást vizsgálja, vagy 3 pontos, amikor az eredeti fájlt is
  • programrészek zárolását (lock), hogy a konfliktusok kizárhatóak legyenek
  • adott verzió, mint pillanatkép (snapshot) rögzítése (tag), amelyhez a hozzáférés publikus
  • feltöltések atomi műveletként történő kezelését (pl. megszakadó feltöltés esetén visszavonás)

Lokális verziókövető rendszerek

Forráskód változásainak követése, a szoftver funkcióinak különböző kombinációjával készült kiadások kezelése

  • lokális tároló (de többen is elérhetik pl. mainframe esetén)
  • fájl alapú műveletvégzés (1 verzió 1 fájl változásai)
  • konkurenciakezelés kizárólagos zárak által

Az 1970-es években lefektetésre kerültek az elméleti alapok

  • Source Code Control System (SCCS) – 1972
  • Revision Control System (RCS) - 1982

Centralizált verziókezelő rendszerek

Több fejlesztő általi párhuzamos szoftverfejlesztés támogatásának előtérbe kerülésre

  • centralizált modellt megtartva, de kliens-szerver architektúra
  • fájlhalmaz alapú műveletek (1 verzió több fájl változásai)
  • konkurenciakezelés jellemzően beküldés előtti egyesítéssel (merge before commit)

Az 1990-es évektől terjedtek el:

  • Concurrent Versions System (CVS)
  • Subversion (SVN)
  • SourceSafe, Perforce, Team Foundation Server, stb.

Hátrány: a szerver kitüntetett szerepe (pl. meghibásodás), továbbá a verziókezeléshez hálózati kapcsolat szükségeltetik

Elosztott verziókezelő rendszerek

A klasszikus verziókezelő műveletekről leválasztásra kerül a hálózati kommunikáció, azok a felhasználó által kezdeményezhető önálló tevékenységekként jelennek meg

  • decentralizált, elosztott hálózati modell
  • minden kliens rendelkezik a teljes tárolóval és verziótörténettel
  • a revíziókezelő eszköz műveletei lokálisan, a kliens tárolóján történnek
  • a kommunikáció peer-to-peer elven történik, de kitüntetett (mindenki által ismert) szerverek felállítására van lehetőség
  • konkurenciakezelés jellemzően beküldés utáni egyesítéssel (commit before merge)

A 2000-es évek első felében jelent meg:

  • Monotone, Darcs, Git, Mercurial, Bazaar, stb.

Változások reprezentációja

A teljes revíziók tárolása nem lehetséges az adattárolás és adatkezelés jelentős költségei miatt

A verziókezelő eszközök ezért csak két egymást követő verzió közötti különbséget, a változáslistát (changeset, delta) tárolják

  • egyes rendszerek (pl. Mercurial) időnként pillanatfelvételt (snapshot) készítenek a teljes tartalomról

Eleinte (SCCS) a delták a régi verzióból az újat tudták előállítani (forward deltas)

Korán felmerült (RCS), hogy a fordított delták (reverse deltas) használata a legújabb verzió pillanatképének tárolásával jobb teljesítményt nyújthat, ugyanis leggyakrabban egy ág legfrissebb állapotát szokták lekérni

  • Kevert megoldás is lehetséges, pl. a fő ágon fordított irányú deltákat, a mellékágakon viszont előre mutató delták

Az eltérések meghatározása szöveges fájlok, így programnyelvi forráskódok esetében jellemzően állapot alapúan történik

  • a legtöbbször soronkénti összehasonlítással
  • pl. GNU diff
  • struktúrált tartalom esetén az összehasonlítás egysége más is lehet (pl. XML, JSON, UML)

Bináris adatok (pl. képek) esetén a művelet alapú megközelítés is alkalmazható.

A 3. generációs verziókövető rendszerek idejére a háttértárak mérete jelentősen megnőtt, míg költségük csökkent

  • Egyes eszközök ezért a megváltozott fájlok teljes tartalmát tárolják a revíziókban, nem csak a módosult tartalomrészt

Külömböző fájlok tárolása

A Git verziókezelő rendszer a szöveges állományok, így tipikusan a forráskód fájlok változáskezelésében hatékony. Elsődlegesen a projekt forráskódját érdemes benne elhelyezni.

Egy általános szoftver projekt esetén nem érdemes verziókezelés alá vonni:

  • fordítás során előálló köztes tárgykódot vagy a végső bináris állományokat, mert újból előállíthatóak, folyamatosan változnak és ütközéseket okoznak.
  • fejlesztő eszközök személyes beállításait (pl. Visual Studio esetén a .vs/ vagy Netbeans esetén a nbproject/private/ könyvtárak), amelyek felhasználónként eltérőek.
  • nagy méretű bináris állományokat (pl. videók, nagy méretű képek), amelyek kezelésében a Git nem hatékony. Bár a Git tárolók mérete jól skálázható, egy könnyen kezelhető repository mérete az 1-2 GB-os méretet nem haladja meg.

A nagy méretű videó, kép és hang erőforrás állományok hatékony kezelése körültekintést igényel.

  • A nagy méretű bináris állományok változásainak kezelésében a Git kevésbé hatékony.
  • Jelentősen megnöveli a tároló helyi másolatának lekéréséhez szükséges hálózati forgalmat (git clone).
  • Egy fejlesztőcsapatban a programozóknak nem feltétlenül van szükségük a fejlesztéshez a designerek által készített assetekre.

Ezért a nagy méretű bináris erőforrás állományokat még akkor sem feltétlenül érdemes a Git tárolóban elhelyezni, ha amúgy ritkán változnak.

A nagy méretű bináris állományok kezelése a Git Large File Storage (Git LFS) segítéségével oldható meg.

  • A nagy méretű bináris állományokat egy hivatkozással helyettesíti és magukat a fájlokat egy másik (akár távoli) szerveren tárolja.
  • Így a Git tárolónk mérete kezelhető marad.

Gitflow feature branching model

Fő fejlesztési ágak:

  • master
  • develop

Támogató ágak:

  • feature branches
  • release branches
  • hotfix branches

Források