Microsoft SharePoint kehityksen hallinta Team Foundation Serverillä – OSA 2
Terve taas hyvät MSDN-blogin lukijat, jatkan edellistä aihettani liittyen SharePoint kehityksen hallintaan Team Foundation Servereillä. Viimeksi kirjoittelin SharePoint kehityksen hallinnasta teoreettisemmin ja nyt siis kuvaan enemmän käytännönläheisesti perusteita, jotka on hyvä tietää, mikäli teet töitä TFS Build palvelimella ja SharePoint-sovelluksilla.
Käyn läpi, mitä muutoksia tarvitaan Build-palvelimella, voidaksesi ajaa SharePoint-sovelluksien build- prosesseja. Tämä on aika hyvin ohjeistettu Microsoftin MSDN-artikkeleissa, mutta niin kuin aina on eri asia tietää polku kuin kulkea sitä. Tässä blogissa kerron tämän polun kulkeneen ”matkamuistiinpanot”.
Mitä pitää tehdä build-palvelimelle, jotta SharePoint-sovelluksen rakentaminen onnistuu?
Alla on kuvattu käyttämäni ympäristö, jolla tein tämän kokeilun:
Ensimmäinen palvelin: Windows Server 2012 Standard:
- TFS 2013 Application Tier, Build Service ja VS 2013 Premium
- SharePoint Foundation 2013
- SQL Server 2012
Toinen palvelin: Windows Server 2012 Standard:
- Active Directory role
Ympäristö oli toteutettu Windows 8.1 Hyper-V featuren päälle. Käytin yhtä sisäistä verkkoa, jossa domain pelaa ja yhtä ulkoista verkkoa NAT / Connection Sharing – toiminnon läpi HOST-koneella.
Sitten itse asiaan:
Ensinnäkin, käy läpi tämä alla oleva MSDN-artikkeli hyvin tarkasti:
msdn.microsoft.com/en-us/library/ff622991.aspx
Huomioi, että nämä ohjeet ovat tehty TFS 2012 asennukselle ja minä käytän esimerkissäni TFS 2013 asennusta.
Etenkin yllä olevassa materiaalissa, katso kohta otsikolla: ”Install SharePoint Farm and Sandboxed Solution Build Support”.
Huomioitavaa tuossa ohjeessa on se, että jos sinulla on alustana Windows Server 2012, et voi asentaa Identity Foundationia ohjeiden mukaan. Sen sijaan asenna ”. NET 4.5 Feature”:
Toinen asia, mikä on hyvä tiedostaa, on että Office Developer tools on nykyisin sisäänrakennettu Visual Studio 2013 versioissa. Tässä lisätietoa aiheesta: msdn.microsoft.com/en-us/library/bb398242.aspx
Työnkulku-sovelluksen ajamiseen Build Serverillä:
Tein yksinkertaisen Visual Web Part - sovelluksen ja katsoin että se kääntyy sekä tuottaa WSP - paketin:
Sitten määrittelin build-prosessin itse muokkaamallani Build-prosessitiedostolla nimeltä: SharePoint13DailyBuild.xaml, jota olin käyttänyt TFS 2012:sta.
Pääkohdat sille mitä tämä prosessi tiedosto tekee, on kuvattu lyhyesti alla:
Kuvassa 4 (korostettu ylempänä olevalla vihreällä ympyrällä) on kuvattu tuloste käskyistä, joiden tarkoitus on ennen varsinaisen build-prosessin aikana korvata tiedostoja kohdekansioon: ”C:\Program Files (x86)\ Reference Assemblies\SharePoint\”.
Tässä kohtaa voinet kysyä miksi noita tiedostoja pitää korvata viittauskansiossa?
Vastaus on yksinkertainen. Mitä jos pitää ajaa Build-prosessia eri SharePoint-versioita varten yhdellä TFS Build -koneella? Yksinkertaisesti ajan referenssikansioon ns. ”lennossa” oikean SharePoint-version DLL – tiedostot. Tämän avulla ei tarvitse asentaa kahta Build-ympäristöä, jos pitää olla tuki eri SharePoint- versioiden buildeille. Eikä tarvitse asentaa lokaaleja SharePoint asennuksia Build-ympäristöön. Nuo DLL- tiedostot pitää kaivaa oikean SharePoint-asennuksen ISAPI-kansioista.
Toinen asia mitä pitää muokata (Kuvattu kuvan 4 alimmaisen vihreän ympyrän sisällä), on se että WSP- tiedosto tiputetaan erilleen Drop-hakemistossa sijaitsevaan Release-kansioon, jonka sisältö korvautuu aina viimeisimmällä ajolla. Näin ollen asennuksista vastaava automaatioprosessi tai henkilö saa aina samaan paikkaan viimeisimmän sovelluksen.
Nämä ylläolevat asiat toteutin Build-prosessitiedostoa editoimalla ja lisäämällä aktiviteetteja olemassa olevaan Microsoftin Default Build Process -tiedostoon. En mene tässä blogissa tarkemmin erittelemään näiden toteutusta.
Tässä kuvakaappaus build – lokista (Huomioi se, että tässä esimerkissä en korvaa kaikkea mitä pitää, laitoin nämä Replace - lauseet tähän esimerkin takia):
Build-prosessin määritykset Visual Studiossa on kuvattu alla:
Tässä on määritelty se, minne tiputan Build-tuotokset:
Tässä on määritelty, mitä sovellusta ajan millä parametreillä. Huomaa ylimääräinen Build Argumentti: /p:IsPackaging = true. Tämä mahdollistaa Team Buildin ajavan WSP-paketin Drop-hakemistoon.
Buildin lopputuloksena on alla kuvatun näköinen kansiorakenne:
Tässä oli ihan perusesimerkki sille, miten SharePointin sovellusrakennus onnistuu TFS Build Serverillä. Tästä voidaan lähteä edelleen rakentamaan prosessia niin, että sama Build-prosessi ajaa paketin pudotuksen jälkeen myös esimerkiksi PowerShell-komentosarjan SharePoint asennusta vasten jolloin saadaan myös sovellusten Deploy-prosessi mukaan. Sitä en kuitenkaan lähde erittelemään tarkemmin, koska muuten blogistani tulisi valtava ja muutenkin asennusprosessit ovat yleensä tapauskohtaisia. Toivon, että tästä olisi apuja samojen asioiden kanssa painiskeleville.
Muuten tämä on viimeinen blogini tänä vuonna, joten toivon oikein rauhallista joulua ja oikein hyvää alkavaa uutta vuotta 2014.