[Sharepoint] Migraties en versiebeheer methodieken

[Jan_V]

Momenteel willen we bij ons op het werk het ontwikkelproces een beetje meer professionaliseren. Voorheen maakten we voornamelijk ASP(.Net) applicaties en daar hadden we het proces redelijk onder controle. Er waren meer dan genoeg verbeterpunten, maar op zich redden we ons prima.
Nu zien we een verschuiving van het ‘normale’ ontwikkelen in .Net naar Sharepoint. Onze focus ligt daarom het afgelopen jaar ook voornamelijk op het maken van Sharepoint sites en intranetten. Op zich werkt dit redelijk, maar tijdens het ontwikkelproces komen we toch iedere keer weer struikelblokken tegen die we nooit hadden met het ontwikkelen in ASP.Net.
Enkele voorbeelden die ik op kan noemen die we zijn tegen gekomen:
- Masterpages/stylesheets komen niet volledig mee, waardoor pagina’s er op ontwikkel en productie anders uit zien
- Contenttypes komen dubbel in productie te staan (wanneer er vaker dan 1x een migratie plaats vind)
- Webparts die niet meer goed werken (CQWP stijlen bijvoorbeeld, maar ook eigen custom webparts)
- Lastig debuggen van eigen webparts/custom pagina’s
Op zich kan ik nog wel meer dingen opnoemen, maar dat zou een redelijke lijst worden denk ik.
Het belangrijkste punt dat vaak mis gaat bij ons is het migreren van een server naar een andere server, bijvoorbeeld ontwikkel naar productie.
Met het commando stsadm –o export hebben we de ervaring dat niet alles goed wordt meegenomen en site kolommen en contenttypes soms dubbel in een siteverzameling worden geplaatst.
Met content deployment moet je ontwikkel server weer verbinding kunnen maken met de productie server, iets wat vaak niet mogelijk is danwel wenselijk.

Nu heb ik het een en ander proberen op te zoeken over het migreren van sharepoint websites van de ene naar een andere server, maar heb niet echt een goede methode gevonden. Vaak kom je eenzelfde vraag tegen van iemand die ook met zo’n probleem zit waar geen antwoord op wordt gegeven of een antwoord waar je eigenlijk weinig mee kan

