Thoughts on building deployable and updatable SharePoint solutions

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 After save&reload:

Messing example 2: head introductions