Az elmúlt két hétben a VSTS segítségével a késõbb mintának szánt website fejlesztési projekten dolgoztam, dolgoztunk gõzerõvel. Elsõ lépésben a projekt feladatok, a kód verziókezelés, és a hibák kezelését tettük be a rendszerbe. A projekten jelenleg “csak” hárman dolgoztunk, egy fejlesztõ (jómagam) és két projektvezetéssel és tesztelésre felkért kolléganõ. A dolog érdekessége, hogy az alapvetõ feladatok kezeléséhez a projektvezetõi, tesztelõi szerepkörhöz jelenleg nem telepítettük a Team Explorer-t, azok elérhetõségét az ingyenesen telepíthetõ Team System Web Access modullal biztosítottuk.

Team Server Web Access Nyitóoldal

Módszertan és projektvezetõi oldal

A demó projektünk az MSF for Agile fejlesztési módszertanon alapul.

Akik kicsit is foglalkoztak az MSF-el azok most azonnal megértik, hogy az Agilis fejlesztési módszertan biztosítja számunkra azt a nagyfokú rugalmasságot ami egy website fejlesztése során szükséges, és mégis kikényszeríti azokat a formalizált eljárásokat, amelyek nélkül nem lehet használható megoldást csinálni már egy kisebb projekt esetében sem. (Részletsebb megismeréshez lásd az MSDN módszertani oldalait)

Az agilis módszertan lehetõvé teszi nekünk, hogy a formális kérdésekkel a lehetõ legkevésbé foglalkozzunk, azt csak a munka elkészítéséhez szükséges mértékig rögzítsük és dokumentáljuk. E módszertan azonban azt is követeli, hogy a szükséges mértékig dokumentáljuk mindazt amit el kell készíteni. Minderre a TFS-ben gyárilag rögzített módszertani szabályrendszer gondoskodik. (Sõt gyárilag elõkészített formalizált dokumentumokkal vezette a kezünket a szükséges dokumentumok létrehozása érdekében).

Nos a projekt alapvetõ szabályainak létrehozása és feladatdefinícióit követõen máris a tényleges munka közepén találtuk magunkat. Elsõ lépésben a projekt tulajdonképpeni meta adatait az Area-t és az Iteration kérdéskört definiáltuk. Az Area részben rögzítettük a website elkészítésének feladati témaköreit (mondhatni a horizontális részt), míg az Iteration rész alatt az idõbeli elõrehaladás során létrejövõ idõben elhatárolt fejlesztési etapokat (vertikális rész). Második lépésben a projekt feladatait rögzítõ TASK elemeket vettük fel (külön-külön minden igényt, hogy a késõbbiekben önállóan kezelhessük a velük kapcsolatos történéseket).

Ezt követõen – tekintettel arra, hogy a kódbázis meglévõ része már betöltésre került, és a szükséges projekt security beállítások is megvoltak – a tényleges feladatmegoldás volt hátra.

Fejlesztõi oldal

Fejlesztés

A munka során a fejlesztéshez a Visual Studio 2008 Team System Developer-t használtuk, mely nagyon jól használhatónak bizonyult a CSS alapú website fejlesztése során (A Visual Studio 2005 használata során a master page és az ettõl elétrõ részen, szinten lévõ tartalmi oldalak használata nem volt ennyire kényelmes – jól érezhetõ, hogy a 2008-as verzió esetén jelentõsen fejlesztették ezt az oldalt. A VS 2008 TS for Developer Beta 2 használata során mindössze az ASPX oldalak szerkesztése során találkoztunk egy bosszantó hibával, nevezetesen a Ctlr+Z hatására a rendszer a memóriában tárolt tényleges fájl kódszövegét elrontotta, de ezt csak az oldal elmentése, kilövése majd visszatöltése során vehetõ észre).

Munkában a TFS és a Visual Studio

A munka során elsõre kicsit furcsa volt, hogy minden feladatot – legyen az a feladatok, bugok kezelése, az adatbázis kezelése, vagy akár a tényleges fejlesztés – a VS-ben oldottunk meg. Mondom elsõre szokatlan volt, de rövid idõ alatt megszokva már nagyon sokat segített és felettébb gyorsá tette a “mit kell épp csinálnom” kérdésre a válaszok megadását.

Kódverziók kezelése

