Bevezetés a Visual Studio Team Services használatába

Bevezetés a Visual Studio Team Services használatába

Bevezetés a Visual Studio Team Services használatába Nagy Gáspár független konzulens, olyan csapatokat oktat és segít, amik fejlesztői munkájuk minőségét és hatékonyságát agilis tesztelési módszerekkel, azon belül is viselkedésalapú szoftverfejlesztéssel (behavior driven development - BDD) szeretnék növelni. Gáspár a megalkotója és jelenleg is vezető fejlesztője a nyílt forráskódú SpecFlow tesztelési eszköznek, amely meghatározó BDD eszköz a .NET platformon. Több mint 15 éve foglalkozik szoftverfejlesztéssel, korábban szoftvertervezőként és fejlesztői coachként is dolgozott. Rendszeres előadó nemzetközi konferenciákon, és a Scrum Alliance akkreditált oktatója a Certified Scrum Developer programban. Microsoft Certified Professional az Application Lifecycle Management témakörben. Gáspárt megtalálhatod a twitteren (@gasparnagy), a blogján (http://gasparnagy.com) vagy vállalkozásának (Spec Solutions) weboldalán (http://www.specsolutions.eu).

TARTALOMJEGYZÉK Tartalomjegyzék ...................................................................................................................................................1 Bevezetés..............................................................................................................................................................2 Legyél te is Ricsi! ...................................................................................................................................................3 Mi is az a VSTS? ....................................................................................................................................................4 Első lépések ..........................................................................................................................................................5 0. Perc: Regisztrálj a Visual Studio Team Services használatára ......................................................................5 2. Perc: Hozz létre egy VSTS-projektet .............................................................................................................5 4. Perc: Hozz létre egy alkalmazást! .................................................................................................................6 7. Perc: Töltsd fel az alkalmazást a VSTS-re! ....................................................................................................8 9. Perc: Fordítsuk és teszteljük az alkalmazást a felhőben! .............................................................................9 14. Perc: Tervezd meg a következő lépéseket! ............................................................................................. 12 Az alkalmazáskövető, amit böngészővel is elérhetsz – VSTS & TFS Web .......................................................... 12 A csapat, ahol mindenki adminisztrátor – VSTS Teams..................................................................................... 14 A fejlesztési folyamat, ami a csapat igényeihez illeszkedik – Process, Scrum board, Kanban board & Customizations .................................................................................................................................................. 17 Process........................................................................................................................................................... 17 Scrum Board .................................................................................................................................................. 18 Kanban Board ................................................................................................................................................ 19 Tanácsok a testreszabáshoz .......................................................................................................................... 21 A verziókezelő, amiben mindenki integrálhat – Git .......................................................................................... 21

•••

1/24


A teszt, amire nem kell a nap végéig várni – VSTS Build ................................................................................... 23 Szintén Ricsi? ..................................................................................................................................................... 24

BEVEZETÉS Öt-hat évvel ezelőtt, ha valaki a Team Foundation Server nevet hallotta, illetve a rövidítését, a TFS-t, valószínűleg komplex, bonyolult nagyvállalati alkalmazás, illetve verziókövető rendszer jutott eszébe. Egy olyan rendszer, ami bonyolult szervezeti struktúrákat kezelt, kifinomult, jogosultságokat vett figyelembe, házirendeket és más szabályokat tartatott be, és külső reportokat és dokumentumokat kapcsolt a fejlesztési folyamatokhoz. A világ azonban megváltozott. Az agilis fejlesztői folyamatok megjelenésével előtérbe kerültek a kisebb, hatékony, cross-funcional, nagyfokú autonómiával rendelkező csapatok, és a rövidebb fejlesztési ciklusokkal dolgozó, iteratív (pl. Scrum) vagy épp folyamszerű (pl. Kanban) fejlesztési modellek. A Team Foundation Server, és különösen a felhőalapú változata, a Visual Studio Team Services (VSTS), lépést tudott tartani ezekkel a változásokkal, és hatékony támogatást tud nyújtani az egészen kicsi hobbiprojektektől a nagyobb, több csapat együttműködését igénylő projektekig. Ebben a cikkben a felhőalapú változat, a VSTS használatába nyújtok egy kis bevezetőt. Megvizsgáljuk a legfontosabb funkciókat, és azt, hogyan lehet elkezdeni és hatékonyan használni a VSTS-t egy kisebb projekt támogatására. A VSTS használata öt főnél kisebb projektek esetén és MSDN előfizetőknek ingyenes, úgyhogy a költségek miatt sem kell aggódni.

•••

2/24


LEGYÉL TE IS RICSI! Sok évvel ezelőtt egy nagy banki projekten dolgoztam Angliában. A több száz fejlesztős mamutprojekt fejlesztése szigorú szabályok szerint folyt. A csapatok részletesen kidolgozott tervek alapján dolgoztak, meghatározott időrendben és házirendek betartásával. (Bár a projekt szervezett volt, azért sikeresnek nem mondható. Már akkor több éves csúszásban voltak, amikor én csatlakoztam. Végül, úgy tudom, egy kis teammel az egész rendszert újraírták később. De ez egy másik történet.) A csapatok tagjai a napi munkájukat a nap végén fésülték össze, azaz integrálták a rendszer aktuális változatába, hogy aztán utána a csapatok munkáit is integrálni lehessen. Ha ez megvolt, indulhatott a napi tesztelés. Persze az ritka eset volt, hogy minden egyből működött. Tipikusan valamilyen banális hiba miatt kellett újraindítani az egész folyamatot. Ez volt a délutáni-esti program. Néha a késő esti is. A folyamatot egy olyan kolléga koordinálta, nevezzük Ricsinek, akinek a névjegykártyájára az volt írva, hogy “Configuration Manager”. Ricsi volt az alkalmazásmenedzsment mindenese. Hozzá kellett fordulni jogosultságokért, ő készítette el a branch-eket a verziókövetőben, és ő integrálta a végeredményt. Nagyon vidám és vicces figura volt. Reggel. Aztán este fele, ahogy az integráció fölé egyre sötétebb felhők kezdtek gyülekezni, a hangulat már nem volt olyan kellemes. Nem csak neki, nekünk sem. Szerintem másnap a jogosultságok és az egyéb igények kielégítését a szerint prioritizálta, hogy ki miatt hányszor kellett plusz munkát végezni az előző napokban. Ez volt a legfőbb motiváció. Bár a névjegykártyájára menedzser volt írva, senki sem irigyelte. Képtelenség volt egy ekkora projektet ilyen szigorú szabályok szerint menedzselni. Az én feladatom az egyik komponens teljesítményproblémáinak megjavítása volt. Nagyon meglepődtek, amikor ezt nem a nagy termékben kezdtem el, hanem egy kis lokális projekttel meg egy-két mini tesztelő programmal vágtam bele a dologba. Mondták, hogy ez felesleges, hiszen az esti tesztfolyamat teljesítménytesztet is tartalmaz. De amit nem tudtak, hogy akkorra én már több, mint 100 ilyen tesztet tudtam futtatni a komponensemre naponta. Persze nem az agilis fejlesztés látnoka voltam én akkor, egyszerűen csak nem volt nagy kedvem beletanulni a nagy rendszer működtetésébe és a szabályokba arra a pár hónapra, amíg ott voltam. Mindenesetre működött a dolog, és onnantól az én kéréseimet Ricsi mindig egyből teljesítette. Nem tudom, mi lehet most Ricsivel. De azt hiszem, ő is rájött azóta, hogy sokkal jobb, ha minden csapat a saját maga konfigurációmenedzsere. A saját maga Ricsije.

•••

3/24


MI IS AZ A VSTS? Az ALM (Application Lifecycle Management, alkalmazás életciklus menedzsment vagy alkalmazáskövetés) olyan átfogó fogalom, amelyen az alkalmazásfejlesztés során felmerülő adatok és tevékenységek tárolását és kezelését értjük. Az ALM eszközök legtöbbször támogatják az alkalmazás követelményeinek (pl. user story), a munka menedzselésének (pl. task) és karbantartásának (pl. bug) leírásait, valamint lehetőséget adnak a forráskód verziókezelésére. A Microsoft Team Foundation Server (TFS), illetve annak felhőalapú változata, a Visual Studio Team Services (VSTS) a Microsoft ALM-rendszere, amelyet sok .NET-alapú projektben alkalmaznak. (A VSTS korábban Visual Studio Online néven volt elérhető.) A Team Foundation Server a teljes fejlesztési folyamatot lefedően nyújt támogatást a projekt tervezésétől a fejlesztésen át a karbantartási periódusig. Ezáltal megkönnyíti a projektek támogatását, mert nem kell különböző, az egyes részfolyamatokat támogató eszközöket integrálni és összehangolni. Bár egy új TFS projekt létrehozása és bekonfigurálása az elérhető sablonoknak köszönhetően pár perces folyamat, lehetőség nyílik a projekt folyamatainak testreszabására és a vállalat speciális igényeinek lekövetésére. A Team Foundation Server sokrétű termék, részletes ismertetése meghaladja e cikk kereteit. Ezekről bővebben a https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx címen található részletes leírás. Ebben a fejezetben a felhőalapú változat, a Visual Studio Team Services egy-két fontosabb funkcióját sorolom fel, amelyekbe a további fejezetek részletesebb betekintést is nyújtanak majd. A Visual Studio Team Services egy a Microsoft Azure infrastruktúrán futó TFS rendszer, amiben a felhasználók vagy cégek elkészíthetik saját regisztrációjukat, amelyhez egyedi URL (pl. https://azéncégem.visualstudio.com) tartozik. Ez az URL reprezentálja a vállalat vagy csapat saját ALM-portálját, amelynek saját felhasználói, jogosultságai és beállításai vannak. A VSTS az első öt felhasználóig ingyenesen használható, így egy most induló projektcsapat költségek nélkül ki tudja próbálni a felhőalapú ALM előnyeit. Több felhasználó esetén a költségek a felhasználók számától függnek, de azok a fejlesztők, akik MSDN-előfizetéssel rendelkeznek, költségek nélkül használhatják a szolgáltatást. A VSTS árazásáról az https://www.visualstudio.com/en-us/products/visual-studio-teamservices-pricing-vs.aspx címen lehet részletes információt találni. Az ALM infrastruktúra – mérettől függően – komplex, több szerverből álló rendszer. Az alkalmazásszerver és az adatokat tároló adatbázisszerver legtöbbször külön gépre kerül, de sokszor van szükség a szolgáltatások további skálázására. Ennek beállítása és üzemeltetése komplex feladat. A VSTS használatával erre nincs szükség, hiszen a szolgáltatás menedzselése központilag történik. A VSTS fejlesztése rövid, háromhetes ciklusokban történik. Ez a gyakorlatban azt jelenti, hogy az újítások és javítások az alkalmazásban rövid időn belül megjelennek, és használatba vehetők. Bár a telepített TFS is relatív sűrű, negyedéves release-ciklusokat használ, a cégek a frissítések költségeinek és az esetlegesen keletkező időkiesések csökkentésének érdekében általában ennél jóval ritkábban, 1-2 évente frissítik a rendszerüket. A VSTS előnyei között a már említett egyszerűbb karbantartás és az új funkciók hamarabbi megjelenésén túl még az integrált felhőalapú build-rendszert (lásd lejjebb) és a könnyebb, megbízhatóbb és biztonságos elérhetőséget lehet megemlíteni. Ez utóbbi segítségével az ALM-rendszerünket bárhonnan, biztonságos kapcsolaton keresztül elérhetjük mind webböngésző, mind Visual Studio használatával. Így az elosztott munkavégzés könnyebbé válhat, és egyszerűbben bevonhatjuk az ügyfelet is a projekt folyamatába.

•••

4/24


ELSŐ LÉPÉSEK Ahhoz, hogy a VSTS-szel mi is Ricsik lehessünk, meglepően kevés dolgot kell megtanulnunk. Mit szólnál, ha azt mondanám, hogy 15 perc alatt lehet egy teszteket futtató környezeted. Ebben a fejezetben azt mutatom meg, hogyan. Bár a régebbi Visual Studio verziók is alkalmasak a VSTS elérésére, ebben a cikkben Visual Studio 2015 használatát feltételezem. Ha még nincs telepítve VS2015, azt egyszerűen megteheted a https://www.visualstudio.com/ oldalról kiindulva. A Community kiadás magánszemélyeknek és kisebb cégeknek ingyenes (teljes lista itt), illetve egyéb esetekben is tanulási céllal ingyenesen használható. A Visual Studio 2015 használatához valószínűleg már szükséged volt egy Microsoft fiókra (régebbi nevén Microsoft Live). Ha valamiért még nem rendelkezel ilyennel, pár perc alatt létrehozhatsz egyet (ingyenesen) a https://signup.live.com oldalon.

0. PERC: REGISZTRÁLJ A VISUAL STUDIO TEAM SERVICES HASZNÁLATÁRA 1. Egy böngészőben nyisd meg a https://www.visualstudio.com/ oldalt, és válaszd ki a VSTS-regisztráció elkezdését (a középső zöld gombra kattintva)! Ha regisztráció előtt még szeretnél többet olvasni a rendszerről, akkor azt a https://www.visualstudio.com/en-us/products/visual-studio-team-servicesvs.aspx címen teheted meg. 2. Add meg a Microsoft fiókod emailcímét és jelszavát! 3. A regisztrációhoz ki kell választani a VSTS-portálod nevét. Ez a név fog szerepelni az URL-ben: https://valami.visualstudio.com. Célszerű nem a céged nevét megadni, hanem valamit, ami rád jellemző, hacsak nem a cég nevében regisztrálsz. Az én rendszerem például a https://gasparnagy.visualstudio.com címen fut. 4. Azt is ki kell választani, hogy Git vagy Team Foundation Version Control legyen a kódkezelés alapja. Ezt hagyd az alapértelmezett “Git” opción. Az “A verziókezelő, amiben mindenki integrálhat – Git” fejezetben még beszélünk erről. 5. A „Continue“ gombra kattintva a regisztrációd hamarosan el is készül.

2. PERC: HOZZ LÉTRE EGY VSTS-PROJEKTET Az igazság az, hogy ha a VSTS-re most regisztráltál az előző lépések szerint, akkor automatikusan létrejött egy projekt a rendszereden („MyFirstProject” néven). Ha amúgy is ezt a nevet szeretted volna választani az első próbálkozáshoz, akkor készen is vagy. Át is nevezheted a projektet, de gyakorlásképpen létre is hozhatsz egy újat. Ezt mutatjuk most meg.

•••

5/24


1. A böngésződben jelenleg az automatikusan létrehozott projekt áttekintő képernyőjét látod. Ez leginkább a címsorból látható. Ahhoz, hogy új projektet tudj létrehozni, először is menj a VSTSportálod főoldalára a címsor „Team Services” linkjére kattintva. 2. Kattints a „New” linkre a „Recent projects & teams” panelen! Egy ablak fog felugrani a projekt részleteinek megadásához. 3. Add meg a projekt nevét! Esetleg leírást is adhatsz hozzá, de ez nem kötelező. Ha nincs jobb ötleted, lehet a projekt esetleg „HelloWorld”. Elvileg szóköz, sőt felkiáltójel is lehet a projekt nevében. 4. A „Process template” maradjon az alapértelmezett „Agile” (erről bővebben az „A fejlesztési folyamat, ami a csapat igényeihez illeszkedik – Process, Scrum board, Kanban board & Customizations” fejezetben), hasonlóképpen a „Version Control” maradjon „Git” (erről pedig a “A verziókezelő, amiben mindenki integrálhat – Git” fejezetben)! 5. Kattints a „Create project” gombra! Hamarosan elkészül a projekt, amire a megjelenő ablakból oda is navigálhatunk. (Esetleg egy a funkciókat bemutató kalauz is felugrik. Ezt érdemes átböngészni valamikor, de most haladjunk, mert kifutunk a 15 percből…)

4. PERC: HOZZ LÉTRE EGY ALKALMAZÁST! A példaalkalmazás persze lehet bármi, de mi most egy egyszerű „Hello World” webes alkalmazást fogunk létrehozni. 1. Nyisd meg a Visual Studio 2015-öt, és válaszd ki a File / New / Project parancsot! 2. Válaszd ki az „ASP.NET Web Application (.NET Framework)” sablont, és add meg a projekt nevét. Ez nem muszáj, hogy ugyanaz legyen, mint a VSTS-projekt neve.

•••

6/24


3. Praktikus egyből bepipálni, hogy a projekthez automatikusan egy új Git repository is készüljön. Így a sablon által létrehozott és a később általad módosított fájlok szépen elkülönülnek majd.

4. A felugró ablakban válaszd ki az MVC 4 sablont, és jelöld be, hogy adjon hozzá unit tesztprojektet is! 5. Mivel mindenkivel közölni szeretnénk üzenetünket, nem csak a regisztrált felhasználókkal, állítsd át az autentikációt “No Authentication”-re!

6. Kattints az OK gombra, és betöltődik az új projekt. Fordítsd le (F6)! 7. Nyisd meg a Views / Home / Index.cshtml fájlt a webprojektben, és az elején a H1 részben szereplő ASP.NET-et írd át “Hello VSTS World”-re! Ez így már valóban a mi alkalmazásunk.

•••

7/24


8. Futtasd az alkalmazást (F5), és ellenőrizd, hogy tényleg a megfelelő üzenet jelenik-e meg! 9. A Test / Windows / Test Explorer menüponttal nyisd meg a tesztfuttató ablakot! Ebben pillanatokon belül megjelenik három teszt is, amiket a sablon hozott létre. (Ha nem jelenik meg, akkor érdemes újrafordítani a solutiont. Lehet, hogy nem adtál hozzá unit teszt projektet a létrehozáskor?) 10. A tesztfuttató ablakban a “Run All” linkre kattintva futtasd a teszteket! Ha minden jól megy, három zöld pipát látsz majd. (Persze csaltunk, mert egyik sem teszteli a főoldali címet, amit átírtunk…) 11. Mivel minden rendben, elfogadhatjuk a változásainkat. (Mivel Git-et választottunk ki, így ezt már azelőtt is megtehetjük, hogy a VSTS-sel összekapcsoltuk volna a projektünket.) Nyisd meg a “Team Explorer”-t! Ez általában a “Solution Explorer” melletti fülön van, de a View menüből is megnyitható. 12. Válaszd ki a “Changes” gombot. (Ide egyébként VS2015 Update 3 esetén egyszerűbben is eljuthatsz az alsó státusz soron található ceruzaikonra kattintva.) 13. Ha még nem használtál Git-et a gépen, megjelenik egy figyelmeztetés, hogy add meg a nevedet és az emailcímedet. Ez nem azonosításra kell, hanem a módosításaid megcímkézésére. Érdemes azt az email címet megadni, amit a VSTS-hez használtál. 14. Írj be egy üzenetet (pl: “főcím átírása”), és a “Commit All” gombbal fogadd el a változtatásokat! Hurrá! Az alkalmazás készen áll arra, hogy VSTS-ben menedzseljük.

7. PERC: TÖLTSD FEL AZ ALKALMAZÁST A VSTS-RE! Az alkalmazást (pontosabban a forráskódját) többféleképpen is fel lehet tölteni a VSTS-re. Most a legegyszerűbbet mutatom be, ami VS2015 Update 2-től már rendelkezésre áll. (VSTS használatához érdemes mindig a legújabb Update-re frissíteni (jelenleg Update 3) a Visual Studio-t, mert folyamatosan egyre több kényelmi szolgáltatás jelenik meg benne.) 1. A Visual Studio-ban navigálj a „Team Explorer” „Sync” oldalára! Ezt úgy is megteheted, hogy a „Team Explorer” eszköztárján a „Home” gombra kattintasz, majd kiválasztod a „Sync”-et, de az eszközsor alatti címsor is valójában egy legördülő menü, ahonnan szintén kiválasztod a megfelelő oldalt.

•••

8/24


2. Kattints a „Publish to Visual Studio Team Services” szekció „Publish Git Repo” gombjára! 3. Ha a Visual Studio-ba a megfelelő Microsoft fiókkal vagy bejelentkezve, akkor meg is jelenik itt a VSTS-portálod címe, és ki tudod választani a már elkészített projektet. Figyelem, ehhez át kell kapcsolnod „Advanced” módba a képernyőt! 4. A „Repository name” legyen ugyanaz, mint a VSTSprojekt neve, ugyanis egy ilyen nevű repository már amúgy is létrejött, úgyhogy érdemes abba feltölteni, és nem egy újat létrehozni. 5. Ha mindent rendben találsz, mehet a „Publish repository”! Ez csak pár másodpercig tart majd. 6. Nyisd meg a projektedet a böngészőben, és válts át a „Code” fülre a címsor alatt! Láthatod, hogy a forráskód már itt is van.

9. PERC: FORDÍTSUK ÉS TESZTELJÜK AZ ALKALMAZÁST A FELHŐBEN! Az igazi Ricsiséghez igazából már csak az kell, hogy a híres esti buildet bekonfiguráljuk. Persze mi futtathatjuk többször is naponta. Akár minden kódfeltöltéskor is. 1. Nyisd meg a projektedet a böngészőben, és válts át a „Build” fülre a címsor alatt! Ez jelenleg üres, épp csak egy „New Definition” gomb van rajta. Nekünk pont ez kell.

•••

9/24


2. A „New Definition” gombra kattintva kezdd el a build definíciójának létrehozását! 3. A megjelenő ablakban sok-sok sablon van. Végiggördítve látható, hogy a VSTS nem csak .NET projekteket tud fordítani, de megbirkózik többek között a Java vagy a Node.js projektekkel is. Válaszd ki a „Visual Studio” nevű sablont, majd a „Next” gombot! 4. A következő ablakban nem sok mindent kell beállítani, minden jó úgy, ahogy van alapból. Esetleg a „Continous integration” opciót jelölhetjük be. Így minden kódfeltöltéskor automatikusan elindul majd a build.

5. Ezután a buildlépések beállításaihoz kerülsz, amit érdemes átböngészni, de a mi kis alkalmazásunkhoz nincs szükség módosításra. A sablon által hozzáadott lépések visszaállítják a NuGet csomagokat, lefordítják a solutiont, lefuttatják a teszteket, és az eredményeket naplózzák.

•••

10/24


6. A build véglegesítéséhez kattints a „Save” gombra, és adj egy nevet a buildnek! Ha a „Continous integration” opciót bejelölted, lehet esetleg a neve CI (ez a continous integration gyakran használt rövidítése). De persze más nevet is adhatsz.

7. A jobb felső sarokban található „Queue new build…” linkkel tudod kérni a build futtatását. Kattints az „OK” gombra, és már mehet is! 8. Az eddigi beállításokkal ez a build egy ingyenesen használható, felhőalapú, virtuális buildszerveren fog lefutni. Ezeket az erőforrásokat mások is használják, így néha pár percet várni kell, mire a mi buildünkre kerül a sor. 9. Pár perc múlva a build elindul, és kevesebb, mint egy perc alatt le is fut. Az eredményképernyő „Tests” fülére kattintva a tesztek lefutásáról is kapunk visszajelzést.

•••

11/24


14. PERC: TERVEZD MEG A KÖVETKEZŐ LÉPÉSEKET! Lefejlesztettünk (kis túlzással) és bekonfiguráltunk egy alkalmazást, amit innentől a VSTS-ben menedzselhetünk. Éljen! Még maradt is egy kis idő a 15 percből. Mivel ez kávézásra már kevés lenne, inkább használjuk fel arra, hogy végiggondoljuk a következő lépéseket! 

Nem ártana a csapattársainkat is bevonni a projektbe. Erről „A csapat, ahol mindenki adminisztrátor – VSTS Teams” fejezetben olvashatsz többet.



A csapattal közösen megbeszélhetitek, hogy milyen módszertan és elvek alapján szeretnétek fejleszteni, és milyen lépések szükségesek egy funkció megtervezésétől a publikálásáig. Erről „A fejlesztési folyamat, ami a csapat igényeihez illeszkedik – Process, Scrum board, Kanban board & Customizations” fejezetben olvashatsz még.



Bár egy ideig inkább közösen érdemes az alkalmazás alapjait felépíteni (hallottál már a Mobprogramozásról?), de hosszabb távon a párhuzamos fejlesztések zökkenőmentes integrálásához érdemes kicsit a Git részleteibe beletanulni. Ehhez ad ötleteket „A verziókezelő, amiben mindenki integrálhat – Git” fejezet.



Most már ugyan van egy buildünk, de többet is ki lehet hozni a rendszerből. „A teszt, amire nem kell a nap végéig várni – VSTS Build” fejezet mutat erre egy-két példát.



Ha minden jól halad, nemsokára dübörög majd a projekt. Fontos lesz majd, hogy a projekt állapotáról gyors visszajelzést kapjunk. A projekt kezdőoldala jó lehetőséget nyújt arra, hogy a legfontosabb információkat megjelenítsd. Itt a csempéket tetszés szerint változtathatod és cserélheted. Vagy a kezelt adatokból pár lépésben létrehozott grafikonokat is elhelyezheted itt. A VSTS webes felületéről a következő, „Az alkalmazáskövető, amit böngészővel is elérhetsz – VSTS & TFS Web” fejezetben olvashatsz kicsit többet.

AZ ALKALMAZÁSKÖVETŐ, AMIT BÖNGÉSZŐVEL IS ELÉRHETSZ – VSTS & TFS WEB Régebben a TFS funkciói nagyrészt csak Visual Studio-ból voltak elérhetőek. Emiatt nehéz bevonni az üzleti élet képviselőit, vagy akár a tesztelőket a fejlesztési folyamatba. Persze ők nem a forráskódot akarták nézegetni (persze miért is ne tehetnék), hanem a kódhoz kapcsolódó specifikációs elemeket, hibajegyeket és az ezekből készített jelentéseket. Szerencsére a webes technológia fejlődése lehetővé tette, hogy a TFS funkciói ma már a forráskód közvetlen műveletein kívül modern webes felületen is elérhetők. Ráadásul ez a webes felület minden jelenleg közismertebb böngészővel jól használható, beleértve a kis képernyős mobileszközöket is. Mivel a webes felület nagyon sok beállítás módosítását lehetővé teszi, a teljes funkcionalitás kigyűjtése szinte lehetetlen lenne. Szerencsére a felület többé-kevésbé meghatározott sémát követ, így könnyebben eligazodhatunk az új részeken is. Tekintsük át egy képernyőkép segítségével a legfontosabb dolgokat, amelyeket a webes felületről tudni érdemes. A képen a követelmények listája látható, az egyszerűség kedvéért beszámoztam azokat a részeket, amelyekre hivatkozni fogok.

•••

12/24


1. Az alkalmazás a modern webes alkalmazások irányelveit követi, azaz például egyszerű, könnyen megjegyezhető URL-eket használ. A projekt kezdőlapját a https://valami.visualstudio.com/projektnév linken lehet elérni például. 2. A már korábban említett címsor segít tájékozódni, mivel mutatja, hogy melyik projekt (esetleg melyik team) munkáját látjuk épp. Ez nem csak tájékoztat, de a projekt nevére rákattintva könnyen át is válthatunk egy másik projektre. 3. A címsor másik oldalán a bejelentkezett felhasználó nevét látjuk (esetemben a csapat legintelligensebb tagja, Glu-Glu delfin van bejelentkezve). A linkre kattintva a felhasználó beállításait módosíthatjuk. 4. Még mindig a címsorban vagyunk. A fogaskerék ikon egy új ablakban a projekt beállításaihoz visz („Control Panel”). Ez egy hasonló szerkezetű oldal, elsőre könnyű is összekeverni a kettőt. Sok-sok beállítást találunk itt. 5. Az oldalakon belül kétszintű fülekre emlékeztető hierarchiába vannak szervezve az oldalak. A fülek maguk nem látszanak, a szín és a betűvastagság jelzi a kiválasztott oldalt. 6. A pontos kinézet innentől fogva attól is függ, hogy mi a kiválasztott oldal, de néhány esetben még egy hierarchikus listát is láthatunk a képernyő bal oldalán, ami az oldalon belüli navigálást segíti. 7. Sajnos néha még mindez sem elég, és egy további szinten válthatunk az al-al-al-aloldalakon megjelenő adatok között. A képernyő közepén például most a Work / Backlogs / Stories / Backlog oldal látható. Persze ennek az oldalnak is egyedi URL-je van, úgyhogy a gyakran használt oldalakat be lehet tenni könyvjelzőbe, vagy a projekt főoldaláról be lehet linkelni.

•••

13/24


8. Némi könnyítést jelent, hogy a jobb felső sarokban egy gyorskereső helyezkedik el. Ezzel a különböző Work Itemeket, azaz feladatokat, User Story-kat, hibajegyeket és hasonlókat lehet gyorsan megnyitni. Be lehet írni ezek számát, címrészletét, de egyéb „okos” keresőfeltételeket is (ezekhez a legördülő menü ad segítséget). Például az „a:@Me” szöveget begépelve a hozzám rendelt Work Itemek jelennek meg. 9. Elsőre talán furcsának tűnhet, hogy a felhasználói felület nem gombokat, hanem linkeket használ a legtöbb művelet végrehajtására. Több „kapcsoló” típusú link is van, amik alapértelmezésben a jelenlegi állapotot mutatják, de ha rákattintunk, akkor átváltanak. A példában az előrejelzés (Forecast) jelenleg ki van kapcsolva (Off). Ha rákattintunk az „Off” linkre, bekapcsol. (Hasonlóan a „Parents Hide” felirat „Hide” linkje nem elrejti, hanem pont megjeleníti a jelenleg elrejtett szülő kapcsolatokat.) Kicsit fura, de meg lehet szokni. 10. Azokon a képernyőkön, amelyeken sok adatot gyorsan kell bevinni, mint például itt a követelmények listájánál, a szövegdobozok úgy működnek, hogy a tényleges bevitel háttérfolyamatként indul el. Azaz nem kell megvárnunk, amíg a begépelt szöveg ténylegesen elmentésre kerül, már gépelhetjük is a következő elemet. Még csak az egérhez sem kell nyúlnunk, hiszen a bevitt szöveget az Enter billentyűvel is elfogadhatjuk. 11. Sok lista „kezeli” a jobb egérgombot (vagy hosszú érintést), és erre nem a böngésző felugró menüje jön fel, hanem a listaelemmel kapcsolatos további funkciók. Ez a menü egyébként a „…” ikonra kattintva is felugrik. A felsorolt ötleteket és funkciókat megismerve könnyen felfedezheted a webes felület többi részét is. Érdemes a gyakran használt feladatokhoz kitapasztalni, hogyan lehet őket legkönnyebben elvégezni úgy, hogy a felesleges időkiesést elkerülhessük, de ami még fontosabb, hogy a ne zökkenjünk ki, akár egy bonyolult, több lépéses navigáció által, az eredeti feladatunkból. Szintén ebben segíthet a projekt főoldala, ami egy személyre (pontosabban csapatra) szabható áttekintő oldal (dashboard).

A CSAPAT, AHOL MINDENKI ADMINISZTRÁTOR – VSTS TEAMS Ricsi egyedüli volt és pótolhatatlan. Ez az elején valószínűlen nem zavarta. Sőt, talán még örült is neki. Viszont ahogy az idő múlt, úgy kezdett el egyre kényelmetlenebbé válni számára a feladat. Nem volt egy rendes szabadnapja, szinte sosem tudott hamarabb hazamenni. A munkája folytonos stressz volt. A csapatoknak sem volt jó, hogy Ricsi tartotta kézben az összes konfigurációs feladatot. Bár egyértelműen nagyszerű szakember volt, és mindent tudott a rendszerről, az, hogy néha egyszerű beállításokra is órákat, esetleg napokat kellett várni, senkinek nem volt jó. Ahhoz, hogy ezt elkerüljük, kisebb, autonóm csapatokra van szükség, amelyek képesek a feladataik elvégzéséhez szükséges beállításokat maguk elvégezni. És ez nem azt jelenti, hogy minden fejlesztői csapatban kell, hogy legyen egy rendszergazda vagy egy konfiguráció menedzser, hanem sokkal inkább azt, hogy a csapat minden tagjának elegendő ismerettel kell rendelkeznie ahhoz, hogy ezeket a beállításokat elvégezze.

•••

14/24


Persze a centralizált konfigurációs modelleknél sokszor nem is az ismeretek hiánya volt a gond (legalábbis a tapasztaltabb csapattagok esetében). Mind tudtuk, hogy melyik az a kapcsoló vagy gomb, amit meg kell nyomni. Az ismeret nem elég, kell az is, hogy a csapattagok megfelelő jogosultságokkal is rendelkezzenek. Bár sokak számára talán őrült ötletnek tűnhet, de több sikeres projektben is részt vettem, ahol a csapattagok mind adminisztrátori jogosultságokkal rendelkeztek (természetesen csak a projektre vonatkozóan). VSTS-ben a legtöbb művelet visszavonható, illetve visszakövethető. Egy meghatározott feladatkörrel rendelkező, kicsi csapat tagjai nem tudnak igazán nagy károkat okozni, a kisebb problémákat pedig bőven ellensúlyozza, hogy a feladatok gyorsan, várakozási idő nélkül elvégezhetők. VSTS-ben egy-két egyszerű beállítással a csapat minden tagját adminisztrátorrá tehetjük, de természetesen nem muszáj. Néha már az is elég, ha a tapasztaltabb csapattagok rendelkeznek a megfelelő jogosultságokkal. De a jogosultságok természetesen még ezen belül is finomhangolhatóak. Most, legalábbis egy próba erejéig, legyünk kicsit merészek! Hívjuk meg a projektre egy barátunkat, és állítsuk be, hogy minden csapattag adminisztrátor legyen! 1. A projekt dashboardján a “Team Members” panel üres, és csak egy “Invite a friend” gombot tartalmaz. Kattints erre a gombra! 2. A megjelenő ablakban add meg a felvenni kívánt csapattag Microsoft fiókjához tartozó emailcímét! Ne zavarjon meg, hogy egy “No identities found” üzenet jelenik meg. Ez csak annyit jelent, hogy az illetővel még nem dolgoztál együtt. 3. Kattints a “Save changes” gombra. A csapatba tartozó tagok listáját láthatod, ha minden jól ment, akkor az új tag is a listán szerepel. (Bizonyos esetekben a lista tetején található frissítés gombot meg kell nyomni.)

Ezzel a felhasználót meg is hívtuk, és sok feladatot máris el is tud végezni, de például új buildet nem tud létrehozni. Ez persze jó is így, mint alapértelmezett beállítás, de mi most azt szeretnénk, ha mindketten egyenrangú szerepbe kerülnénk.

•••

15/24


A különböző jogosultságokat sokféleképpen meg lehet adni. Be lehet állítani személyenként, csoportokat lehet létrehozni, vagy épp a Windows Active Directory csoportjainkhoz is állíthatunk be jogosultságokat (VSTS esetén ez Azure Active Directory). Most mi – a tervünknek megfelelően, azaz legyen mindenki adminisztrátor – a projekthez automatikusan létrehozott csoportot tesszük majd bele az adminisztrátorok csoportjába. Így tényleg mindenki, aki a projektcsoport tagja, egyben adminisztrátora is lesz egyben. 1. Kattints a beállítások gombra (fogaskerék) a projekt címsorában. Ezzel a “Control Panel”-re, azaz a beállításokhoz kerülsz.

2. Itt egy furcsaságra kell felfigyelni. Bár sokmindent lehet beállítani itt, bizonyos projektbeállításokat nem fogsz megtalálni. Ez azért van, mert jelenleg nem a projekt, hanem a projektcsapat (“Project Team“) beállításait látod. Ez a címsorból is kiderül, csak az lehet zavaró, hogy a csapat neve alapból ugyanaz, mint a projekt neve, a „Team” utótaggal. A projekt beállításaihoz a címsorban a megfelelő linkre kattintva lehetne eljutni, de mi most maradjunk itt, a csapat beállításainál. 1. Válts át a “Security” fülre. Itt most a bal oldali listában a projektcsapatot látod, jobb oldalon pedig a jogosultságokat. 3. A jogosultságok oldalán válaszd ki a “Member of” fület. Itt lehet látni, hogy a csapatunk már most is tagja két csoportnak, a “Contributors” és a “Project Valid Users” csoportoknak. A “Contributors” (közreműködők) olyan csoport, amely alapértelmezésben rendelkezik olyan jogosultságokkal, amelyek egy tipikus fejlesztőnek szükségesek. A “Project Valid Users” (érvényes projekt felhasználók) csoport minimális (olvasási) jogosultságokkal rendelkezik, amelyekre mindenkinek szüksége lehet, aki a projekttel kapcsolatba kerül. 4. Kattints az “Add…” gombra, és kezdd el gépelni a “Projekt Administrators” szavakat! A legördülő listából válaszd ki a projekthez tartozó adminisztrátori csoportot!

•••

16/24


5. A “Save Changes” gombbal fogadd el a változtatásokat! Most már mindenki, aki a projektcsapatban van, egyben adminisztrátor is. A VSTS nem csak kis projektek kezelésére alkalmas. Ahogy talán az eddigiekből már sejthető volt, egy VSTSprojekthez több csapatot is létre lehet hozni, amik más-más jogosultságokkal vagy akár feladatlistával rendelkeznek, de elérhetik a projekt közös erőforrásait. Sőt, egy ember (pl. a scrum master) lehet több csapatnak is a tagja. Ilyenkor ő ki tudja választani, hogy melyik csapat tagjaként szeretné használni a VSTS-t.

A FEJLESZTÉSI FOLYAMAT, AMI A CSAPAT IGÉNYEIHEZ ILLESZKEDIK – PROCESS, SCRUM BOARD, KANBAN BOARD & CUSTOMIZATIONS Agilis fejlesztéshez szerencsére sok jól definiált fejlesztési és projektmenedzsment-modell közül választhatunk. Letöbben hallottak már a Scrum vagy a Kanban modellről. Bár ezek a modellek valós projekttapasztalatok alapján lettek kialakítva, bármikor szükség lehet a projekt speciális igényeihez történő igazításra. És itt most nem feltétlenül arra a kevésbé jó gyakorlatra gondolok, hogy a modell számunkra kevésbé tetsző elemeit egyszerűen kihagyjuk, hanem olyan módosításokra, amelyek a projekt igényeit szolgálják. Például ha egy asztali alkalmazást fejlesztünk, figyelnünk kell arra, hogy a telepítőcsomag is mindig frissítve legyen, ha egy új funkció kerül bevezetésre. Vagy ha például szigorú biztonsági szabályokat megkövetelő környezethez fejlesztünk szoftvert, szükség lehet a külső auditok fejlesztési folyamatba történő integrálására. A VSTS több szinten támogatja a különböző projektfejlesztési folyamatokat és azok testre szabását. Ebben a fejezetben rövid áttekintést adunk ezekről.

PROCESS A projekt létrehozásakor meg kellett adnunk egy menedzsmentmodellt (process) a projektünkhöz, ahol mi az “Agile” modellt választottuk ki. A “Process”-eket régebben “Project Process Template”-nek nevezték. A VSTS a projektben szereplő Work Itemeket (feladatok, specifikáció elemei, hibajegyek, stb.), illetve ezek lehetséges állapotait a kiválasztott modell alapján határozza meg. Mi az “Agile” modellt választottuk ki, így a követelményeket “User Story” work itemekkel adhatjuk meg. Ha a “Scrum” modellt választottuk volna ki, ezek “Product Backlog Item”-ek lennének, kicsit más tulajdonságokkal. A projekthez kiválasztott modell később nem módosítható, úgyhogy ezt az elején kell eldönteni. Egyből felmerül a kérdés, hogy melyiket válasszuk. Általánosságban azt lehet elmondani, hogy az “Agile” modell legtöbb esetben jó bármilyen agilis projekt számára, beleértve a Scrum-ot is. A “Scrum” modellt akkor érdemes választani, ha szigorúan a Scrum által megadott terminológia szerint szeretnénk fejleszteni. A harmadik elérhető modell a CMMI, ami kifinomultabb változásmenedzselési lehetőségeket ad. A választás részleteiről a https://www.visualstudio.com/en-us/docs/work/guidance/choose-process címen lehet bővebb összefoglalót találni. Lehet ugyan teljesen új modelleket (“Process”) is létrehozni, de ez igen bonyolult feladat, inkább csak nagyvállalatoknál alkalmazzák. Egyszerűen lehet viszont a meglévő modellek alapján leszármaztatott modelleket (“Inherited process”) létrehozni, amelyek kis módosításokat, kiegészítéseket adhatnak a meglévő modellekhez. Például hozzá lehet adni egy új mezőt egy Work Itemhez, vagy megváltoztatni, hogy melyik mező hol jelenjen meg. Ennek részleteit ebben a cikkben nem tárgyaljuk. Ha már van egy kis VSTS-projekt-

•••

17/24


tapasztalatunk, a “Control Panel” “Process” füléből kiindulva önállóan is felfedezhetőek a lehetőségek, illetve a https://www.visualstudio.com/en-us/docs/work/process/manage-process címen lehet többet olvasni a lehetőségekről.

SCRUM BOARD A Scrum vitathatatlanul a leginkább elterjedt agilis fejlesztési modell, és a VSTS hatékony támogatást tud adni a Scrum alapú fejlesztésekhez. A Scrum részletes ismertetése most nem célom, inkább nézzük meg, hogyan is lehet a létrehozott projektünk első fejlesztési ciklusának (amit a Scrumban Sprintnek hívnak) feladatait egy feladattáblán, task boardon összegyűjteni. 1. A projekt oldalán válaszd ki a “Work” fület! A követelmények és feladatok kezelésének képernyőjére jutsz. 2. A bal oldali listában válaszd ki az első ciklust, az “Iteration 1”-et! (Mivel az “Agile” modellt választottuk ki, ezért nem Sprintnek hívják a ciklusunkat. De ezt mindjárt javítjuk. A definiált ciklusokat a “Control Panel” “Work” füléről kiindulva kezelhetjük még.) 3. Döntsd el, hogy mettől meddig tart a Sprint, és állítsd be a dátumokat a jobb felső sarokban található “Set dates” linkre kattintva! Javítsd ki a ciklus nevét is “Sprint 1”-re! 4. A képernyő közepén található szövegdoboz segítségével adj hozzá néhány user story-t a sprinthez. Ne feledd, hogy a story-t enterrel is hozzáadhatod. (Persze legtöbbször a user story-k már adottak, és nekünk csak be kell vállalni őket a sprintre. Ehhez a bal oldalon először a “Stories” elemet kellett volna választanunk, és a listából rádobni párat az “Sprint 1” listaelemre.)

5. Most a középső panelen a „Board” fület válaszd ki! A Scrumból ismert taskboard jelenik meg, amin a zöld „+” gombokkal felvehetjük a story-khoz tartozó feladatokat az első sprintre. Vegyél fel néhány faladatot. Itt is lehet enterrel beírni feladatokat.

•••

18/24


6. Ha a feladat kártya jobb alsó felére kattintunk, megadhatjuk a feladat elvégzéséhez szükséges idő becslését (órában). Bár órában adjuk meg a becslést, sokat nem érdemes töprengeni a pontos számadaton. A valóság úgyis más lesz. Ez csak nagyságrendi becslés inkább. A feladat leírására kattintva egyéb részleket is megadhatunk. 7. A feladatokat egérrel lehet az egyes fázisok között váltani. A feladatokat a csapattagokhoz is rendelhetjük.

A board feletti sáv linkjeire, illetve a beállítások ikonjára kattintva testre szabhatjuk a task board bizonyos tulajdonságait.

KANBAN BOARD A Scrum a követelmények fejlesztését ciklikusan, sprintekbe szervezve valósítja meg. Ez a ciklus az egész csapatra vonatkozik. Más fejlesztési modellek esetén, különösen termékfejlesztéskor, nincs szükség arra, hogy a csapat ilyen szigorúan meghatározott ritmusban dolgozzon, hiszen a feladatok folyamatosan érkeznek és a termék gazdája, a product owner is mindig elérhető. A Kanban modell ilyen fejlesztési folyamatot ír le. Ebben a modellben nem a csapat, hanem a megvalósítandó funkcionalitás az, ami a fejlesztés folyamatát meghatározza. Ahhoz, hogy egy ötletből megvalósított funkció lehessen, több különböző feladatot kell elvégezni vele kapcsolatban (pl. részletezés, prototípus, tesztelés, véglegesítés, stb.). Ezek a feladatok többnyire projektspecifikusak. Az egyes feladatok állapotait egy ún. Kanban-táblán (Kanban board) lehet vizualizálni. A VSTS lehetőséget nyújt Kanban-alapú fejlesztésre is, sőt, ezt akár kombinálni is lehet a fejlesztési ciklusokkal. Erről bővebben a https://www.visualstudio.com/en-us/docs/work/kanban/kanban-basics címen olvashatsz.

•••

19/24


1. A Kanban board megnyitásához a bal oldali menüben válaszd ki a „Stories” elemet, majd a középső részen válts át a „Board” fülre. 2. A már létrehozott storykat egérrel tudod az állapotok között mozgatni, és persze új story-kat is felvehetsz.

3. A képernyő jobb felső oldalán található diagram az úgynevezett „Cumulative Flow Diagram”, ami azt mutatja, hogy a funkciók mennyi idő alatt készülnek el legtöbbször, és hogy a csapat hány feladaton dolgozik párhuzamosan (Work In Progress, WIP). A cél az, hogy ez minél kisebb legyen. 4. Természetesen a testreszabás itt nagyon fontos. Ezt a kis fogaskerék ikonra kattintva érheted el. Egy új fázis hozzáadásához válaszd a „Columns” opciót a bal oldalról.

•••

20/24


TANÁCSOK A TESTRESZABÁSHOZ A fejezetben bemutattunk néhány legalapvetőbb módot arra, hogyan tudja a VSTS a mi fejlesztési módszerünket lekövetni, és hogyan tudjuk a lehetőségeket testreszabni. A VSTS-ben rengeteg testreszabási lehetőség van, de ne feledjük: van, aki biciklit szerelni, van, aki biciklizni szeret. A végső célunk azért legtöbb esetben az, hogy hatékony fejlesztéssel új üzleti értéket hozzunk létre, és nem az, hogy az összes időnket a rendszer finomhangolása vegye el. Érdemes egy-két hónapot fejleszteni a meglévő lehetőségek minimális testreszabásával, és utána megvizsgálni, hogy milyen módosítások tennék még hatékonyabbá a munkát. Már így is sokkal jobb helyzetben vagyunk, mint Ricsi volt.

A VERZIÓKEZELŐ, AMIBEN MINDENKI INTEGRÁLHAT – GIT A projekt létrehozásakor bátran a Git verziókezelőt választottuk. Ez a fejezet a Git koncepcióját és legfontosabb tudnivalóit foglalja össze. A VSTS Git támogatásáról részletesebb leírást az MSDN-en találhatunk a https://www.visualstudio.com/en-us/docs/git/overview címen. A Git részletesebb megismeréséhez még az ingyenesen elérhető Pro Git könyvet, illetve a magyar nyelvű rövid Git összefoglalást javasoljuk. Feltételezve, hogy már használtatok valamilyen verziókezelő/verziókövető rendszert (SubVersion, SourceSafe, TFS, stb.) és Visual Studioban fejlesztitek az alkalmazást, igazából a Git elsőre nem is különösebben más, mint a megszokott rendszerek. Ahogy az „Első lépések” fejezet „4. Perc: Hozz létre egy alkalmazást!” szakaszában is láttuk, módosításokat véghezvinni, és azokat elfogadni (check-in/commit), elég hasonló, mint más rendszerekben. Miért is más mégis a Git, és miért tudja jobban támogatni az agilis fejlesztési folyamatokat? Az első lényeges különbség, hogy míg a legtöbb ismert verziókezelő a központosított (centralized) verziókezelők csoportjába tartozik, a Git elosztott (distributed) verziókezelő. De mit is jelent ez? A központosított verziókezelőkben a forráskód, annak verziói és egyéb adatai egy központi adatbázisban tárolódnak, amit egy központi szerver kezel. Bármilyen műveletet végzünk a verziókezelővel a gépünkön (pl. lekérjük a kód korábbi változásait), a művelethez el kell juttatni a kérést a szerverhez. Ez akkor is igaz, ha valamilyen módosítást végzünk. Ha például elfogadunk egy változtatást (check-in), akkor az egyből a szerverre kerül. Ha más is épp elfogadni készül a módosításait (csak épp megelőztük), előbb a mi módosításunkkal kell összefésülnie a sajátját. Ez azért nem annyira kényelmes. Például ha öt perc múlva menne a buszunk, kifejezetten bosszantó, hogy nem tudjuk a napi munkánkat elmenteni (pedig a másik, aki megelőzött, amúgy is kocsival van). A központosított verziókezelők esetén az párhuzamos fejlesztések illesztése, integrációja összekapcsolódik a módosítások elfogadásával. A Git esetén más a helyzet. Nincs is feltétlenül szükség szerverre hozzá. (Az „Első lépések” fejezetben úgy tudtuk létrehozni az új projektünket Gittel, hogy még nem is kapcsolódtunk a szerverre.) A Git esetén a könyvtár, ami a forráskódunkat tartalmazza, egyben tartalmaz minden adatot, és a forráskód teljes előtörténetét is (ezeket a „.git” nevű mappában). Ezt így együtt „Git Repository”-nak nevezik. Magyarul nincs kiforrott kifejezés rá, lehetne tároló vagy gyűjtemény is, de legtöbben magyarul is repository-nak, vagy röviden repo-nak nevezik. Mivel minden adat itt van a fájlrendszerünkön, bármikor lekérhetjük a kódtörténetet, akkor is, ha épp a repülőn ülünk, és nincs internetkapcsolat. Mivel nem kell a szerverhez fordulni az ilyen kérésekkel, ezek

•••

21/24


általában sokkal gyorsabban is működnek, azaz sokkal gyorsabban és kényelmesebben szerezhetünk meg információt az alkalmazásunkról a forráskód történetének vizsgálatával és analizálásával. Ez pedig végeredményben sokkal jobb kódismerethez, kódmegosztáshoz és hatékonyabb csapatmunkához vezet. Egy érvünk már van. A helyileg elérhető repository azonban nem csak az olvasási műveletekhez használható. Elfogadhatjuk a változtatásainkat is lokálisan! Ezt a műveletet, és az eredményeképp létrejött változtatást „Commit”-nak nevezik. Ha úgy érezzük, egy feladattal végeztünk, azt „elcommitolhatjuk”. Mivel ez lokális, nem kell abban a pillanatban az integrációval foglalkozni, és jó eséllyel elérjük majd a buszt is. Egy tanulmány azt vizsgálta, hogy a nap melyik szakaszában történik a legtöbb check-in/commit, és kevéssé meglepő módon az jött ki, hogy délután fél öt és öt között. Ez azért érdekes, mert valamilyen szinten véletlenszerű, hogy az egyes feladatok elvégzésére mennyi idő kell, és furcsa, hogy ennek ellenére mindenki pont a munkaidő vége előtt készül el a feladattal. Ha Gitet használunk, nem kell aggódnunk akkor sem, ha csak már a buszon ülve jövünk rá: valami kimaradt. Másnap reggel még lehetőségünk lesz pótolni és akár a már elfogadott commitot is kiegészíthetjük vele. Persze csak ha nem osztottuk még meg a munkatársainkkal. És itt jön be a szerver szerepe a Git verziókezelőbe. Ahhoz hogy többen együtt tudjanak dolgozni, a munkáikat – azaz a gépükön lévő repository-t – szinkronizálniuk kell, és ehhez valamilyen közösen elérhető szervert, mi esetünkben a VSTS-t tudják igénybe venni. A szinkronizálás két lépésből áll, a „pull”, amikor a szerveren található változásokat (új commitokat) letöltjük, és a „push”, amikor a mi új commitjainkat megosztjuk a többiekkel. Visual Studioból nézve ez egy „sync” művelet, ami egy pull-t és közvetlenül utána egy push-t jelent. Persze a párhuzamos változtatásokat itt is össze kell fésülni. Ezt sajnos nem lehet megúszni. Viszont itt az integráció nincs a változtatások elfogadásához kötve, bármikor megtehetjük, amikor épp alkalmas rá az idő (érdemes minél gyakrabban). Az integráció eredménye is csak egy commit (egy úgynevezett „merge” commit), úgyhogy azt is ugyanúgy lehet fel-/leszinkronizálni, mint a sima commitokat. És ha könnyebb az integráció, a csapattagok szívesebben fogják megtenni, és kevésbé marad olyan feladat, amit csak Ricsi csinálhat a nap végén. Megvan tehát a második érvünk. A harmadik dolog, amiben a Git más, mint a legtöbb centralizált verziókezelő, az az, ahogy a forráskód változatait, azaz a „branch”-eket kezeli. A legtöbb rendszerben a branch-ek a fájlrendszerben könyvtárakként jelennek meg. Ez egyrészt azt is jelenti, hogy a forráskód több verzióját is lehet egyszerre használni, és azt is, hogy egy új branch létrehozása a projekt teljes könyvtárszerkezetének lemásolását jelenti. Talán nem véletlen, hogy ritkán hoztak létre branch-eket az emberek az ilyen rendszerekben. Egy fél napos munkára branch-et létrehozni szinte már mazochizmus. A Git-nél a branch-ek ugyanannak a könyvtárnak a különböző változatai. Ha branch-et váltunk, a Git lecseréli azokat a fájlokat, amik különbözőek a jelenlegi és a kiválasztani kívánt branch között. Így ha kevés a különbség a branch-ek között, a váltás nagyon gyors. Egy új branch létrehozásához nincs szükség fájlok mozgatására, úgyhogy ezt bármikor megtehetjük. Hasonlóan a commitokhoz, egy új branch is kezdetben csak a lokális repository-ban lesz elmentve, de később, ha szükség van rá, megosztható a többiekkel. A branch-ek egyszerű és gyors kezelése teljesen új gyakorlatot eredményez a legtöbb fejlesztői csapatban. Sokkal bátrabban és gyakrabban használják a branch-eket, ami azt eredményezi, hogy a kód rendszerezettebb lesz. Ez a későbbi kódtörténet-vizsgálatot is megkönnyíti, de egyben az összefésülést és az integrációt is egyszerűbbé teszi. Ez a harmadik érvünk.

•••

22/24


Persze még sok más érdekességet lehetne felsorolni az elosztott verziókezelőkkel és a Gittel kapcsolatban. Érdemes tanulmányozni folyamatos kódellenőrzést (code review) lehetővé tevő „Pull Request” alapú fejlesztési modelleket is, amit a VSTS nagyszerűen támogat. Erről a https://www.visualstudio.com/enus/docs/git/pull-requests címen lehet többet olvasni. Természetesen vannak olyan szituációk is, amikor a centralizált verziókezelők jobban működnének. Az Git infrastruktúra és VSTS támogatás tükrében azonban nyugodtan állíthatjuk, hogy a Git összességében jobb választás egy új projekt esetén. És így Ricsi is eléri a buszt.

A TESZT, AMIRE NEM KELL A NAP VÉGÉIG VÁRNI – VSTS BUILD Az „Első lépések” fejezetben létrehoztunk egy VSTS-projektet a webalkalmazásunk menedzselésére, és létrehoztunk hozzá egy buildet is, ami nemcsak hogy lefordította az alkalmazásunkat, de még az automatizált tesztjeinket is lefuttatta minden kódfeltöltés (most már tudjuk mi is ez, ez a Git push) esetén. Mit is lehetne még mondani a VSTS-buildekről? Igazából a létrehozott buildünk sok mindent megmutatott abból, amire a build rendszer képes. Ebben a fejezetben nem hozunk létre ennél komplexebb buildet, inkább egy pár tulajdonságát emeljük ki a VSTS build rendszerének. 1. Ez egy új buildrendszer. Sokáig a build lépéseit XML-ben, XAML fájlokkal lehetett megadni. Bár voltak készen használható sablonok, ha valamiért a bennük leírtaknál többre volt szükség, a leírófájlokat kellett szerkesztgetni. Ez nehéz és fáradságos munka volt, és tényleg „Configuration Manager” titulus kellett hozzá, hogy valaki belevágjon. Bár kompatibilitási okokból még mindig működik a XAML-alapú build rendszer, de az új buildeket már az új rendszerrel érdemes megadni. Az új rendszer feladat-, vagy lépésalapú. Ez azt jelenti, hogy meglévő lépésekből tetszőlegesen összeépíthetünk egy bonyolultabb fordítási folyamatot is. Sok előre definiált lépést találunk a VSTSben, de ha továbbiakra lenne szükség, akkor használhatjuk a PowerShell stepet, aminél aztán tetszőleges PowerShell scriptet lefuttathatunk. 2. Nem csak .NET vagy Windows alapú feladatokat végezhetünk el. Előre definiált step-ek vannak Java, Node.js és Xamarin projektekhez, de használhatunk Ant, CMake vagy akár sima shell scriptet is. 3. A VSTS-projekttel együtt, meghatározott mennyiségű ingyenes build időt is kapunk a VSTS felhőalapú build szerverein. Ez azt jelenti, hogy kisebb projektek esetén nincs is szükség arra, hogy saját build szervert üzemeljünk be. Ez az úgynevezett „Hosted Agent”, amely természetesen használható nagyobb igényű projektek esetén is, csak akkor már nem ingyenes. 4. Ha a felhőalapú build szolgáltatásai nem elégségesek (például valamilyen speciális programra vagy hardverre van szükség a build szerveren), üzemeltethetjük a build szerverünket a céges hálózatban is, függetlenül attól, hogy a projektünket a felhőalapú VSTS-ben menedzseljük. Egy ilyen szerver beállítása csak pár percet vesz igénybe, és nincs szükség VPN vagy más speciális hálózati kapcsolat kialakítására, mivel a kapcsolatot a cégen belül üzemeltetett szerver kezdeményezi. A build szerver akár egy Linux-os gép is lehet. 5. A build-eket nem csak fordításra és tesztelésre, hanem telepítésre is lehet használni. Ehhez egyszerű esetben csak egy valamilyen deployment step-et kell behúzni a build definíciójának végére,

•••

23/24


bonyolultabb esetekben lehetőség van különböző telepítési fázisok, stage-ek definiálására és az alkalmazás verzióinak – megadott házirend és protokoll szerinti – telepítésére. Ez utóbbiak a VSTS- projekt „Release” füléről kiindulva fedezhetőek fel. Összességében elmondhatjuk, hogy az új step-alapú buildrendszerrel könnyen lehet buildeket definiálni és a projekt speciális igényeihez szabni. A felhőalapú buildszerver farm hatékony megoldás lehet, amennyiben a cégen belül nem áll rendelkezésre a megfelelő buildszerver infrastruktúra, vagy csökkenteni szeretnénk az egyszeri nagyberuházás kockázatát. Erről egy korábbi cikkemben is olvashatsz bővebben.

SZINTÉN RICSI? Ebben a cikkben a VSTS használatába szerettünk volna egy kis betekintést nyújtani, egy kis, autonóm, agilis csapat szemszögéből. Ricsi, a konfigurációmenedzser története mutatta be a problémákat, amelyek a régebbi, centralizált projekt szervezés eredményei. Tervünk az volt, hogy megmutassuk, hogyan lehetne ezt jobban csinálni a Team Foundation Server felhőalapú változata, a Visual Studio Team Services segítségével. Először 15 perc alatt létrehoztunk egy webes alkalmazást, amit VSTS-ben menedzselhetünk. Már ez a kis tizenöt perces app elég volt ahhoz, hogy számos dolgot megmutathassunk a modern projekt csapatok hatékony támogatásával illetve a VSTS ehhez tartozó funkcióival kapcsolatban. A további fejezetekben az agilis projektek egy-két fontosabb elvárásaiból kiindulva vizsgáltuk meg – a teljesség igénye nélkül – hogy milyen módon tudjuk a VSTS-t felhasználni céljaink elérésére. Beszéltünk a projekt böngészőn keresztüli könnyű elérhetőségéről, arról, hogyan lehet elérni, hogy a konfigurációmenedzselés bizonyos feladati egy emberre háruljanak. Megvizsgáltuk, hogyan lehet a VSTS-t úgy beállítani, hogy az leginkább támogassa a mi fejlesztési modellünket. Végül beszéltünk az elosztott verziókezelők, és azon belül a Git szerepéről az agilis projektekben, illetve arról, hogy a VSTS build hogyan tud hatékony és skálázható módon egyfajta biztosítóhálóként ügyelni az alkalmazásunk minőségére. Mindezek a feladatok régebben csak lassan és nehézkesen voltak elvégezhetők, és speciális szerepkört igényeltek, mint amilyen Ricsi is volt. A VSTS-el ma már bárki el tudja végezni ezeket a feladatokat és így a projekt sokkal gördülékenyebben tud haladni. Bárki lehet Ricsi. A VSTS oldalához kattints ide: https://www.visualstudio.com/en-us/products/visual-studio-team-servicesvs.aspx

•••

24/24

Bevezetés a Visual Studio Team Services használatába

Recommend Documents