DEBRECENI EGYETEM INFORMATIKA KAR
Visual Studio Team Foundation Server, Team Build
Témavezetı: Dr. Kuki Attila Egyetemi Adjunktus Külsı témavezetı: Jagó Jácint IT Services Hungary Kft. Head Developer
Készítette: Sipos Nándor Programozó Matematikus
DEBRECEN 2009
1.
BEVEZETÉS..................................................................................................... 3
2.
A TEAM FOUNDATION SERVER .................................................................. 6
2.1 2.2 2.2.1 2.2.2 2.3 2.3.1. 2.3.2. 2.3.3. 2.3.4.
Alapfogalmak .......................................................................................................................................6 Visual Source Safe............................................................................................................................13 A TFS szerkezeti elınyei:.....................................................................................................................14 A TFS Funkcionális elınyei:.................................................................................................................15 A Visual Studio Team System .......................................................................................................18 Team Explorer........................................................................................................................................19 Visual Studio 2008 Team System Architecture Edition ....................................................................20 Visual Studio Team System 2008 Development Edition ..................................................................21 Visual Studio Team System 2008 Test Edition ..................................................................................22
3.
A TEAM FOUNDATION BUILD..................................................................... 23
3.1 3.2. 3.2.2. 3.2.3. 3.2.4. 3.4. 3.5. 3.6. 3.7
A Team Foundation Build áttekintése .........................................................................................24 A Team Foundation Build felépítése ............................................................................................25 Az Application Tier ..................................................................................................................................27 Build Server..............................................................................................................................................27 Build Repository ......................................................................................................................................28 Build adatok specifikációja ............................................................................................................29 Build indítása.......................................................................................................................................34 Buildek elemzése és nyomonkövetése.......................................................................................35 Gyakorlati példa .................................................................................................................................36
4.
BEFEJEZÉS .................................................................................................... 38
5.
KÖSZÖNETNYILVÁNÍTÁS:.......................................................................... 39
6.
FORRÁSOK .................................................................................................... 40
2
1. Bevezetés A rohamosan fejlıdı informatika egyre magasabb színvonalú alkalmazásokat, alkalmazásfejlesztési technológiákat követel. Annak érdekében, hogy a minıségi célok elfogadható idın belül megvalósuljanak, fontos, hogy adott probléma megoldásán, adott project fejlesztésében minél több ember részt vehessen. Ugyancsak lényeges szempont lett, hogy a korszerő, akár több száz fıbıl álló alkalmazásfejlesztıi csapat tagjai, földrajzilag elszigetelve is dolgozhassanak. Az információáramlás ilyen körülmények között meglehetısen nehézkes. Ezért gondolta a Microsoft, hogy érdemes lenne megoldást találni arra, hogy a Developer Team idejének nagy része ne megbeszéléseken, telefonkonferenciákon, vagy levelezéssel teljen. Megalkotta ezért a Visual Studio Team Systemet (VSTS), egy fejlesztıeszközt, amely a szoftverfejlesztési életciklust kezdetétıl – a tervezéstıl - egészen a végéig – a tesztelésig - a lehetı leghatékonyabban használható. Dolgozatom céljául ennek a csoport alkalmazásfejlesztıi rendszernek a bemutatását tőztem ki, és szeretnék különös hangsúlyt fektetni magára a build folyamatra. Szándékom, egy olyan leírás készítése, amelybıl kiderül, hogy a szoftverfejlesztıi csapat szereplıi hogyan végezhetik munkájukat a legkorszerőbb eszközökkel, úgy, hogy közöttük az együttmőködés is minél hatékonyabb legyen. A témaválasztásnál sokat számított, hogy van ilyen rendszerrel tapasztalatom. Munkám során számos termelésben is részt vevı Team Foundation Server 2005 és 2008 rendszer telepítésében, mőködési kérdés megoldásában, teljesítménnyel, konkrét project-tel kapcsolatos jelenséggel szembesültem, amelyek mind segítettek ennek a technológiának a megismerésében. Úgy gondolom, hogy a rutinos programozók között is elıfordulhatnak emberek, akik még nem találkoztak ezzel a programmal. Talán irományom hatására a Visual Studio Team Foundation Server-t is beveszik a lehetséges opciók közé a Project Manager-ek, amikor csapatuk számára ideális
integrált alkalmazási életciklus management megoldás (ALM) bevezetésén gondolkodnak.
3
A Team System ugyanazon az eszközkészleten alapul, amelyet a világ vezetı szoftvergyártója használ belsıleg saját szoftverei sikeres tervezéséhez, létrehozásához és telepítéséhez. Olyan alkalmazássá bıvíti a Visual Studio-t, amely a teljes csapatot integrálja a termék életciklusának minden fázisában. Ezáltal növeli a project sikerességének megjósolhatóságát, a csapat termelékenységét, hatékonyságát, együttmőködését. Mivel szolgáltatásai testreszabhatóak és bıvíthetıek, megteremti a fejlesztıi környezet bıvíthetıségének lehetıségét is. A VSTS ereje elsısorban olyan csapatoknál érzékelhetı, ahol fellelhetı a project
manager, rendszertervezı, fejleszı és tesztelı szerepkör. Ezeket a szerepeket, és a hozzájuk kapcsolódó mindennapi feladatokat, elvárásokat szeretném néhány szóval ismertetni. A project managereknek kell áthidalni az őrt az ügyféligények és a fejlesztıi csapat munkaterve között. Nekik kell biztosítaniuk a csapat együttmőködését és kommunikációját konzisztens és naprakész dokumentációval. Be kell tartatniuk, tartatniuk a határidıket, kezelniük és minimalizálniuk kell a kockázatokat, szükség esetén stratégiai irányváltásokat kell beiktatatniuk, és fenn kell tartaniuk a folyamatok zavartalan hömpölygését a fejlesztıi életciklus valamennyi fázisán keresztül. Ezek a feladatok jellegzetesen olyanok, melyeket csak sok független eszközzel, és „kézi” beavatkozással lehet elvégezni. A VSTS leegyszerősíti a Project Managerek munkáját, mégpedig úgy, hogy a különbözı project management eszközöket egyetlen alkalmazáson, a Visual Studio-n belül teszi elérhetıvé. Az
architectek számára Distributed System Designer-ek (Elosztott Rendszer Tervezı) állnak rendelkezésre, amelyekkel átláthatóbbá, rugalmasabbá tehetı a Service orientált alkalmazások fejlesztése, telepítése. Lehetıvé teszik, hogy míg az alkalmazástervezık ezeket az alkalmazásokat vizualizálják, addig a fejlesztık dolgozni tudjanak a generált kódokkal, mégpedig úgy, hogy a kódváltozatok szinkronban legyenek a designnal. A Distributed System Desinger-ekkel lehet diagramokat létrehozni, melyek az adatközpont logikai felépítését szemléltetik. Ezek segítségével remekül lehet a fejlesztıkkel ismertetni pl. a telepítés célkörnyezetének lényeges adatait. A Code Analysis tool pl. egy éjszakai build check-in policy-jának (beadási szabályok, lsd következı fejezet) részeként, lehetıvé teszi, hogy a hibák ki legyenek javítva mielıtt a kód hozzáadódik a forrásfához. Ennek a fejlesztık vehetik hasznát
4
munkájuk során. A teljesítmény monitorozó eszközök segítségével korán bemérhetıek, kiértékelhetıek az esetleges performancia problémák. A múltban a tesztelési és a fejlesztı eszközöket elkülönítve tartották. A tesztelık külön környezetet, és test scripteket használtak, melyeket ık írtak, és a forráskód kezelıtıl elkülönítve tároltak. A VSTS egy rakás teszt eszközt is integrál az IDE-n belül. A Web tesztek, load tesztek, manuális tesztek és unit tesztek (egység tesztek) mind saját varázslóval és szerkesztıablakkal rendelkeznek. A tester-ek szerkeszthetik, futtathatják és ellenırizhetik a különbözı munkaegységekhez kapcsolódó teszteket a VS-en belül. Egy sikertelen teszt esetén mindössze egy jobb-klikk elég ahhoz, hogy létrejöjjön egy bug, és hivatkozás is készíthetı a problémás kód részletre. Így a probléma könnyen reprodukálható. Rendelkezésre áll egy bıvíthetı infrastruktúra arra is, hogy a tester-ek, developer-ek és a partnerek létre tudják hozni saját teszt típusaikat, szerkesztıiket, és visszajátszó mechanizmusukat, ami a Visual Studio reporting és analysis rendszerrel való együttmőködésének eredménye. Az említett 4 szerepkör között nincsenek szilárd határok, bıvíthetıek, sıt a csapat felépítésétıl és a project jellegétıl függıen egy személy akár több szerepet is betölthet. Miután néhányat említettem azok közül, hogy „melyek” azok a funkciók, amivel a VSTS segíti a szereplık munkáját, dolgozatom során jónéhány technikai „hogyan” kérdésre is igyekszem választ adni. A teljesség igénye nélkül igyekszem nagyobb hangsúlyt fektetni azokra a funkciókra és technológiai megoldásokra, amelyek véleményem szerint a VSTS magját, lényegi részét képezik, s hogy mik azok az ötletek, amelyeket a világ vezetı softvergyártói is alkalmaznak eredményességük receptjeként.
5
2. A Team Foundation Server 2.1
Alapfogalmak Ahhoz, hogy mélyebben elkezdhessük taglalni ennek a fejlesztıi csoportot
támogató eszköznek a felépítését, elengedhetetlennek érzem, hogy néhány alapvetı fogalmat tisztán lássunk. Ennek a fejezetnek ezt tőztem ki céljául. Aki már találkozott a VSTS-sel és megismerkedett alapfogalmaival, most néhány soron keresztül nem fog újat hallani.
A TFS egy többrétegő architektúra[1]: Adatbázisrétegbıl (Data Tier, DT), Alkalmazásrétegbıl (Application Tier, AT), és Kliensrétegbıl (Team Explorer, vagy maga a Visual Studio) áll. Felépítése tehát hasonló ahhoz, amit nagyvállalatok szoktak létrehozni saját üzleti alkalmazásaikhoz, és a felhasznált software-k is a leggyakoribbak: ASP.Net, WSS és Microsoft SQL Server. Adatbázisréteg (Data Tier): a TFS adatbázisrétegét az Microsoft SQL Server hosztolja. Ideális esetben ez egy dedikált server, ami csak ezt az egy feladatot látja el. A TFS az SQL Server adatbázismotor és analitiai, elemzı szolgáltatásait használja. A DT-be az alábbi adatbázisok kerülnek a telepítés során (TFS 2008 esetében is): • TFSIntegration
–
TFS
központi
szolgáltatások
(project
metaadatok,
figyelmeztetések, security group-ok, stb) • TFSWarehouse – TFS adattárház (analízis és report tároló) • TFSWorkItemTracking – itt tárolódnak a work item-ek (arról, hogy mik azok a work item-ek, a késıbbiek során ejtek szót) • TFSWorkItemTrackingAttachments – ennek külön táblája van (Attachments), ez egy mutatógyőjtemény a work item attachment file-jaira.
6
• TFSVersionControl – verziókezelési adatbázis (lsd. Késıbb: Verziók) • TFSActivityLogging – activity log adatbázis. A TFS rendelkezik egy beépített eszközzel arra, hogy logoljon minden server parancsot a DT adatbázisai felé. Ezek mind web service hívások. • TFSBuild – build adatbázis, ami a build-ekkel kapcsolatos adatokat tartalmazza
Alkalmazásréteg (Application Tier, AT): Az AT ASP.net webservice-ekbıl, valamint a csapatportált támogató WSS-bıl áll. (Megjegyzés: mivel mind a TFS webservice-k, mind a WSS ugyanarra az IIS telepítésre támaszkodnak, különbözı portszámot kell hozzájuk beállítani.)
7
A web service-k az AT-n a TFS API-re épülnek, és ezek biztosítják a TFS funkcionalitásait. A service-k virtual directory-kban találhatóak az IIS Manager Team Foundation Server website gyökere alatt:
A webservice-ket nem közvetlen használatra tervezték. A szoftverfejlesztı készlet (SDK, Software Develpment Kit) tartalmaz további információkat errıl. Ettıl függetlenül lehetséges a közvetlen kapcsolat, ha egy webhivatkozás megadásával a megfelelı webservice-re. A WSS-sel (Windows SharePoint Services) könnyen és gyorsan létrehozható a Team Project portal környezete bármilyen mérető team számára, méghozzá anélkül, hogy kódot kellene írnunk. A WSS portálok elınye továbbá, hogy képesek az összes szükséges mővelet elvégzésére, amelyre szükségünk lehet. Pl: feltöltés, letöltés, biztonság, menük, Check-in, Verziókezelés, stb.
8
A következı ábra az AT felépítését szemlélteti:
Kliensréteg (Client Tier, CT): a TFS kliensrétegét a következı alkalmazások képezhetik: • Visual Studio 2005 vagy 2008 – fejlesztıi környezet • Microsoft Office Excel • Microsoft Office Project • Microsoft Internet Explorer • Team Explorer – VS-be épülı modul, vagy különálló eszköz a Team System project-ek létrehozására és kezelésére. Ezek az alkalmazások a TFS-el a webservice-eken keresztül kommunikálnak.
9
Munkaelem (Work Item, WI):
Önálló munkaegység, melyet el kell végezni. A
munkaelem kifejezés meghatározhat bármilyen tevékenységhez köthetı információt, amely része a szoftverfejlesztési életciklusnak. Olyan követelmények, feladatok, hibák, stb., melyeknek tulajdonságaik vannak, úgymint címük, dátumuk, állapotuk, és a csapattag neve, akihez rendeltük. Ezek az elemek a szoftverfolyamatunk alapjai lehetnek, és ahogy haladunk az idıben a project-ünk fázisain keresztül, úgy fejlıdnek ezek is velük. A workitem-eket más objektumokhoz tudjuk kapcsolni. Ha verziókezelıbe projectvezetı
beadott nyomon
kódhalmazhoz tudja
követni,
rendeljük, mely
akkor
változtatások
a
fejlesztı, tartoznak
vagy melyik
követelményekhez, illetve hibákhoz.
Verziókezelés (Version Control): Olyan több verzióval rendelkezı adatok kezelése, melyeken egyidejőleg nem csak egy ember dolgozhat. Az egyes változtatásokat verziószámokkal vagy verzióbetőkkel követik nyomon. A Team Foundation Verziókezelı (Team Foundation Version Control, TFVC) bevezeti a változáskészlet,
changeset fogalmát. Más verziókezelı termékeknél az egyes fájloknak, amelyeken dolgozunk, nincs hivatkozásuk vagy környezetük: csak külön fájlok, melyeket egy idıben adunk be. A TFVC-ben a changeset-ek összetartozó fájlmódosításokat írnak le. Ezáltal a könyvelés és a munkafolyamat jobb, az administzráció pedig egyszerőbb. Minden chageset egy egyedi azonosítót kap a nyomon követéshez, és a jelentésekhez.
Check-out (kivétel): Lokális másolat készítése egy verziókezelt file-ról. Ilyenkor legtöbbször a legfrissebb verziót kapja a user, de van lehetıség konkrét (régebbi) verzió kikérésére is.
Check-in (beadás):
Az a mővelet, amikor a lokális példányváltoztatások jóváíródnak
a serveren tárolt változatban.
Ez történhet egyszerő másolás vagy összefésülés
(merging, lásd késıbbb) eredményeként.
10
Conflict:
Konfliktusról akkor beszélünk, ha többen akarnak megváltoztatni egyszerre
egy adatot, és a rendszer képtelen a változásokat összeépíteni. Ilyenkor a felhasználónak kell feloldania a konfliktust. Ezt úgy teheti meg, hogy kiválasztja az egyik változtatást és csak azt juttatja érvényre. Change (változtatás): Verziókezelt adaton alkalmazott változtatás. ChangeList (változtatás lista): egy check-in alatt bevitt változtatások listája. Branching (elágaztatás): Verziókezelt adatok egy részhalmaza elágazhat, így több aktuális változattal is rendelkezhetnek. A branching az a mővelet, amikor kimásoljuk az aktuális forrás fából a kód-ot, és beillesztjük a fa újonnan létrehozott ágába. Hogy ezt könnyebben megértsük, vegyünk egy példát a file rendszer-bıl. Elágaztatáskor vesszük az aktuális kód mappáját (forrás) és létrehozunk egy új mappát beillesztve a forrás mappa tartalmát. Gondolhatunk tehát az elágaztatásra úgy is, mint egy file rendszer szintő másolás mővelet, melynek során vesszük az egyik helyen lévı fileokat, és átmásoljuk ıket egy másik helyre. Ezekután a fejlesztık párhuzamosan folytathatják a munkát mindkét mappa tartalmán.
Mergeing (összefésülés): Az összefésülés az elágaztatás ellentett mővelete. Egy elem elágaztatása helyett a forrás fában, két elemet alakítunk eggyé.
Source Control(adattárház):
a Team Foundation Server (Team Foundation Verson
Control, TFVC) verziókezelıjét Source Control-nak, vagy Repository-nak (adattárház) nevezzük. Eltérıen a Microsoft korábbi verziókezelıjétıl (Visual SourceSafe), amely még file rendszer alapú tárolási mechanizmussal mőködött, a TFS Source Control minden forrásfile-t, változtatást, az aktuális check-out-okat, stb. SQL adatbázisban tárolja. A Source Control-nak köszönhetıen áll a felhasználó rendelkezésére a többszörös, vagy szimultán check-out, konfliktuskezelés, shelving, unshelving, a biztonsági szintek állítási lehetısége a forrásfa minden szintjén,
Shelving: Forráskód idıleges elhelyezése a Version Control server-en, tényleges check-in nélkül.
11
Workspace:
kliens oldali másolata a source control serveren lévı file-oknak és
mappáknak. Mikor hozzáadunk, szerkesztünk, törlünk, mozgatunk, átnevezünk forráskezelt egyedeket, a változtatásaink késleltetıdnek, vagy megjelölıdnek pending changes-ként (felfüggesztett változtatások) a workspace-ben. A workspace egy elkülönített hely, ahol írhatjuk, tesztetlhetjük a kódot, anélkül, hogy aggódnunk kellene a már beadott forráskód stabilitása miatt, vagy amiatt, hogy a többi fejlesztı változtatásai hogyan fogják befolyásolni a pillanatnyi munkánkat. A változtatásaink elkülönítıdnek a workspace-ben mindaddig, amíg be nem adjuk ıket a source control serverre. A Get Latest parancs való a workspace-ünk synchronizálására a legfrissebben beadott változtatásokkal a serveren.
Build (összeállítás): Forrás kódból, a független, végrehajtható, és számítógépen futtatható
szoftvertermékké
való
konvertálás
folyamatát,
és
a
folyamat
végeredményét Build-nek nevezzük. Ez a folyamat egyszerőbb programoknál mindössze egyetlen forrásfile lefordításából áll, összetettebb szoftvereknél viszont a forráskód több file-ból is felépülhet, és különbözı módon kombinálható annak érdekében, hogy több verzió jöjjön létre. A Build process-t általában egy build eszköz vezérel, amely lefordítja, és összekapcsolja a megfelelı sorrendben a file-okat. Ha a forráskód egy bizonyos file-ban nem változott meg, akkor nem szükséges újrafordítani, ami a build idı optimalizálása szempontjából lényeges. MSBuild: A Microsoft Build platform-ja, amit jellemzıen a Visual Studio-val használnak. Az MSBuild 2.0 a .NET Framework 2.0 része, és a Visual Studio 2005-tel mőködik együtt. A 3.5 verziót a .NET Framework 3.5 tartalmazza, a Visual Studio 2008-hoz adták ki, és lehetıség van vele 2.0, 3.0 és 3.5 .NET Verziók által támogatott project-ek build-elésére. Ezt nevezzük multi-targeting-nek. Mivel az MSBuild a .NET Framework része, lehetıség van Visual Studio project-ek, solution-ok build-elésére anélkül, hogy a Visual Studio IDE telepítve lenne a gépünkön. Az MSBuild project file-okkal dolgozik. Ezek XML file formátumúak, kiterjeszthetık, és segítségükkel meghatározhatjuk mely egyedeket kell build-elni, és azt is, hogy hogyan kell ezt tenni különbözı platformok, konfigurációk esetén. Újrafelhasználható
12
build szabályokat készíthetünk, melyeket különbözı file-okban tárolhatunk, lehetıvé téve, hogy a termék különbözı project-jeit konzisztensebben build-elhessük.
2.2
Visual Source Safe Minden fejlesztési projecthez, ami egyszerő demókódnál többet jelent fontos,
hogy tartozzon hozzá verziókezelı. A Microsoft berkein belül ezt a célt kezdetekkezdetén a Visual Source Safe (VSS) szolgálta. Annak ellenére, hogy a VSS hasznos eszköz, sok fejlesztı szeretett volna több fejlett funkciót, lehetıséget használni. A Microsoft ezért tőzte ki céljául, hogy egy olyan fejlett, teljeskörő, vállalati szintő verziókezelı rendszert alkosson meg, amely az összetett fejlesztési feladatok többségének kezelésére alkalmas, továbbá a VSS-nél sokkal megbízhatóbban kezeli az elágaztatás és összefésülés mőveleteit. 2006-ban ezért piacra dobta a Visual Studio 2005 Team Foundation Server-t (TFS), amelyben számos új funkció található. Írásom most következı részében szeretnék kitérni a VSS és a TFS architektúrális és funkcionális különbségeire[3], melyeket érdemes fontolóra venni, amikor döntésre kerül a sor azt illetıen, hogy melyik technológia lenne ideálisabb választás fejlesztıi csapatunk számára.
13
2.2.1
A TFS szerkezeti elınyei:
a VSS a Source Safe explorerével és a
Visual Studio plug-in-jével egyaránt a Visual SourceSafe adatbázisba ír és onnan olvas, ami lényegében egy file győjtemény, általában egy megosztott hálózati mappában. Ezzel szemben a TFS esetén a source control rendszer .NET Web servicet használ, hogy hozzáférjen az adatokhoz, melyeket egy SQL Server adatbázisban tárol. Emiatt a TFS source control architektúrája jobb teljesítményt és nagyobb megbízhatóságot garantál. Biztonság és project jogosultságok: a VSS esetében felhasználói jogosultságok és kinevezéseket (melyeket a VSS administrator programmal lehet beállítani), függetlenek a Windows Sharing permissions-tıl (megosztási engedélyek), melyeket a VSS megosztott hálózati mappára állítottunk be. Be lehet állítani a jogokat és kinevezéseket konkrét VSS projectekhez vagy független VSS felhasználókhoz, de minden VSS user-nek ugyanolyan engedélyekkel kell rendelkeznie a VSS adatbázis mappa tekintetében. Ennél fogva minden VSS user hozzáférhet a megosztott folderhez, és teljes jogosultsággal rendelkezhet a VSS adatok fölött, függetlenül a project szintő jogaitól, melyet a VSS admin programban specifikáltunk. A TFS esetén a user specifikus operatív engedélyek és a project szintő engedélyek a Windows user account-hoz kötıdnek. A user autentikációt biztonságosan végzi az Internet Information Server (IIS). Külön SQL Server adatbázis hozzáférésre nincs szüksége az egyes
user-eknek,
akik
source
control
mőveleteket
hajtanak
végre.
Ezek
eredményeként a TFS security infrastruktúrája könnyebben adminisztrálható, robusztusabb és biztonságosabb.
14
Megbízhatóság: mivel a VSS-nek nincs server komponense, az adatszállítással járó mőveletek nem tranzakcionálisak, azaz nincs lehetıség roll-back-re ha probléma történik. Azon ritka esetekben, amikor megszakad a hálózati kapcsolat egy írási mővelet közepén, az érintett file-ok integritása veszélybe kerül, és információ vész el. A TFS egy kliens-szerveralkalmazás, melyben a mőveletek adatbázisban történnek stored procedures (tárolt eljárások) útján, melyek nincsenek kitéve hálózati kapcsolati hibáknak. Bizonyos mőveletek tranzakcionálisan hajtódnak végre, minél fogva hiba esetén lehetıség van roll-back-re. Ez az arhitektúra biztosítja, hogy a forrásfile-ok ne korruptálódhassanak. Biztosak lehetünk abban is, hogy azok a file csoportok, melyek összefüggı change-eket tartalmaznak ugyanabban az idıben lesznek a source control serverre commit-álva egy megfelelıen ellenırzött changeset-ként. Skálázhatóság: TFS támogathat akár 2000 user-t is, míg a VSS 20, vagy kevesebb létszámú team-eknek ajánlott. A TFS annyi adatot tárolhat, amennyit az SQL Server elbír (terabyte-ok…) és amennyit a hardware környezet megengedhet, ugyanakkor a javasolt méretkorlát a VSS adatbázisa esetén 4 GB.
2.2.2
A TFS Funkcionális elınyei: Changeset-ek: Koncepcióját tekintve a
VSS adatbázis és a TFS soruce control server belsı strukturája hasonló. Mind az adatbázisok, mind a serverek hierarchikusan szervezıdnek. Mappák tartalmaznak file-okat. A file-oknak verziói vannak, melyek szám és létrehozás ideje/dátuma alapján azonosíthatók. A TFS-nek viszont van egy elınyös koncepciója, ami még nem létezik a VSS-ben. Ez pedig nem más, mint a changeset. A changeset egy logikai tároló, amiben a TFS minden check-in mővelethez kapcsolódó dolgot tárol: file és mappamódosítások, linkek a kapcsolódó work item-ekre, check-in kommentek és más információk, mint pl. hogy ki végezte a változtatást.
15
Check-out és check-in különbségek: VSS-ben csak akkor kell explicit check-outot és check-in-t végezni, ha file-t szerkesztünk. TFS esetén, minden cselekvésnél szükség van explicit check-out és check-in-re. További eszközök, melyek különbözıen mőködnek: VSS-tıl eltérıen a TFS nem hajt végre GET mőveletet, mikor check-out-olunk egy file-t. Egyszerre több user is check-out-olhat és változtathatja ugyanazt az item-et. VSS esetén a check-out-ok kizárólagosak. TFS-nél viszont lehetıség van a file lock-olásra, hogy más user-ek ne check-out-oljanak vagy check-in-eljenek változtatásokat. Elágaztatás és összefésülés: a VSS csak nagyon alap szinten támogatja a branch és merge mőveleteket, mert nem tárolja a merge history-t a két file, vagy folder branch között. Ezzel szemben a TFS source control esetén létezik merge history. Checkout mővelet és a Get Latest: mikor végrehajtunk egy Get operációt, hogy feltöltsük a workspace-ünket file-okkal, egy konzistens pillanatfelvételt készítünk a source control-ról. A forrás konfiguráció kijelöl egy idıpontot, amikor felvétel készül a TFS source control azon file-jairól, melyeket összetartozónak vél, és így együtt buildelhetıek és tesztelhetıek. Mikor egy fejlesztı dolgozik a workspace-ben, védett a többi fejlesztı által végzett változtatásoktól. İ irányítja, mikor akarja elfogadni a mások általi változtatásokat, úgy, hogy végrehajtja a Get mőveletet. Mikor ez történik, frissítve lesz az egész forrás konfiguráció és nem csak egy-két file. Egy file változtatása függ más megfelelı file, file-ok változtatásain, és emiatt meg kell gyızıdni róla, hogy konzisztens a forrás snapshot, amit build-elni és tesztelni akarunk. Emiatt nem hajtódik végre CheckOut mővletkor Get Latest a CheckOut alatt levı file-okon. A kivétel alatt lévı file update-elése ezt a konzisztens snapshot filozófiát tönkre tenné és olyan forrás konfigurációt hozna létre, amely nem buildelhetı, tesztelhetı. Egy lehetséges megoldásként a TFS kényszeríti a user-t, hogy végrehajtson Get Latest mőveletet még mielıtt beadja a változtatásait, így ha a beadáskor nem a legaktuálisabb másolatunk van, a TFS a konfliktus kezelési párbeszédablak feldobásával figyelmeztet.
16
Ezek tehát az alapvetı különbségek a VSS és a TFS között, melyek felsorolása után azt hiszem már könnyebben eldönthetı, hogy a VSS, avagy a TFS a jobb választás a team-ünk számára. 2006 és a TFS elsı verziójának megjelenését 2008ban a Visual Studio 2008 Team Foundation Server megjelenése követte, amelyben számos olyan új dologot változtattak, vagy oldottak meg, amely az elsı verzióból az “ínyenceknek”
esetleg
hiányozhatott.
Ezek
közül
csak
néhányat
említenék
felsorolásképpen[2]: • SharePoint 2007 támogatás (és immáron tetszıleges porton keresztül is) • Reporting Services támogatás (másik szerveren, és extra portokon is) • Nevesített SQL Server támogatás (így már egy szerveren akár több TFS is futhat) • Windows 2008 támogatás • SQL 2008 támogatás • Upgrade támogatás TFS 2005-rıl • Performancia optimalizálás (akár 30.000 user is lehet) • Egyszerősített telepítés (nincs külön DT telepítés, szükségtelen annyi speciális user a telepítéshez, és nem kell mindnek admin-nak lennie sem) • Végleges törlés • Certificate alapú azonosítás • Stb.
17
2.3
A Visual Studio Team System A bevezetı során már felszínesen kifejtettem, hogy a VSTS a négy szerep
mindegyikét külön funkciókkal, lehetıségekkel támogatja. Annak érdekében, hogy a különbözı szerepek esetlegesen mások számára szükségtelen funkciói ne bonyolítsák túl az alkalmazást, mindegyik szerephez létezik külün Visual Studio edition(kiadás). Most ezen kiadások sajátosságaira szeretnék kitérni. A következı táblálzat rendszerezi az egyes eszközöket. A különbözı kiadások különbözı feladatkörre specifikált
modulokat,
opciókat
tartalmaznak[6].
rendszerezi:
18
Ezeket
a
következı
ábra
2.3.1. Team Explorer A Project Managerek számára a legfontosabb a Team Explorer (TE) lesz, amely egy ún. add-in (beépülı modul) a Visual Studio-hoz. Segítségével tud kapcsolódni a TF serverhez. Ha nincs szüksége Visual Studio-ra, akkor dönthet úgy, hogy csak TE-t telepít gépére, mert erre is lehetıség van, és a Team Explorer is tartalmazni fogja a munkájához szükséges legfıbb funkciókat. Létre tud új Team Project-et hozni, kiválaszthatja a process template-et (telepítéskor MSF for Agile, és MSF for CMMI Software Development process template-k vannak, de bármilyen egyéni minta létrehozható). Ki tudja osztani jogosultságokat a TFS-hez, hozzáférhet a Work Itemekhez (újat hozhat létre, szerkeztheti azokat, követheti állapotukat), dolgozhat a Project SharePoint portálján (ez szintén magától létrejön a Team project létrehozásakor), az összes dokumentum elérhetı számára, ami a Team Project-hez kapcsolódik. Szintén fontos a lifecycle során, hogy a project manager jelentéseket tudjon lekérni. Erre a TFS a Reporting Services-el (RS) nyújt megoldást. Mivel az RS böngészı alapú, nem kell külön eszközt telepíteni a jelentések kiíratásához, kinyomtatásához. Az SQL Server komponenseként települ a TFS DT-re. Mivel a legtöbb project manager az MS Office Excell-t használja reportjai elemzéséhez, fontos megemlíteni, hogy a VSTS használatakor is lehetıségük lesz ad-hoc lekérdezéseket, jelentéseket készíteni Excell-el, mivel a táblázatkezelıvel is lehet a TFS adatbázisához kapcsolódni, és adatokat megjeleníteni Pivot Tábla formájában. A lekért adatok megoszthatóak a csapattagokkal a project SharePoint Portálja segítségével.
19
2.3.2.
Visual Studio 2008 Team System Architecture Edition
A csapatunk Architectjei[7] számára a Distributed System Designer (Elosztott Rendszer Tervezı) lesz a legnagyobb érték, melyet a Visual Studio 2008 Team
System Architecture Edition tartalmaz. A Distributed System Designer-ek az elsı hordozói a Dinamikus Rendszer Kezdeményezésnek (DSI, Dynamic System Initiative), amelynek szándéka, hogy megkönnyítse az elosztott rendszerek tervezését, bevetését, mőködtetését A Distributed System Designer-eknek köszönhetıen a software architect-ek, infrastruktura architect-ek és fejlesztık növelhetik a termék sikerének elıreláthatóságát. Mögöttes metamodel-ként a Rendszer Definíciós Modelt (SDM, System Definition Modell) használják. A Distributed System Designer jónéhány grafikus tervezıbıl áll, amelyek a következı célokkat szolgálják: • dokumentálni, visualizálni és közzétenni az alkalmazás terveket, adatközpont runtime környezeteket. • elosztott alkalmazás rendszereket tervezni • alkalmazás rendszereket értékelni ki a cél adatközpontban • létrehozni és össeegyeztetni az alkalmazás terveket a forráskódokkal
Hogy ezeket a célokat még magasabb színvonalon elérhessék az architectek és fejlesztık, a következı eszközök is rendelkezésükre állnak: • Application Designer (alkalmazástervezı): a fejlesztıi környezetben megtervezi, vizualizálja, konfigurálja és implementálja az alkalmazásokat • System Designer (rendszertervezı): megtervezi az alkalmazásokat tartalmazó-, és egyéb rendszereket. • Web Service Details window (Webszolgáltatások részletei): megtervezi és átnézi a Web Service mőveleteket. • Setting and Constraints Editor (Beállítás és megszorítás kezelı): az alkalmazás és logikai szerver beállításokat és constraint-eket kezeli. • Logical
Datacenter
Designer
(Logikai
adatközpontként ábrázolja a futtató
Adatközpont
környezeteket, és
tervezı):
logikai
segít a rendszer
skálázhatóságát felmérni • Deployment Designer (telepítés tervezı): definiálja és kiértékeli a alkalmazások,
20
alkalmazásrendszerek telepítés definícióit.
2.3.3.
Visual Studio Team System 2008 Development Edition
A Visual Studio Team System 2008 Development Edition olyan haladó eszközkészlettel látja el a fejlesztıket, amely segít felismerni a rossz minıségő, nem elég biztonságos, vagy nem hatékony kódot. A programozók rendelkezésére bocsátja a legjobban bevált praktikákat, továbbá az automatikus Egység Tesztelés (Unit Test) lehetıségét. A Unit Test a minıség biztosításának legjobb módja. Olyan teszteket kell írni, amelyek ellenırzik az adatokat és algoritmusokat, valamint biztosítják, hogy a kezdeti hibák nem térnek vissza késıbb. Ennek érdekében 4 fajta Unit Test van: • A pozitív egységtesztek valósághően lefuttatják a kódot és igazolják a helyes eredményt • A negatív egységtesztek szándékosan helytelenül futtatják a kódot és igazolják a megfelelı teljesítményt és hibakezelést. • A stress test-ek vagy feszültség tesztek a kód teljesítményének határait próbálják felfedni és ismertetik azokat. • A hibabeszúró (Fault Injection) tesztek a hibakezelés rendellenességeit fedik fel. A bug-ok korai felfedezésének legegyszerőbb módja, ha a fejlesztık növelik a figyelmeztetések szintjét a szerkesztıben és a kódelemzési eszközökben. Ha megfelelıen használják a workitem-eket, akkor pedig nem maradhat befejezetlen kód. A teljesítmény vagy performance eszközök segítségével mérhetıek, kiértékelhetıek a teljesítmény problémák. Ezek az eszközök mind a Visual Studio-ba integráltan találhatóak meg.
21
2.3.4.
Visual Studio Team System 2008 Test Edition
A Visual Studio Team System 2008 Test Edition teszt eszközök garnitúráját tartalmazza, melyek nem csak a saját teszt keretrendszerükben, hanem más nagyobb szoftver életciklus eszközök szerkezetén belül is. Ez a kiadás a teszterek számára megkönnyíti, hogy létrehozzanak, vezessenek, szerkesszenek, futtassanak, tároljanak teszteket. Több teszttípus, mint pl. Web, load (terhelés) és kézi teszt található benne. Lehetıség van létrehozni egy olyan több számítógépekbıl álló group-ot, amivel terheléses tesztet lehet szimulálni. A csoport egy vezérlıbıl, és több agent-bıl (ügynök) áll. A csoportot együttesen köteléknek nevezzük. Egy agent annak a köteléknek a része, amely teszteket futtat, és szimulált terhelést generál. A controller, vagy vezérlı pedig annak, amely kötelék vezérli az ügynököket és begyőjti a tesztek eredményeit. Amikor a tesztek futnak, az eredményeket automatikusan generálják, lementik a lemezre, és megjelenítıdnek a Test Results (Teszt Eredmények) ablakban. Töb teszt típusért még mélyebb eredményeket is lehet lekérni. Ha a csapat arra használ egy TFS Team Project-et, hogy segítsen a munkát vezetni, akkor szintén lehet teszteredményeket kiadni. Publikáció után össze lehet olvasztani, és fel lehet használni ezeket a jelentésekben.
22
3. A Team Foundation Build A Team Foundation Build (TFB) a Microsoft Visual Studio Team System fejlesztıi környezet része. Ahogy a projectek életciklusuk során fejlıdnek, elıbb vagy utóbb elérkezik az idı, amikor le kell ıket fordítani (compile), distribute-olni, és kezdıdhet a tesztelés. Ezt a folyamatot együttesen Build-nek nevezzük. A TFS esetén azonban a Builld jóval összetettebb folyamat, mint ahogyan azt az MSBuild-nél tárgyaltuk, és a Project Team tagjai számára rengeteg manuális többletmunkát jelent. Ez a folyamat a következı problémákat rejti: • A mindenre kiterjedı és a project környezetbe integrált build eszközök nélkül elıreláthatatlan
és
megismételhetetlen,
ad
hoc
build
process-eket
eredményezhetnek. • A build process-t figyelemmel követni, tisztán látni a pillanatnyi állapotát szintén nem egyszerő dolog. • Általában nincsenek módszerek arra, hogy hogyan oldjuk meg a build során esetlegesen felmerülı akadályokat. A Team Foundation Build a build process számos aspektusát automatizálja, és jelentıs eszközkészletet biztosít a folyamat során felmerülı problémák megoldására és a létrejövı build-ek elemzésére. A következık során a Team Foundation Build tool lehetıségeirıl, a build rendszer alapelveirıl, a build eszközei és a Visual Studio közötti interakcióról lesz szó, továbbá arról, hogyan is épül fel egy tipikus build process a Visual Studio Team System-en belül.
23
3.1
A Team Foundation Build áttekintése Számos fejlesztı cég külön build labort hoz létre azzal a céllal, hogy ott a
buildeljék publikus és privát software release-eiket. Egy build labor, olyan hardware és software erıforrások együttese, amelyek összegyőjtik a Team Project forráskód file-jait a Build Serveren, majd compile-t hajtanak végre a rendszer legutóbbi változtatásain. Gyakori szokás szerint ezt a build-et késıbb becsomagolják, és egy olyan helyre másolják, amely a Team minden tagja számára elérhetı. A minıségbiztosításért felelıs szervek ezután már szabadon futtathatják rajta teszt szoftvereiket, és vizsgálhatják, milyen jellegő változtatásokat kell még a fejlesztıi csapatnak a project-en végrehajtani. A Team Foundation Build nem titkolt célja, hogy egy ehhez hasonló Build Labort biztosítson egyetlen dobozba zárva. Lényegében arra törekszik, hogy megszüntesse a build folyamattal járó manuális munka nagy részét, és információt szolgáltasson az aktuális Build állapotára vonatkozóan a fejlesztıi Team tagjai számára. A Team Foundation Build platform elınyei: •
Lehetıvé teszi, hogy a Visual Studio-n belül, gyorsan és könnyen jöjjön létre és kezdıdjön el a Build process.
•
Eszközöket biztosít a Project Team tagjai számára, amelyekkel a Build státuszát ellenırizhetik.
•
Build-rıl build-re összehasonlítható vele akár történelmileg is, hogy hogyan alakulnak az egyes build-ek a tesztelés, fejlesztés során.
24
3.2.
A Team Foundation Build felépítése
A Team Foundation Build szolgáltatáscsomagja 4 Visual Studio-n belüli alrendszerbıl épül fel. Mindegyik fontos szerepet játszik a build folyamatban[4]: •
A Team Build Client (lényegében maga a Visual Studio) definiálja a build-et a Team Foundation Source Control system-ben, majd el is indítja.
•
A Team Foundation Server Application Tier (alkalmazás szerver) figyeli a Team Build Kliens felıl érkezı build kéréseket, majd továbbítja azokat a Build Server felé.
•
A Build Server végzi a munka oroszlán részét: futtatja a Build Service-t, ami vizsgálja a Build specifikációit, begyőjti a szükséges file-okat a Source Control rendszerbıl, compile-t (fordítást) hajt verge a forrásfile-okon, teszteket futtat, majd az eredményeket publikálja. A Build befejezıdése után az értesítések kiküldhetıek a csapatnak, továbbá a Build Server egy meghatározott helyre publikálja a build-et.
•
A Team Foundation Server data tier (adatbázis szerver) tölti be a data repository (adattárház) szerepét: itt tárolódnak a build részletei és a log eventek (naplózott események), láthatóvá és elemezhetıvé téve a buildet a Build kliens számára.
25
A következı ábra ezen komponensek egymással való együttmőködését szemlélteti:
Megyjegyzés: A diagram csak egy logikai arhitektúra. A Team Foundation rendszer fizikailag máshogyan is strukturálható. Például: nagyobb projectek esetén logikus döntés egy dedikált Build Server létrehozása, de a Build Server ugyanazon a gépen is futtatható, ahol a TFS Application Tier, vagy esetleg még a Data Tier is. Nagyobb lélegzetvételő project-ek esetén pedig az a leghatékonyabb, ha egy egész számítógép farmunk van Build gépekbıl, és ezen futnak a Build server komponensei.
26
3.2.1.
A Team Build kliens
A Team Foundation Build rendszer elsıszámú kliense a Team Explorer, mely a Visual Studio beépülı moduljaként, vagy önálló alkalmazásként telepíthetı, használható. Az aktuálisan futó összes Team Project-hez tartozó Build elérhetı, vezérelhetı, konfigurálható a Build node-ból, mely a Team Explorerben található. Ezek az egységek úgy tekinthetıek, mint beállítások egy-egy halmaza, beleértve azt is, hogy mely file-k tartoznak a build-hez, melyek azok a test-ek, melyeket a build részeként futtatni kell , vagy hogy hova lesz a build publikálva, stb.
3.2.2.
Az Application Tier
A Team Foundation Build 4 web servicebıl áll, melyek az Application Tier Szerver-en futnak: •
Build Controller web service: Az API-t (Application Programming Interface)
kiegészítve irányítja, kontrollálja a build-eket. Felelıs többek közt azért is, hogy a build-et elindítsa és leállítsa, vagy jelezze, hogy véget ért a build. •
Build Store web service: Ennek a web service-nek köszönhetı, hogy a build-
del kapcsolatos adatokat a Data Tier-en el lehet menteni és újra elı lehet venni szükség esetén a késıbbiek során. •
Build Integration web service: Lehetıvé teszi, hogy a Build Server és más
kliensek kapcsolatba kerüljenek más Team Project egyedekkel is. •
Publish Test Results web service: Ez az az API, mely megosztja a build test
eredményeit a Project Team tagjaival.
3.2.3.
Build Server
A Build Server implementálja magát a Build processt. Windows service-kbıl áll (Team Build Service-k), amelyek az AT felıl érkezı utasításokat hajtják végre. Ennek a service-nek a feladata, hogy a Build Database-bıl nyert információk szerint használja a mögöttes bulild motort (MSBuild).
27
3.2.4.
Build Repository
A Build repository-t a TFS DT implementálja a saját SQL Server adatbázisa alapján, amit TFSBuild-nek hívunk. Ez az adatbázis több, mint 20 táblát tartalmaz, amik a build definíciókal, test eredményekkel, és work item-ekkel kapcsolatos információkat tartalmazzák. A következı ábra az adat modelljét mutatja néhány fontosabb build-et definiáló táblának.
Most, hogy betekintést nyertünk a Team Build világába is, ideje, szeretném egy konkrét példával szemléltetni, hogyan lehet létrehozni, specifikálni, elindítani, majd pedig analizálni egy build processzt a Visual Studio Team System segítségével.
28
3.3.
Új Team Build létrehozása
A Team Foundation Build bevezeti a build types (build típusok) fogalmát. Egy build type az adott build-del kapcsolatos összes konfigurációs adatot tartalmazza. Lényegében egy build összes alkotóeleme itt definiálódik. Egy build type-ot Team Explorer-en keresztül, a New Build Type Creation Wizard segítségével lehet létre hozhatun létre.
3.4.
Build adatok specifikációja
Az elsı lépés, hogy megadjuk a build nevét. Ez ugyanaz a név, ami a Team Explorer Builds node-on belül és a build reports-ban is található. A következı ábra a Build Type wizard elsı oldalát szemlélteti:
A varázsló következı lépése során választhatjuk ki azokat a project-eket, amelyeket build-elni akarunk. Erre való a legördülı lista az ablak tetején. Itt ki lehet választani az adott Workspace összes elérhetı project-jét. Itt lehet meghatározni a build sorrendet is. Ez olyan esetben fontos, ha sorrendi függés van a különbözı
29
solution-ok lefordítása által létrejövı binary-k között.
A Build konfiguráció adja meg a build paraméterét. Ez alapján dıl el, hogy a build release vagy debug típusú-e, és szintén itt adható meg a build cél CPU platformja is.
A TFB-dnek tudnia kell, hogy melyik szerver funkcionál Build Server-ként. Fontos,
30
hogy ekkorra már ez a szerver ki legyen jelölve Build Server-nek, ahogy azt a TFS install médián levı setup file futtatásakor tettük. Ennek során települt a Build Service, és a szolgáltatásnak futnia kell már a build elindítása elıtt:
A build során teszteket is futtathatunk. A varázsló következı oldalán lehet megadni, hogy mely tesztek fussanak le a build alatt, vagy után. Az alsó checkbox használatával adhatjuk meg, hogy egy statikus kód analízis is lefusson a forrásfájlokon, amelyeket a build-ben megadtunk.
31
A VSTS 2008 esetében az új Build létrehozása némiképpen módosult a 2005-ös verzióhoz képest[5]. Lehetıség van korlátozni az adott idıpillanatban szerveren tárolt Build-ek számát, melynek köszönhetıen a régi build-ek kitakarításával jelentıs tárhelyet tudunk felszabadítani. A szabály neve Build Retention Policy, és meg lehet adni a build végeredménye szeirnt is: failed (hibás), stopped (leállított), partially succeedded (részben sikeres), vagy sikeres build-ekre vonatkozóan. Ami viszont véleményem szerint még jelentısebb újítás: az ún. idızített Build-ek (Scheduled Build) és Build Triggerek létrehozása. Ez a VS 2008 Team System-en a varázsló utolsó lépése az összegzés elıtt, és itt lehet beállítani, hogy mikor fusson le automatikusan a Build. Beállítható, hogy minden alkalommal build történjen, ha valaki forrásfile-t checkin-el a szerverre. Ennek a neve: Continous Integration. Szintén ennél a lépésnél állíthatjuk be azt is, hogy új build-ek a már futó build-ektıl függıen induljanak. Ebben az esetben, ha már fut build, akkor egy vagy több checkin esetén az új build nem indul el amíg a régi be nem fejezıdött.
32
Ha a project szempontjábból azt véljük hatékonyabbnak, akkor lehetıség van megadni, hogy a hét mely napjain és hány órakor induljon build. Tehát ha pl. nagyobb project esetén azt szeretnénk, hogy ne a munkaidıben használódjanak szerverünk erıforrásai a build processre, akkor úgy értdemes idızítenünk a build-et, amikor a legkevesebben használják a szervert. A 6. és egyben utolsó lépés során a New Team Build Type Creation Wizard összegzi, hogy miket adtunk meg. Teszt futtatásához fontos, hogy fel legyen telepítve a Build Agent-re a Visual Studio Test Edition, a Code Analysis futtatásához pedig a Development edition jelenléte szükséges.
A Finish gomb megnyomása után két dolog történik: •
Létrejön egy XML file (TFSBuild.proj), amiben tárolódnak a build beállításai
•
és hozzáadódik a Source Control System-hez, mint egy új project, aminek a neve megegyezik a Build nevével.
•
Ha a késıbbiek során szükséges a build type-ot szerkeszteni, módosítani, akkor a TFSBuild.proj file szerkesztésével lehet ezt megtenni. Erre remek eszköz a Visual Studio XML szerkesztıje.
33
3.5.
Build indítása Ha van egy vagy több már definiált build, akkor a csapat tagjai manuálisan a
Team Explorerbıl, vagy idızítve elindíthatják azokat amikor csak akarják. Eredetileg a TFB nem képes rá, hogy idızített build-eket hajtson végre egyszeri vagy többszörösen ismétlıdı rendszerességgel. A TFS parancs segítségével azonban parancssorból használhatjuk a standard window scheduler task-ot. Egy idızített build beállításához a következı információkra van szükség: •
a TFS AT server URL-je
•
a build type-ot tartalmazó Team Project neve
•
a build type neve, amit schedule-álni szeretnénk A parancs neve, amivel végrehajtani és irányítani lehet a build-et: TFSBuild.exe
(TeamBuildInstallDir\Comon7\IDE\). Néhány paraméter megadásával ez a .exe kapcsolódik a build serverhez, lokalizálja a team project-et, letölti a konfigurációval kapcsolatos információkat, majd pedig végrehajtja azt. A következı ábra egy hagyományos build processz futását szemlélteti:
34
3.6.
Buildek elemzése és nyomonkövetése
A build alatt az engine folyamatosan naplózza az build során zajló történések adatait. A logok visszakerülnek a Build Repository-ba, és így a csapattagok számára lehetıvé válik, hogy nyomonkövssék a Visual Studio-val az események alakulását. A Build
információk
a
Team
Bulid
Exploreren
keresztül
láthatóak.
Ez
egy
böngészıablak, amely listázza a befejezett, vagy épp zajló Build-eket. A Team Build Explorer az elsıszámú eszköz a build folyamatának, vagy a már teljesített összegzések szemrevételezésére. Minden Build jelentés a VS document ablakában nyitható meg. A riport következı komponensekbıl tevıdik össze: •
Summary (Összegzés): összegzi a build részleteit, a build-el kapcsolatos adatokat, mint pl a build nevét, a személyt, aki indította, a gépet, ami futtatta, a jelenlegi állapotát, és a linket a build log-hoz.
•
Build Steps (Build lépések): tartalmazza a listát (ha a build még zajlik, akkor dinamikusan), ami megadja a dátumot és a pontos idejét a build minden fázisának.
•
Result Details (Eredmény részletek): a build által generált hibákat és figyelmeztetéseket tartalmazza, valamint a build-del futó tesztek eredményeit.
•
Associated Changesets (hozzárendelt változtatások): a build-ben részt vevı összes changeset listáját tartalmazza hyperlink-el együtt.
•
Associated Work Items (hozzárenelt munkadarabok): ez az összes build-hez rendelt workitem-et sorolja fel hyperhivatkozásokkal.
A Build logok és Reportok segítségével theát a csapat rendelkezésére áll minden infromáció, amely egy esetleges sikertelen build-et okozhat, és sikeres build esetén is fontos adatokat tudhatunk meg az alkalmazással, az alkalmazás teljesítményével, állapotával kapcsolatban.
35
3.7
Gyakorlati példa Annak
érdekében,
hogy
az
elhangzott
elméleti
jellegő
információkat
könnyebben elképzelhesse a Tisztelt Olvasó, szeretnék picit gyakorlatiasabb dolgokról is írni, amelyet az elhangzottak összegzésének szánok. Ennek érdekében most egy Team Project létrehozásának módját szeretném lépésrıl lépésre ismertetni egészen a build folyamat befejezıdéséig. Tételezzük fel, hogy a csapat számára egy .Net alkalmazás elkészítése a feladat. Annak érdekében, hogy a leghatékonyabban, tehát a csapat valamennyi tagjának bevonásával el tudjunk kezdeni dolgozni a feladaton, szeretnénk egy Team Project keretein belül szervezni a teendıket. Miutrán Visual Studio-val létrehoztuk a .Net Solution-t, nincs más teendınk, mint hogy megírjuk a public property-ket és metódusokat (ezt a Class Designer segítségével egyszerően megtehetjük), mielıtt a Visual Studio Team System-en belül a solution-hoz létrehozunk, és hozzáadunk egy Unit Test Project-et. Erre a Team Project-ünk buildelésénél lesz szükségünk, hiszen egység teszteket szeretnénk majd futtatni a build során. Ha már van egy mőködıképes Team Foundation Server telepítésünk, ami a hálózatra van kötve, a szerverhez való kapcsolódást a Visual Studio Tools menüjének Connect To Team Foundation Server parancsával oldhatjuk meg. Kapcsolódás után már létre tudunk hozni egy új Team Projectet. Általában a Team Project-et még kód írás elıtt értemes létre hozni. A project létrehozásának elsı fázisában ki kell választanunk a Process Template-et. Ez fontos lépés, hiszen a template határozza meg a workitemeket, report-okat és a biztonsági beállításait a project-nek. A következı lépésben beállítjuk a Source Control-t a project-hez. Érdemes egy üres source control mappát létrehozni s elnevezni a project nevével megegyezıen. Ezután összegezve látjuk majd megadott beállításainkat. A project létrehozása következik, ami eltart egy darabig, mivel sok dolgot kell a TFS-nek tennie. Többek között ekkor jön létre a Project-ünk WSS portálja is. Ezekután megadhatjuk a biztonsági beállításokat, amivel definiáljuk a csapat tagjainak szerepköreit is. Tehát már létrehoztunk egy .Net solution-t, hozzáadtuk a Unit Testeinket és létrehoztunk egy új Team Project-et kijelölve a fejlesztı, tesztelı és egyéb szerepköreit, beállítva a
36
jogosultságokat. A következı lépés során elkészítjük a Unit Test-eket úgy, hogy távoli géprıl is futni tudjanak a Team Foundation Build Server-en. A Visual Studio Team System-en belül, a Test Manager automatikusan létrehozza a teszt metadata file-t, .vsmdi kiterjesztéssel. Ez tartalmazza a unit test konfigurációt a project számára, ami biztosítja, hogy a teszt fusson távoli build során is. Ezek az adatok a .vsmdi file-ban mentıdnek el, és a file szintén beadásra kerül a Source Control System-be. Készen állunk a project build type-jainak definiálására. Ezt a Team Explorer-bıl a Team Build opciónál érhetjük el, a Create New Build types paranccsal. Egy olyan build-et hozzunk létre, ami lefordítja a .Net Solution-unkat, és a Unit Test Projectünket is. A már ismertetett varázslóban meg kell adnunk a build-elésre szánt projectek neveit, a Build Server-t, és be kell állítanunk, hogy a Unit Test-ek fussanak is le a build során. Miután a build befejezıdött, rendelkezésünkre állnak a Build Report-ok, amibıl kiderül, hogy ki indította az esetlegesen sikertelen Build-et. A build naplózott adatairól email-t is külhet a rendszer a fejlesztıkne, benne az adatokkal, melyekkel fény derülhet a hibás build, vagy teszteset okára. Az AssignWorkItem funkcióval egy feladatot (Task) adhatunk a fejlesztınek, aki checkin-elte a problémát okozó kódot. Nagy vonalakban ezek a visszatérı mozzanatai egy tipikus Visual Studio Team Systemmel fejlesztett Team Project életciklusának, de megjegyezném, hogy magát a fejlesztést, ami az egész Project lényege, most szándékosan nem részleteztem, mert az nem ennek a dolgozatnak a témája.
37
4. Befejezés Dolgozatom céljául a Visual Studio Team System és szerveralkalmazásának, a Team Foundation Servernek átfogó leírását, a kapcsolódó szerepkörök bemutatását tőztem ki. Írásom alapján a Tisztelt Olvasónak lehetısége nyílt megismerni a VS Team System elıdjét, különbözı kiadásait, továbbá mélyebben érintettem a szoftverfejlesztés lényegi célját, a Build folyamatot is. Összegzésként végigkövettük egy tetszıleges alkalmazás életciklusának fázisait, ezáltal gyakorlati szemszögbıl még jobban megvilágítva ennek a meglehetısen összetett rendszernek egy ajánlott használati módját, üzemeltetését. Tisztában vagyok vele, hogy az érintett területek tárgyalása során sok esetben hagytam nyitott kérdéseket magam mögött. Számos olyan terület is lenne még, amelyet meg sem említettem, pedig talán szorosan kapcsolódna a témához. Amennyiben a Kedves Olvasó így érez, azt kell mondjam, hogy dolgozatom elérte célját. Naívság lett volna ugyanis részemrıl egy hiánytalanul teljes kép visszaadásával próbálkozni egy ily mértékben testreszabható, ráadásul bıvíthetı rendszerrıl a rendelkezésemre álló terjedelemkorlátokon belül. Dolgozatom elolvasása után remélem, hogy lesznek, akik lázas keresésbe kezdenek egy-egy általam érintett témát még jobban körüljárni. Hiszen az informatika fejlıdése, s így a fejlesztıi környezetek fejlıdése is megállíthatatlan. A Visual Studio 2010 és a .Net Framework 4.0 már elérhetı tesztelés céljából, és a többi mammutcég „gyártósoráról” is sorozatban potyognak le az újabbnál újabb fejlesztıi eszközök. A verseny tehát e téren megállíthatatlan, s igazi gyıztesének csak magukat a fejlesztıket mondhatjuk, akiknek egyre hatékonyabb, produktívabb alkalmazások állnak rendelkezésükre, hogy a mai modern szoftverpiac magas elvárásait teljesíteni tudják.
38
5. Köszönetnyilvánítás: Köszönetet mondok Dr. Kuki Attila témavezetımnek, hogy lehetıséget biztosított munkám sikeres elvégzéséhez és dolgozatom megírásához. Köszönöm segítıkész támogatását és dolgozatom alapos és kritikus átnézését.
Köszönetet mondok továbbá Jagó Jácint külsı konzulensemnek, hogy az IT Services Hungary Kft. Microsoft Fejlesztıi csapata infrastrukturális hátterének megismerésében segítségemre volt, s ezáltal segítette munkám elvégzését. Köszönet a konzultációval töltött idıért, és az építı kritikákért, melyekkel segített dolgozatom színvonalát tovább emelni.
39
6. Források [1] Richard Hundhausen – Working with Microsoft Visual Studio 2005 Team System [2] http://msportal.hu/blogs/smulo/archive/2007/10/17/team-foundation-server2008-mi-233-rt-is.aspx [3] http://msdn.microsoft.com/en-us/library/ms181369(VS.80).aspx [4] Lars Powers, Mike Snell - Microsoft® Visual Studio 2005 Unleashed [5] Lars Powers, Mike Snell - Microsoft® Visual Studio 2008 Unleashed [6] Official Microsoft Visual Studio Documentation [7] http://msdn.microsoft.com/en-us/library/cc304371.aspx
40