Enkele tooling die ik tot nu toe heb gevonden (maar nog niet heb geprobeerd):
SMigrate -> Hiermee zou je sites moeten kunnen migreren van de ene naar een andere server en zou beter moeten werken als stsadm als ik de site mag geloven. (een blogpost die ik had gevonden: http://geekswithblogs.net...ive/2004/12/06/16898.aspx)
WSPBuilder -> Dit zou gebruikt kunnen worden voor het deployen van webparts en features van de ene naar een andere site, aangezien het de 12-hive eigenlijk ‘kopieert’
Sharepoint Content Deployment Wizard -> Komt volgens mij op hetzelfde neer als SMigrate, maar ziet er iets beter uit en met wat extra features (http://www.codeplex.com/SPDeploymentWizard)

Op zich lijken deze tools wel handig, maar ik vraag me eigenlijk af wat anderen gebruiken en wat de werkwijze is.
Op zich lijkt dat het gebruik van SCDW in combinatie met WSPBuilder een goede methode kan zijn. Volgens mij heb je dan al je Sharepoint content die je migreert, inclusief de 12-hive, waar al je webparts, features en custom pagina’s in staan (in de _layouts map).

Verder ben ik zelf nu ook bezig om een TFS 2008 op te zetten en bij een huidig project kijken of dit handig is om met Sharpoint te gebruiken. Hier heb ik nog nooit mee gewerkt, met TFS, maar hoor van iedereen dat het erg prettig werkt. Kun je met TFS dan een Sharepoint website in het versiebeheer plaatsen?
Momenteel lukt me dit namelijk niet met VS2008 en SourceSafe. Wanneer je namelijk een Sharepoint website probeert te openen krijg je een foutmelding. Wel zou ik graag zien dat je Sharepoint websites gewoon in VS2008 kunt wijzigen (inclusief de masterpages, stylesheets, workflows, etc). Sharepoint Designer is namelijk niet een applicatie die ik graag gebruik. Momenteel gebruiken we dat wel, aangezien we ‘niet beter weten’, maar fijn is anders.

Dit is een heel verhaal, maar in het kort komt het neer op deze vragen:
- Hoe migreren jullie Sharepoint sites van de ene naar een andere server (tooling en methodes)?
- Hoe wordt het versiebeheer aangepakt van pagina’s (TFS, VS2008, SPD, etc.)?

Ben benieuwd hoe anderen dit aanpakken.

[asfaloth_arwen]

Ik kan je de ervaringen van mijn vorige stage geven, echter denk niet dat je er erg vrolijk van wordt. Ik heb stagegelopen bij een SharePoint consultancy bedrijf.

Hoe migreren jullie Sharepoint sites van de ene naar een andere server (tooling en methodes)?

Hier heb ik van alles gezien, maar niet echt mooie oplossingen. Van scripts toch standaard backup and restore. Dit is op gegeven moment veranderd, met een externe backup and restore tool van Quest.

Hoe wordt het versiebeheer aangepakt van pagina’s (TFS, VS2008, SPD, etc.)?

Alles werd gedaan vanuit SharePoint designer, in testfases werden pagina's gerenamed naar pagina.old etc.
TFS zou de oplossing moeten zijn, maar hier heb ik nog geen ervaring mee. Ik ga over 1.5 week beginnen aan een project waar ik hiermee aan de slag ga. (onderdeel van mijn afstudeerproject)

[AlanSmithee]

Jan_V schreef op vrijdag 23 januari 2009 @ 09:11:
- Hoe wordt het versiebeheer aangepakt van pagina’s (TFS, VS2008, SPD, etc.)?

Wij werken vaak met paginas die in een class library project zitten en maken dan gebruik van tool/extra build stap zoals Andrew Connell op zijn blog heeft staan zodat er ook een CAB/WSP gemaakt wordt. Dan staat het project nu nog in Subversion en binnenkort met TFS in SourceSafe.

Als je een pagina bewerkt met SPD en versiebeheer wilt moet volgens mij de pagina Ghostable/Ghosted in een document libary zijn, waarop (verplicht) versiebeheer aan staat.

[jip_86]

TFS houd alleen je code bij. Je kunt er mooie aparte branches mee maken om gescheiden te ontwikkelen. Alle code voor een release weer samenvoegen naar een tak. Versiebeheer ook prima.

Ik heb wel gezien op mijn stage dat het niet meevalt om een goede TFS strategie uit te denken ( hangt van de hoeveelheid branches af en de wensen tot schuiven met code ).

Maar extra bestanden komen niet vanzelf in TFS. Een solution die in source control zit voegt wel de sourcebestanden toe enzo, maar eigen bestanden moet je handmatig er in zetten. Ook lost TFS het probleem met hoe te publiceren naar een andere server niet op.

[MikeN]

Volgens mij krijg je het nooit goed zolang je in Sharepoint designer blijft klooien. Voor zover ik weet wordt er bij het bedrijf waar ik bij zit gewoon netjes een site definition gemaakt, waarvan je dan een wsp hebt. Uitrollen in productie is dan een kwestie van je wsp deployen, upgraden is een kwestie van je wsp upgraden.

[Jan_V]

Als ik het goed begrijp stoppen ze dus de:
- Master pages
- Pagina templates
- XSL StyleSheets
- CSS
- Images
- mogelijk nog meer dingen die me nu even niet binnen schieten
in een WSP?

Als dat echt goed werkt, lijkt me dat een prima oplossing. Nadeel is wel dat je bij iedere wijziging in een van de onderdelen je wsp moet updaten en dus ook je application pools worden gerecycled (of een iisreset).
Ik dacht zelf dat wsp's voornamelijk bedoeld zijn om spullen in de 12-hive te stoppen en niet in de database, aangezien daar deze spullen worden opgeslagen.

Zal eens kijken of ik iets kan vinden over deze methode.

[reddog33hummer]

TFS houd alleen je code bij. Je kunt er mooie aparte branches mee maken om gescheiden te ontwikkelen. Alle code voor een release weer samenvoegen naar een tak. Versiebeheer ook prima.

Hoewel source control de grootste reden voor TFS is.
Zit er ook Work item tracking in om het process van ontwikkelen te sturen (zeer nuttig om "heb ik geprogd omdat het leuk was" tegen te houden).
Verder kan je via TFS hier raportages over draaien om inzicht in je process te krijgen.

Ik heb wel gezien op mijn stage dat het niet meevalt om een goede TFS strategie uit te denken ( hangt van de hoeveelheid branches af en de wensen tot schuiven met code ).

Dit is inderdaad iets waar goed over na moet denken.Als je dit verkeerd doet, achtervolgd je dit behoorlijk lang. Maar dat is voor elk soure beheer systeem.

Maar extra bestanden komen niet vanzelf in TFS. Een solution die in source control zit voegt wel de sourcebestanden toe enzo, maar eigen bestanden moet je handmatig er in zetten.

Installeer SP1 van visual studio en de TFS power utitilities (minimaal oktober 2008). Dan kan je complete directories toevoegen en krijg je in explorer een soort turtoise gedrag.

Ook lost TFS het probleem met hoe te publiceren naar een andere server niet op.

Indien je de Visual Studio sharepoint extentions gebruikt, dan kan je visual studio solutions gebruiken die sharepoint features bevatten. Deze kan je gewoon in je source control hebben (krijg je gewoon history over).
Omdat sharepoitn features los kan deployen naar servers, en kan je in de tfs build hangen (en dus elke nacht deployen geautomatiseerd en testen). Het grote punt waar je alleen rekening mee moet houden is dat het werken met features niet altijd zo inuatief werkt als het werken met backup en restores. Maargoed, je ontwikkel process en resultaat wordt betrouwbaarder.
Je hebt daarna ook de mogelijkheid om (b.v. wspbuilder) solutions te maken die ook op farms de hele otap sequence door kunnen.

Vergissingen die snel gemaakt worden met sharepoint ontwikkeling en tfs:
1. Met tfs wordt een sharepoint omgeving meegeleverd. Deze is voor het beheer van het ontwikkel process. Niet voor het tegenaan ontwikkelen.
2. Plaats de ontwikkelserver en test servers in virtuele images die je elke nacht reset (anders weet je nog niet waar je tegenaan test).
3. Test ook upgrades. Van versie 1 van het product naar 2.... is bij sharepoint wel eens een uitdaging.
4. Test ook clusters en farms, deze reageren anders dan een enkele machine in farm modus.
5. Je tfs machine gebruiken als build server (onder het motto, machines sparen). Je buildserver is de meest vuile machines in je netwerk. Deze kan je tfs server onderuit trekken -> source niet beschikbaar.

[ Voor 3% gewijzigd door reddog33hummer op 23-02-2009 09:25 ]

[reddog33hummer]

Jan_V schreef op donderdag 19 februari 2009 @ 15:19:
Ik dacht zelf dat wsp's voornamelijk bedoeld zijn om spullen in de 12-hive te stoppen en niet in de database, aangezien daar deze spullen worden opgeslagen.

WSP's oftewel solutions zijn de manier om sharepoint functionaliteit of content de deployen.
Deze worden nmelijk ook in een farm situatie gerepliceerd. Indien je met lokale bestanden op een sharepoint omgeving gaat knutselen dan kan dit in een enterprise farm omgeving behoorlijk mis gaan.

[reddog33hummer]

MikeN schreef op donderdag 19 februari 2009 @ 13:58:
Volgens mij krijg je het nooit goed zolang je in Sharepoint designer blijft klooien.

Je kan wel dit eerst goed maken, en dan met de solution generator hier features van maken.

Voor zover ik weet wordt er bij het bedrijf waar ik bij zit gewoon netjes een site definition gemaakt, waarvan je dan een wsp hebt.

Custom site definities is inderdaad een manier om sharepoint deploys uit te voeren.
een voordeel ten opzichte van features is dat deze "makkelijk" uit te rollen zijn, en gewoon als custom sites defintion aangemaakt kunnen worden.

Een paar nadelen van custom site defintions zijn dat waneer ze uitgerold zijn, ze moeilijk up te daten zijn. Wanneer je een migratie uitvoerd (WSS 2.0 naar 3.0 b.v.) je nieuwe versies paraat moet hebben (hoe zit het straks met de nieuwe versie van sharepoint ?). Je bij een restore van een backup, ook de custom site definitions moet hebben. Dat custom site definitions alleen voor nieuwe sites werken. En dat je per site maar 1 custom site defintion kan gebruiken (indien een andere leverancier dat al gedaan heeft... zit je al).

Uitrollen in productie is dan een kwestie van je wsp deployen, upgraden is een kwestie van je wsp upgraden.

Uitrollen is inderdaad deployen. Upgraden..... wil je meestal liever een retract doen vaneen solution en opnieuw deployen. Solution Upgrades die schema's bevatten willen nog wel eens ongewenst gedrag opleveren.

[reddog33hummer]

Microsofts advies voor dit probleem (meer process dan techniek)
http://msdn.microsoft.com/en-us/library/bb428899.aspx