Microsoft SharePoint kehityksen hallinta Team Foundation Serverillä

Moi, blogissani on ollut hiljaista vähän aikaa lapsen syntymän johdosta, mutta nyt sain vihdoin aikaa palata asiaan. Moni varmaan on miettinyt sitä sopiiko Team Build ainoastaan omiin räätälöityihin ohjelmistojen kehitysprojekteihin. Tai miettinyt jopa sitä, että MS:n omat tuoteräätälöinnit eivät tuota lisäarvoa Team Buildiin liittyen tai TFS:ään liittyen, kun sehän taisi olla vain se kallis versiohallintajärjestelmä.

Jos tätä mieltä olet, olet väärässä. Osoitan kirjoituksellani perusteet tälle. Otetaan esimerkkituotteeksi Microsoftin lippulaiva SharePoint.

Vielä sellainen huomio, että en käsittele ”APP – model” -kehitystä SharePoint kehityksenhallinnassa tässä blogissa, koska useammassa firmassa tähän ei ole vielä siirrytty. Eli tässä käytän esimerkkinä SharePointin WSP - paketein toimitettavasta lisätoiminnallisuudesta SharePointin päälle. Samat perus- lainalaisuudet säätelevät tosin ”APP – model” – kehitystäkin, mutta osa asioista on eri tavalla. Lisäksi tässä blogissa en paljasta teknisiä niksejä, vaan yritän ensin vastata kysymykseen ”Miksi”. Seuraavassa blogikirjoituksessani sivuan sitten sitä, että ”Miten”.

 

Yleisprosessihan SharePoint -kehityksen kannalta menee jotakuinkin alla kuvatun piirroksen mukaisesti. Tämä siis on korkean tason kuvaus ja sisältää oletuksia siitä, miten olen nähnyt hommaa yleisesti täällä Suomessa pyöritettävän. Tämäkin toimii, mutta prosessi pitää kertoa toimittajien määrällä ja asennustiheydellä, jotta saadaan laskettua tuntimäärinä kokonaiskulu sille kuinka paljon työtä tällaisen mallin ylläpito vaatii. Nyt vaan prosessitehostajat laittakaa taulukkolaskentaohjelma päälle ja laskurit ja diagrammit valmiiksi.

 

Mitä, jos homma menisikin näin:

Huomioitavaa on, että koodauksen ja loppuasennuksen lisäksi TFS hoitaa kohdat 1-5. Jos UAT menee pieleen, niin kohdat 1-5 toistetaan, kunnes toimittaja saa koodattua toimivan ratkaisun. Valmiiksi hiottuna tässä on se hyvä puoli myös, että kohdassa 1.x kysymys on myös työn seurattavuudesta, joka saadaan kaupan päälle. Lisäksi kysymys on laadunvarmistuksesta jo siinä vaiheessa kun koodia tuotetaan. Jo sillä, että Check-in policy on määritelty niin, että kommentit ovat pakollisia ja pakko liittää johonkin työkorttiin, saavutetaan peruslaatu toimituksiin. Sen lisäksi Gated check-in huolehtii siitä, että koodi kääntyy eikä tule kysymystä siitä kuka on rikkonut koodin.

Huom. Kohdan 6 voi myös hoitaa TFS:n uusilla ominaisuuksilla kuten Test Hub. Ja tähän saa myös linkitettyä raportoinnin.

Varsinkin tämä on tärkeää, kun asiakkaalla on monta toimittajaa ja etenkin jos nämä toimivat vielä samassa projektissa. Kuvassa tämä ei näy, mutta tähän kun lisätään testaus ja automaattinen raportointi, minkä TFS tarjoaa, niin saavutetaan lisäkontrollia siihen mitä toimittaja tekee ja mitä asiakas saa.

Eli loppupeleissä kysymys on siitä, että jos et saa prosessia seurattua ja teetät manuaalityönä asiat joita automaatio voisi hoitaa, menetät rahaa. Tarvittavat lisenssit, järjestelmä ja sitä pyörittävä järjestelmänvalvoja säästää aika nopeasti rahasi takaisin. Ja järjestelmää ei nykyään ole pakko pyörittää edes omassa palvelinkeskuksessa kun pilvikin on keksitty. Lisäksi sinun pitäisi ostaa koodin immateriaalioikeudet itselle, koska silloin voit vaihtaa toimittajaa jos työ ei miellytä. Tämä voi töpätä siihen, että et tiedä miten toimituksia voisi hallita. Oma tai palveluna ostettava TFS tarjoaa ratkaisun, mutta mikään väline ei poista sitä faktaa että jos organisaatiossa joku ei pakota järkeviä käytäntöjä, niin tulet jäämään tähän ongelmaan jumiin. Kysymys on siitä, miten hallintaan sovelluksen elämänkaarta. Siitä tuleekin englanninkielinen termi ALM. Onko TFS vielä mielestäsi pelkkä versionhallinta? Seuraavassa blogissa osoitan teknisen esimerkin siitä, miten tämä tehdään.

Comments

• Anonymous
  November 06, 2013
  Erinomainen artikkeli jälleen kerran :-)