Thoughts on building deployable and updatable SharePoint solutions. DIWUG, Serge van den Oever Macaw

(1)

Thoughts on building deployable

and updatable SharePoint solutions

DIWUG, 19-1-2011 Serge van den Oever

(2)

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,

(3)

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

(4)

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?

(5)

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!

(6)

(7)

(8)

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, …

• …

(9)

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

(10)

How about deployment?

• _{Configuring 1.0 on production is OK, but…}

(11)

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)

(12)

But how?

Is it a tool? NO!

It is a concept, a way of working…

(13)

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

(14)

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

(15)

But again… how?

• Data (configuration) deployment from A  B

– OTAP

– Authoring, Staging, Production

• _{Deployment for 1.0 release}

(16)

1.0 release

Clicked together approach:

• Backup/Restore

– Configure on SharePoint Design server

– Content Database backup/restore from A  B

• _{Configure directly on production}

(17)

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

(18)

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,

(19)

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

(20)

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

(21)

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

(22)

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

(23)

When to use WSP packages?

• Assemblies – web parts – _{Application pages} – timer jobs – _… • Feature receivers

• List event handlers

• Actions

(24)

WSP should be updateable

• _{SharePoint 2007:}

– Uninstall, Install

– Upgrade -> nieuw features worden niet toegevoegd

• _{SharePoint 2010:}

– Uninstall, Install

(25)

So SharePoint Designer is my friend?

• _{SharePoint Designer is a great tool}

– User friendly

– Remote access

• _But…

– Actions can’t be “packaged”

(26)

Messing Example 1: __designer:Preview

(27)

Messing example 2: head introductions

<form id="search_form" method="post"

action="http://www.opensourcefood.com/process/search"> After save&reload:

<head>

<meta name="WebPartPageExpansion" content="full" /> </head>

<form id="search_form" method="post"

(28)

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

(29)

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

(30)

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) • …

(31)

DEMO

• _{Demo of using Visual Studio for working with}

(32)

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 • …

(33)

Upgrade.ps1

• Fields

• _{Content Types} • Lists

• Install ContentFiles & PublishingPages packages • _{Delete files} • Upgrade WSP packages • SharePoint Configurations – Property bag – Culture – Features – Page changes – …

(34)

Prerequisites

• _{Learn PowerShell!}

• _{PowerShell is}_THE_{automation language on the}

Microsoft platform

(35)

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”}

(36)

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}

(37)

Questions?

This sucks! Blame Microsoft!

Yes! _No! _!@#$% VNMC! ???