Rétikánya blogja

A madarak fentrõl szemlélve másképp látják a világot...

Visual Studio Team System – Miért is?

Rendezgetem saját jegyzeteimet, és kezembe ötlött egy firkalap, amit a telefonbeszélgetések alatt szoktam irogatni (kivel mirõl is beszélek). Nézegetem és szemembe ötlik egy kérdés amit elég sûrûn hallok: “Visual Studio Team System Miért is? Mire jó ez egyáltalán?”

A kérdést anno én is sokat feltettem magamban, félhangosan és kimondva is, de nem nagyon kaptam rá választ! A Microsoft Magyarország érintett munkatársaival való beszélgetéseim során magam is meggyõzõdtem arról, hogy még ott sem mindenki érti és tudja a választ. Ma még mindig sokan ott tartanak, hogy a termék mûszaki, fejlesztõi mélységeit akarják megmutatni és bíznak abban ezzel meg tudják mutatni a lényeget, pedig dehogy!
A Visual Studio Team System lényegét a neve is jól mutatja, csoport(munka) rendszer. Lényege, hogy a fejlesztõi csoport (érsd projekt) munkáját fogja össze, tegye átláthatóbbá, szervezettebbé. Természetesen számos technikai szolgáltatást, trükköt is bevetettek ennek érdekében, így egy darabig nézhetjük a fejlesztõknek szóló újdonságait, de ha a végére érünk még mindig csak a jéghegy csúcsát fogjuk csak látni.

A Visual Studio Team System Developer fejlesztõi támogatása természetesen több, mint a Professional Edition által nyújtott szolgáltatások. Ez hamar kiderül, ha a két verzió nyújtotta szolgáltatásokat egymás mellé helyezzük. Nagy segítséget nyújtanak eme szolgáltatások természetesen, de a termék tartalmaz egy “rejtélyes” Team Edition CAL-t is, és itt van a kutya elásva!

Amint telepítünk és használatba veszünk egy Team System rendszert, máris egy sor know-how-t kell át- és felvennünk. Ezek azok a bizonyos módszertanok amelyek mentén felépített projektünk máris egy jobban átlátható és kezelhetõ motorként fog dohogni! Itt van a dolog lényege elrejtve! A rendszer használata, a számos kis apróság (forrás kód kezelõ, tesztelõ motor, stb.) mind mind ezt a célt szolgálják és segítik. Természetesen adja magát a kérdés, mennyit is ér mindez? Egy átlag projekten a hatékonyság javulása a megtakarításokkal mérhetõ. A VSTS használatával a megtakarítások az alábbi számokat eredményezik (a nemzetközi felmérések szerint):

  • Tervezés 40%
  • Implementálás 30%
  • Képzés, betanítás 10%
  • Fejlesztés 10%

Kérdezhetitek miért csak 10% a fejlesztési megtakarítás? A válasz egyszerû, egy jól megtervezett és átgondolt kódnak az elkészítésén már nehéz megtakarítást eszközölni (ekkor jön képbe a tesztelés és a forráskód kezelõ), és a többi eszköz ráadásul már a Professional változatban is elérhetõ. Viszont a fejlesztés azért tud könnyen és rugalmasan menni mert mûködik a projekt! A projektünk hatékonysága azonban – mint a fenti számok is mutatják – jelentõsen javul, és ezzel a projekt összes bekerülési költsége jelentõsen csökken.

Az egyik elõadáson érdekes adatokat mondtak erre példának:
Az EDS-nél és a DELL-nél is több projekten vizsgálták a ROI változását a VSTS bevezetését követõen. Azt tapasztalták, hogy a az EDS 4 hónapos referencia projektje a szokott számokhoz viszonyítottan 286%-os ROI javulást, míg a DELL 6 hónapos referencia projektje 225%-os ROI javulást mutatott. Elgondolkodtatóak a számok és az is, hogy ez a teljes projektre viszonyítottan jött ki…

A Microsoft önmaga is elkötelezett a Visual Studio Team System és az ebbe implementált logika mellett, ezt mi sem mutatja jobban, hogy saját belsõ projektjein is ezt használja, illetve ahol nem azokat is folyamatosan migrálja.

A rendszer robosztusságára jó adatok a következõ a Microsoft SQL rendszerének fejlesztésérõl kapott információk:
A Microsoft fejlesztõi diviziójának munkája során a rendszer
3073 felhasználót szolgál ki
100 millió fájlt, 20 millió könyvtárban kezel
A kezelt adatok 1.2 TB-t tesznek ki tömörítve
36 millió letöltés kerül kiszolgálásra hetente
268.000 work item kezelését végzik jelenleg a rendszeren
és most csak az SQL Server csapat használja…
…jelenleg folyik az Office Team bemozgatása a rendszerre és megkezdõdött a Windows Team beemelési projekt.

