Thoughts on building deployable and updatable share point solutions
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• Who clicks together its solution on production using the Web UI and SharePoint Designer?• Who goes through dev, test, acceptation, production with its SharePoint solution?• Who uses WSP’s to do this?• Who does deployments through dev, test, acceptation, production manually?• Who scripts its deployments?
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!
But…• Development is cumbersome• Lot of deep SharePoint knowledge required• 1.0 release is expensiveMany 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 Dev, Test, Acceptation, Production
The holy SharePoint deployment grailA 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 – Dev, Test, Acceptation, Production – Authoring, Staging, Production• Deployment for 1.0 release• Deployment for beyond 1.0 release
1.0 releaseClicked together approach:• Backup/Restore – Configure on SharePoint Design server – Content Database backup/restore from A B• Configure directly on production• Script the configuration through Dev, Test, Acceptation, Production
And after the 1.0 release?Get Content Database / Site Collection backup fromproduction to dev/test/acceptation.X.Y release: always scripted• Batch script• PowerShell script• Paper script (write down manual configuration instructions)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 actionsCombine in one deployment:• paper scripts• automatic scriptsBut… are the required manual actions executed?Risk: rollback not supportedSolution: validate before automatic script
Paper script validationWhy? 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 fileComplexer 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 (in thia case 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:FieldValueFieldName=Keywords runat=server />" />After save&reload:<meta name="keywords"content="<SharePointWebControls:FieldValueFieldName=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 again 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?• SharePoint.DesignFactory.ContentFiles – Deploy content with metadata • Uses Object Model (on server, 2007/2010) • Uses Client Object Model (remote, 2010/Office365) Now available as NuGet package!
SharePoint.DesignFactory.ContentFiles• Use any editor to edit your SharePoint artifacts• Great integration in Visual Studio with right-click actions in Solution Explorer• Available as NuGet package• Super quick development cycle for any SharePoint artifact that can be uploaded to SharePoint. No WSP’s required.• Deploy using less privileges. Only upload rights required.• Upload files + metadata, for example master pages, page layouts, style library, web parts etc.• Keep files under source control• Develop on non-SharePoint machines• Create content-only installation package
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
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