Thoughts on building deployable and updatable SharePoint solutions DIWUG, 19-1-2011 Serge van den Oever Macaw
About Serge van den Oever [Macaw] Macaw Microsoft specialized IT service provider 200 people and growing 13 years @ Macaw Doing SharePoint since first beta s Tahoo (SP2001) Macaw KD Knowledge Development Working on: Macaw Solutions Factory ALM MS Server products Optimizing the product development process New development, innovation, projects http://weblogs.asp.net/soever, http://twitter.com/svdoever
Agenda Thoughts on a simple approach to SharePoint development and deployment for solution versions 1.0 and beyond Thoughts on a simple toolset to support configuration and development using this approach
Audience questions (in Dutch) Wie klikt oplossing in elkaar op productie? Wie gaat door OTAP met oplossing? Wie gebruikt hiervoor WSP s? Wie doet deployment door OTAP handmatig? Wie script de deployment door OTAP?
But first a bit of history Good guys: Do everything through WSP s Build site definitions, list definitions, features Bad Guys: Configure solution in SharePoint with Web Interface and SharePoint Designer Only real coding through WSP s @Macaw: The good guys!
The old days Moss2007
The current days SPS2010
But Development is cumbersome Lot of deep SharePoint knowledge required 1.0 release is expensive Many artifacts in WSP may never change: Site definitions, list definitions, Fields, content types, Migration to new version SharePoint more difficult
So The (not so) bad guys are better of Good knowledge of SharePoint UI and tools like SharePoint Designer often enough Only minor custom developments required like: Web parts Event handlers Quick 1.0 release possible happy customer!
How about deployment? Configuring 1.0 on production is OK, but 1.X should go through OTAP
The holy SharePoint deployment grail A SharePoint deployment approach that is simple, always works, in any situation 1.0 release X.Y release In the cloud (Office 365) Continuation of ANY existing SharePoint solution
But how? Is it a tool? NO! It is a concept, a way of working And PowerShell and some tools.
But ehhh, how? Build SharePoint sites as if they are clicked together So: No site definitions, list definitions etc No features with XML for fields and content types Expensive Only work for 1.0 release Minimize usage of XML configurations Features WSP s
Advantages Fast and cheap implementation of 1.0 release Product specialist can do most work Developer for. custom development Happy customer! Easy migration to new version of SharePoint
But again how? Data (configuration) deployment from A B OTAP Authoring, Staging, Production Deployment for 1.0 release Deployment for beyond 1.0 release
1.0 release Clicked together approach: Backup/Restore Configure on SharePoint Design server Content Database backup/restore from A B Configure directly on production Script the configuration, test through OTAP
And after the 1.0 release? Get Content Database / Site Collection backup from production to dev/test/acceptation. X.Y release: always scripted Batch script PowerShell script Paper script If configuring directly on production (Office 365) New (disparate) functionality can be configured Don t provide access to new functionality yet (security)
Scripting from version X to version Y (1) (Throw away) automatic script(s) When we are on version Y, script for X Y not needed anymore Quality of script should be good enough Use old scripts for reference Build utility functions library Create field Create content type Add field to content type,
Scripting from version X to version Y (2) Paper script Write down the manual actions Combine in one deployment: paper scripts automatic scripts But are the required manual actions executed? Risk: rollback not supported Solution: validate before automatic script
Paper script validation Why? Validate is cheaper than automate Exist site, list, list item, page, Exist url Exist content type Exist field Contains content type A field B
Q: How do I see changes made? Simple answer: You don t, keep track in changes file Complexer answer: Generate a report on all changes compared to the out of the box SharePoint situation New Fields New Content Types Changed Content Types Pages Web part on pages Etc. etc.
Q: how can I rebuild my site from scratch? Script all changes Keep track of change scripts, apply again in correct order (scripts must be production code) Or: Make a reentrant single script that can be applied multiple times Ensure-Field Ensure-ContentType Ensure-
When to use WSP packages? Assemblies web parts Application pages timer jobs Feature receivers List event handlers Actions.
WSP should be updateable SharePoint 2007: Uninstall, Install Upgrade -> nieuw features worden niet toegevoegd SharePoint 2010: Uninstall, Install Upgrade faster
So SharePoint Designer is my friend? SharePoint Designer is a great tool User friendly Remote access But Actions can t be packaged It messes with my HTML!!!!!!!!
Messing Example 1: designer:preview <meta name="keywords" content="<sharepointwebcontrols:fieldvalue FieldName='Keywords' runat='server' />" /> After save&reload: <meta name="keywords" content="<sharepointwebcontrols:fieldvalue FieldName='Keywords' runat='server' designer:preview="keywords field value."/>" />
Messing example 2: head introductions <div id="home_search"> <form id="search_form" method="post" action="http://www.opensourcefood.com/process/search"> After save&reload: <div id="home_search"> <head> <meta name="webpartpageexpansion" content="full" /> </head> <form id="search_form" method="post" action="http://www.opensourcefood.com/process/search">
So SharePoint Designer is my friend? Perfect tooling for some jobs Don t edit your HTML code in it if you do advanced development like building websites with DualLayout
How about some standard tooling? Currently working on: SharePoint.DesignFactory.ContentFiles Deploy content with metadata Object Model (on server, 2007/2010) Client Object Model (remote, 2010/Office365) SharePoint.DesignFactory.PublishingPages Deploy publishing pages with metadata and web parts Object Model (on server, 2007/2010) Researching Client Object Model SharePoint.DesignFactory.Export Export content with metadata, publishing pages + web parts
SharePoint.DesignFactory.ContentFiles project Quick development cycle Install using less privileges Files + metadata Files under source control Content-only installation package Examples: Master Pages (/_catalogs/masterpage) Page Layouts (/_catalogs/masterpage) Web Parts (/_catalogs/wp) Style Library (/Style Library)
DEMO Demo of using Visual Studio for working with content files and publishing pages
Visual Studio solution for projects Acme.Portal.sln Scripts Util HandyFunctions.ps1 Version 1.3 Upgrade.cmd Upgrade.ps1 Version 1.2 PaperScript 1.2.docx Version 1.1 Branding (ContentFiles project) Content package WebPartGallery (ContentFiles project) ) Content package Pages (PublishingPages project) ) Content package Code resulting in WSP s
Upgrade.ps1 Fields Content Types Lists Install ContentFiles & PublishingPages packages Delete files Upgrade WSP packages SharePoint Configurations Property bag Culture Features Page changes
Prerequisites Learn PowerShell! PowerShell is THE automation language on the Microsoft platform Good books available on PowerShell+SharePoint
Summary A simple approach for SharePoint deployment is possible The approach is based on make solutions as if they are clicked together Simple tooling can help in supporting this approach This approach will work for both on premise and cloud solutions
But how much will it save? Faster delivery of 1.0 version Cheaper project, more competitive Happier customer Product specialist can do most 1.0 development Simpler toolset to create SharePoint sites Less XML configuration files
Questions? This sucks! Blame Microsoft! Yes! No!!@#$% Blup??? VNMC!