A fentieket átgondolva mi is képet kaphatunk arról, hogy a VSTS nem csak egy fejlesztõi termék, s megismerése nem csak a .NET keretrendszer és egyéb technikai csodák megértését igénylik, hanem szükségünk van a fejlesztõ projektünk elképzelése, megvalósítása során egy következõ szintre továbblépni!

Végezetül találtam egy összefoglalót ami szépen számbaveszi mik is azok az “apróságok” amiét nyújt számunkra a rendszer. Íme:

Adminisztráció

  • SharePoint 2007 támogatás (extra porton is :))
  • Reporting Services támogatás (másik szerveren és extra portokon is)
  • Nevesített SQL szerverek használata – így egy SQL szerveren több TFS is futhat
  • Windows 2008 támogatás
  • SQL Server 2008 támogatás
  • Upgrade támogatás TFS 2005-rõl
  • Performanciareszelések sokasága (akár 30,000 konkurens felhasználó)
  • Egyszerûsített telepítés (nincs külön data-tier telepítés, nem kell annyi speciális felhasználó, nem kell mindenkinek adminnak lennie, stb.)
  • Jobb támogatás speciális esetekre (cluster, tükrözés, log shipping, virtuális gépek, stb.)
  • Permanens törlés
  • Certificate alapú azonosítás

Build

  • Többszálú fordítás az új MSBuild-del, források kiválasztása részletesebb szabályok alapján
  • Continuous Integration – build queue, szabályok alapján buildek törlése, build minden checkinnél, minden sikeres/sikertelen build után, stb.; checkin policy a broken build esetére, kapcsolódási lehetõség pl. a CruiseControl.Net-hez.
  • Bõvített ‘cél’kezelés, fõleg a kiterjesztés szempontjából
  • Studióból a fordítás leállítása/törlése
  • .NET-bõl objektummodel a build server ellen
  • Automata tesztelési definíciókat (amik akár GUI tesztek is lehetnek mostmár!) végre könnyen beilleszthetjük a fordításba
  • Maga a build definíció bárhova helyezhetõ a TFS-en belül, nem csak a TeamBuildTypes helyre
  • Idõzíthetõ a build
  • Könnyebben konfigurálható build agent
  • HTTPS alapú kapcsolat felépíthetõsége a TFShez
  • Inkrementális fordítás támogatás

Migráció

  • Migration toolkit – konverzió és tükrözés felépíthetõsége ez alapján más rendszerek felé – a népszerû alternatívák felé MS támogatással készülnek el a megoldások

Verzió kontroll

  • Annotate – a power toolban lévõ eszköz továbbfejlesztése
  • Folder Diff – a power toolban lévõ eszköz továbbfejlesztése
  • Destroy – permanens törlés az adatbázis méretének csökkentésére, könyvtárak és fájlok esetére akár úgy, hogy a change set history megmaradjon
  • Get Latest On Checkout – a SourceSafe féle megoldás bekapcsolható – tehát checkoutnál felülírathatod a nálad lévõ fájlt a TFSben lévõvel
  • Workspace mappelési újdonságok – alfolderek nélkül is mappelhetõ végre egy könyvtár
  • Performancianövelés – fõleg 10.000 fájl fölött látszik a különbség – de hát ugye elég gyorsan el lehet érni ezt 🙂
  • Skálázhatóság – többszázezer fájlokra is kiadhatóak mostmár az egyes mûveletek
  • Offline – online kapcsolatok támogatása a felületeken
  • Command line help – nem hangzik nagy dolognak, de azért sokat segít…
  • Source Control Explorer újdonságok – automata frissülés más helyen történõ változások alapján, aszinkron mûködés, útvonalak másolhatósága
  • Merge algoritmus javítások – kevesebb hamis jelzés

Work Item kezelés

  • Performancia és skálázhatóság… míly meglepõ 🙂
  • Query builder felhasználói élmény – drop down, MRU, drag & drop, multi column sort, tooltipek, stb.
  • Csatolások jobb kezelése – drag & drop, multi select, stb.
  • Iterációs elemekre is érvényes biztonsági beállítások

Webes hozzáférés

  • A TeamPlain Web Access megvásárlásával most még csak Power Toolként a jelenlegi verzióhoz, de késõbb már integráns részeként a terméknek fog megjelenni a webes felhasználói felület

Kompatibilitás az elõzõ verzióval

  • A kliens oldali VS add-inokat újra kell fordítani vagy binding policy kell hozzá, mivel megváltoznak a verziószámok
  • A Build funkcióknál van néhány fontos változás:
    • Az Orcas TFS server csak Orcas build serverrel megy együtt
    • VS2005-tel indítani lehet buildet, de a queue management nem látszik
    • Orcas kliens nem fog tudni TFS2005-n új build definíciókat kezelni
    • És néhány hasonló bosszantó apróság… szóval ha buildeket akarunk kezelni, ne akarjunk hybrid rendszert építeni

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.

*

© 2019 Rétikánya blogja

Theme by Anders NorenUp ↑