BUILDIEN HALLINTA TFS 2012 OSA 1

Hei, nimeni on Tommi Kemppi ja työskentelen ohjelmistokehitystehtäviin ja ohjelmistojen elinkaaren hallintaan erikoistuneena konsulttina.

Aion jakaa tietämystäni TFS versioista 2012 ja ehkä 2010 jos sellaiseen vielä pitää viitata jossain. Ideana on että teen sarjan julkaisuja joista ensin keskityn TFS aiheeseen Team Build. Joka muuten on yksi lempiaiheistani.

Mihin tarvitaan Team Build ominaisuutta? Eikö olisi vaan helpompaa koodata ja toimittaa? Kuvaan tässä seuraavaksi tyyppiesimerkin siitä, miltä tuntuu koodata ja toimittaa.

Sinulla on yleensä toiminnallinen määrittelijä kun alat valmistamaan ohjelmistotuotetta. Hän yleensä kuvaa sinulle mitä sinun pitäisi rakentaa. Kuvaukset vaihteleva mutta loppujen lopuksi sinulla on käsisässi otus nimeltä käyttötapaus tai toiminnallinen spesifikaatio. Vaikka et tee formaalilla tavalla ohjelmistokehitystä niin ennenkuin aloitat ohjelmoimisen, tulisi sinulla olla ainakin idea siitä mitä halua saavuttaa. Ilman sitä sinun on aika vaikea ohjelmoida mitään järkevää.

Sitten aloitat koodin vääntämisen. Laitat muutoksia koodiisi (toivottavasti käytät jotain versionhallintaa) jotka alkavat muodostaa osia summasta joka tulee käsittämään tätä käyttötapausta mitä halusit saada aikaiseksi. Alat valmistamaan käytännössä erillisiä paketteja joista toimitus koostuu.

Nyt on aika laittaa valmiit paketit laatikkoon jotka muodostavat toimivan käyttötapauksen. Eli tämä on ensimmäinen versio ohjelmistostasi. Yleinen termi on englanniksi Release tai siis julkaisu näin härmäksi. No mitä tälle julkaisulle tehdään? No tietty se toimitetaan sille joka sen tilasi. Mutta hetkinen? Entä jos sinä tai kollegasi julkaisitte väärän kokonaisuuden? Mitä jos kaveri jonka pitäisi asentaa julkaisunne ei olekaan tilanteen tasalla ja sohlaa koko homman? Mitä jos se mitä tilaaja kuvitteli saavansa ei vastaakaan sitä mitä toimitit? No sitä varten meillä on hieno asia nimeltä laadunvarmistus.

Eli tarvitse henkilön jolla on kaikki tarvittava tieto testata kaikki paketit julkaisussasi ennenkuin julkaisu toimitetaan. Tämä henkilö katsoo sitten suurennuslasilla läpi tuotostasi ja ilmoittaa sinulle jos olet tehnyt typeryyksiä. Sitten korjaat ongelmat ja liität muutoksen pakettiisi. Nyt laadunvarmistaja kuittaa että homma on sitä mitä tilattiin toiminnallisen määrittelyn tai tilaajan kanssa käydyn keskustelun (esim. kolme viikkoa sitten) perusteella. Hienoa mutta olit liian hidas. Tilaaja sanookin että en tarvitsekaan tätä enää, pidä tunkkisi J ja laittaa sinulle tietoa siitä mitä hän haluaa nyt. Tätä kutsutaan muutoksen hallinnaksi.

Muutoksen hallintaa varten tarvitset muutospoliisiin joka varmistaa että että muutoksilla et riko kaikkea mitä on tähän asti tehty tai poikkea liikaa siitä minkä pitäisi olla ylläpidettävä lopputulema kokonasuutta ajatellen. Hän tutkii muutoksen aiheuttamat seuraukset ja antaa ohjeet mitä pitää tehdä että homma pysyy kasassa. Sen jälkeen voit jatkaa siitä mihin jäätiin eli toistat kaiken mitä juuri kuvasin ylemmissä kappaleissa.

Mitä jos voisit vain keskittyä koodaamiseen. Sitähän sinä haluat tehdä ja sillä saadaan jotain aikaiseksi eikä näillä kiusaavilla yksityiskohdilla. Mutta totuus on että nämä asiat pitää olla kunnossa että toimitus onnistuu. Mitä jos esittelen sinulle vielä yhden kaverin englannin kieliseltä nimeltään Build Manager. Aika sankari oikeasti on tämä henkilö liittyen ylläoleviin asioihin. Hän katsoo mitä puuhaatte ja tulee sanomaan että mitä jos vain painat aina tätä yhtä nappia kun haluat tehdä nuo kaikki yllä olevat asiat. Mikä ihmeen nappi kysyt?

Tämä on suurin syy miksi haluan puhua Team Build -aiheesta. Ja sehän on vain oma osa-alue Team Foundation Server 2012 tuotteen ominaisuuksista.