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