A másik újdonság a kódverziók kezelése. Errõl elmondhatom, hogy a lehetõ legjobb élményekkel ajándékozott meg a TFS. Lassan tíz éve, hogy a Visual Source Safe rendszerrel kezelem a Visual Studio fejlesztéseim kódjait. Számos helyzetben “mentett már meg” és még az egyedül végzett munkáim kapcsán is használom. A VSS sajnos alapvetõen file share alapú, és ebbõl adódóan nem egy kapkodós megoldás. (Tudom a http-n keresztül is lehet használni, de hát én már csak ilyen maradi voltam.)

TFS forráskód kezelõ

A VSS-el a távolból végzett munkavégzés sok esetben igen nehézkes volt, mert a VPN-en keresztül a file share alapú projektnyitás és kódkezelés igncsak lassú volt (ne feledjük, hogy ez az egyszerû oldal is jelentõs mennyiségû közel 500 objektumot tartalmaz). E problémát a TS által nyújtott verziókezelés, ami a továbbiakban már WebService alapon mûködött bámulatosan jól megoldotta. A távoli munkavégzés során is gyakorlatilag azonos sebességgel tudtam a projektet megnyitni mintha LAN-on lennék (természetesen ez csak a megnyitáskor történõ ellenõrzésekre és nem a fájlok letöltésére vonatkozik – a VSS már az ellenõrzést is csak mintegy 1-3 perc között tudta megoldani, és ha bele akartam scrollozni a listába akkor…).

Kellemes tapasztalás volt a verziókezelõben elõre létrehozható és ott tárolt Workspace területek definiálása, amelyet minden fejlesztõi ponthoz külön-külön lehet megadni, ami jelentõs segítség volt. Az elmúlt két hétben sok esetben segített a rendszer a gyors és pontos munkavégzésben, bár be kell vallanom még közel sem használom ki az általa nyújtott lehetõségeket. A továbbiakban biztos jelentõs figyelmet fogok e modul felhasználásának szentelni, hisz jelentõs erõtartalék van még benne.

Tesztelõi oldal

Tekintettel arra, hogy a website elsõ lépésben elsõdlegesen statikusnak mondható a tesztelés most nem a módszertanban megadott és elfogadott tesztelésen alapult, hanem csak az elkészült feladat, a javított bug ellenõrzésén. Ez a rész az elmúlt idõszakban felettébb hasznosnak bizonyult, mert a párhuzamos és folyamatos munkát nagyban megkönnyítette. A teszteléssel megbízott kollégák gyorsan és könnyedén tudták kezelni a feladatokat és a bugokat.

Bejelentett hiba állapotváltozásainak megjelenítése

A tapasztalatok alapján kijelenthetjük, hogy e piciny és apró szelete a rendszernek jelentõs segítséget nyújtott az elvárt szint kialakításának elérésében. A felhasználói élmény, a mûködési sebesség teljes mértékben kielégítette az elvárásokat (amit ma egyre ritkábban lehet a szoftverpiacon kapható termékekrõl elmondani).

Projekt állapotának követése

A mostani esetben a TFS használatának elsõdleges célja annak megismerése és a mindennapos használatba való minél gyorsabb bevonása volt. A projektmenedzsment nem volt annyira hangsúlyos, mint kellett volna, de hát emberek vagyunk mi is és elsõre ezt az akadályt nem a legjobban ugrottuk meg. Ettõl függetlenül azért folyamatosan követtük és ellenõriztük az egyes gyári kimutatások által adott eredményeket.

A rendszer számos módon segíti a munka állapotának követését, de most álljon itt csak a számomra a fejlesztõk és tesztelõk munkáját folyamatosan monitorozó kedvencem kimutatásom.

Ez a kimutatás napi szinten képet ad a fejlesztés és a munka aktuális állapotáról. Ha csak ennyit látunk máris képet alkothatunk arról, merre is járunk a munkában, és mikor jutunk egy épp publikálható változat közelébe.

Sajnos e részt egyáltalán nem tekintem megismertnek, ezt még csak kóstolgatom, és csak a késõbbiek hozzák majd meg ennek megismerését.

Értékelés

Az elsõ két hét eredményeinek értékelése alapján határozottan lelkes vagyok, lelkesek vagyunk, mert számos a fejlesztés során eddig problémát jelentõ kérdésben valódi megoldást tudott nyújtani a team system. Megismerése nem oly egyszerû mint szeretnénk, de hát maga a fejlesztés sem a legegyszerûbb folyamat.