Buildien Hallinta TFS 2012 osa 2: Koodin laatumittarit automaattisesti
Tämä on toinen osa blogiani, jossa käsittelen elinkaaren hallintaan tarkoitettua Microsoftin tuotetta Team Foundation Server 2012.
Käsittelin aikaisemmassa blogikirjoituksessani jatkuvan integraation buildejä. Toivottavasti luit sen ensin että saat vähän johdantoa tähän, koska nyt lopetetaan ”slideware” -puheet ja sukelletaan itse tekniikkaan.
Moni varmaan on lukenut useasti siitä, miten tehdään team buildejä. Jos minulta kysytään, mikä hyöty jatkuvan integraation buildeista on, niin sanoisin sen olevan usein toistuvien kehitykseen liittyvien yksinkertaisten toimenpiteiden automatisointi.
Näitä toimenpiteitä ovat:
- laadunvarmistus statistiikan kerääminen
- ohjelmiston yksikkötestien määrä, onnistumisprosentti sekä testien kattavuus suhteessa koodiriveihin
- ohjelmiston integraatiotestien ajaminen
- ohjelmiston asennukset erilaisiin testi – ja laadunvarmistusympäristöihin
- automaattisten UI testien ajo tiettyä versiota vasten
- koodimuutosten liittäminen johonkin tiettyyn ”Releaseen”.
Tässä on yleisimmät esimerkit, joista lähden liikkeelle.
Otetaan tässä julkaisussa esimerkkinä laadunvarmistusstatistiikan kerääminen, koska se on yleensä se alue missä laiskotellaan.
Miten saadaan määriteltyä, millä pelisäännöillä koodin analysointi ja metriikat toimii?
Tuloksia näkyy siis Visual Studiossa seuraavalla tavalla. Koska olen ollut huolimaton, niin analyysi havaitsi prosessoriarkkitehtuuriin liittyvän ongelman, josta se varoittelee alla.
Toinen koodin analysointiin liittyvä toiminto, jota manuaalisesti saadaan hyödynnettyä Visual Studiolla, on koodin metriikat.
Lopputulema näyttää seuraavalta. (Tarkemmin termistö on selitetty täällä: msdn.microsoft.com/en-us/library/bb385914.aspx)
Siitä vaan käyttöön metriikan kerääminen. Entä jos joku joutuu toistamaan nämä viikon aikana päivittäin ja vielä useammille sovelluksille ja budjetti kärsii siitä, kun ei tehdä koodia jolla saadaan käyttötapaukset valmiiksi? Kokemukseni mukaan tätä ei tehdä yllämainitun syyn jälkeen ollenkaan, mistä sitten johtuu se että laatu kärsii.
Ympäristö ja tarvittava dokumentaatio
Lue näiden linkin takaa löytyvät asiat huolella:
- Dokumentaatio miten CodeMetrics aktiviteetti rakennetaan build prosessiin
- Täältä saa code metrics power toolin
Minulla oli tämän kokeen tehdessäni seuraavanlainen ympäristö:
- Windows Server 2012 Standard
- TFS 2012 SP3
- VS 2012
- VS 2010 SP1
- SQL SERVER 2012 Enterprise
- DC Role, APPLICATION SERVER ROLE
Vaihe 1: Luo Aktiviteetti kirjastoprojekti
Ensimmäisenä latasin nuo ohjelmat testikoneelleni ja sitten loin Visual Studiolla ”Activity Library” -projektin.
Laita seuraavat viittauskirjastot projektiin:
Ja nyt ota Build Extensions July 2013 paketista seuraavan kansion sisältö: “..\TfsBuildExtensions July 2013\Code Activities\VS2012”.
Ja kopioi se tänne: “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\”.
Sitten hae projektiin viittaus tähän DLL -kirjastoon: “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\TfsBuildExtensions.Activities.dll”.
Lataa projektiin haluamasi ”build process template”. Minä käytin seuraavaa prosessitiedostoa pohjana:
“DefaultTemplate.11.1.xaml”. Tämä löytyy mistä tahansa TFS 2012 luomasi tiimiprojektin versiohallintajaon ”Build Process Templates” alta.
Tämän jälkeen käännä projekti.
Vaihe 2: Metriikka aktiviteetin lisääminen prosessitiedostoon
Avaa Build prosessitiedosto, jonka lisäsit projektiin:
Kun prosessi tiedosto aukee valitse tools --> Choose Toolbox items --> Browse.
Paikallista TFSBuildExtentions.Activities.Dll ja paina: ”Open”. Ja kuittaa takimmainen ikkuna ok –painikkeella.
General-kategorian alle ilmestyi nyt lista uusia aktiviteettejä:
Vie Metriikka aktiviteetti prosessissa oikeaan paikkaan. Huomioi, että koodin pitää olla kääntynyt ja paikallaan binäärihakemistossa ennen kuin voit käyttää prosessissa tätä aktiviteettia. Alla olevassa kuvassa näkyy hyvä paikka aktiviteetille.
Seuraavaksi aseta oikeat asetukset aktiviteetille. Alla näkyvät minun käyttämät asetukset:
Huomaa, että viittaan ”Files To Process” –kentässä ”WcfService1.dll” -arvoon. Tätä sovellusta ajan buildilla, joten muun metriikan keräyksen välttämiseksi haluan, että metriikat kerätään vain tästä dll –tiedostosta. Olin nyt niin laiska, että en jaksanut viitata suoraan dynaamisesti ”build output” –muuttujiin. Voitte itse miettiä miten se onnistuu.
Tämän jälkeen tallenna template ja käännä projekti.
Vaihe 3: Kustomoidun prosessin liittäminen TFS Build serveriin.
Kun käänsit projektisi sait tuloksena tarvittavat kirjastot, mitkä pitää liittää Build Controllerin custom assemblies määrityksen alle. Minulla tämä polku oli:
“C:\Users\Administrator\documents\visual studio 2012\Projects\BuildExtensions\BuildExtensions\bin\Debug”
Ja siellä pitäis olla seuraavat tiedostot:
Tämä sisältö pitää saada versionhallintaan, jotta Build Controllerin määrityksessä voidaan viitata sinne.
Minulla tämä määritys oli seuraava:
Tämän jälkeen myös kustomoitu prosessitiedosto pitää viedä versionhallintaan. Minä vein sen eri nimellä seuraavaan paikkaan:
Vaihe 4: Liitä kustomoitu prosessi osaksi Team Buildia
Loin uuden ”Build Definition” –määrityksen TFS:ään nimellä ”MetricsBuid” ja viittasin kustomoituun prosessitiedostoon:
Sitten vain ajetaan ”Metrics Build”. Huomaatte varmaan build historiasta (eri värisistä palkeista otsikon alla) että tämä vaati hieman kärsivällisyyttä ennen kuin parametrit sai kohdalleen ja että kustoitu aktiviteetti ensinnäkin viittasi oikean version DLL –kirjastoihin.
Sen lisäksi piti tehdä pieni kikkailu, josta kerron kappaleen lopussa nimeltä ”Mahdolliset ongelmat”.
Kun katsomme tarkemmin View Log –painikkeen takaa, mitä statistiikkaa löytyy, niin huomataan että minun WcfService1.dll oli ajettu metriikka-analyysi ja se löytyy Metrics.xml tiedostosta.
Tässä vielä metriikkatiedoston sisältö:
Kun klikkaan linkkiä Metrics.xml, näen suoran raportin koodin metriikoista yleisesti ja alempana per kooditiedosto ja jopa per metodi.
Mahdolliset ongelmat
Voit törmätä buildia ajaessasi virheeseen numero 777. Tämä ongelma johtuu sitä miten parametrit ovat asetettu. Esimerkiksi, jos SearchGAC on false, ei Metrics.exe osaa etsia viittauksia GAC:ista. Tämän ongelman ratkaisin sillä, että filteröin sitä mitä haluan analyysin ajavan. On ehkä hieman turha ajaa analyysiä DLL –tiedostoille, jota et itse ole rakentanut vaan ne ovat Microsoftin kirjastoja tai muita kolmannen osapuolen tiedostoja. Metriikkahan on tarkoituksen mukaista mitata siitä koodista mitä itse ollaan kehittämässä.
Toinen virhe mitä ihmettelin hieman oli virhe koodi 256. Tämä johtui siitä, että Activiteetti on laitettu viittamaan kansioon ”C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop”. Jos käyttää Visual Studio 2012 tuotetta, niin vastaavat kirjastot, joihin Metrics.Exe pitäisi laittaa onkin ”C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop”.
Olin nokkelasti kiertänyt tämän kopioimalla FxCop hakemiston 11 -version polusta vastaavaan 10 -version polkuun, mutta se ei riittänyt. Tuo PhoenixAnalysisEngine.dll viittasi jonnekin ylemmäs ja ongelmat ratkesi kopioimalla Static Analysis Tools –kansion sisältö kokonaisuudessaan 10 –version vastaavaan kansiopuuhun.
