Thoughts on building SharePoint solutions as if they are clicked together that can be deployed through dev, test, acceptation and production for version 1.0 and beyond.

2. 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

3. 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?

4. 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!

5. 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

6. 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!

7. How about deployment?
• Configuring 1.0 on production is OK, but…
• 1.X should go through Dev, Test, Acceptation,
Production

8. 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

9. But how?
Is it a tool?
NO!
It is a concept, a way of working…
And PowerShell… and some tools….

10. 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

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

12. 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

13. 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 through Dev, Test,
Acceptation, Production

14. 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 (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)

15. 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,
–…

16. 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

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

18. 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.

19. 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-…

20. When to use WSP packages?
• Assemblies
– web parts
– application pages
– timer jobs
– …
• Feature receivers
• List event handlers
• Actions
• ….

21. WSP should be updateable
• SharePoint 2007:
– Uninstall, Install
– Upgrade -> nieuw features worden niet toegevoegd
• SharePoint 2010:
– Uninstall, Install
– Upgrade  faster

22. 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!!!!!!!!

23. 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."/>" />

24. 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">

25. 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

26. 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!

27. 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

28. SharePoint.DesignFactory.ContentFiles

29. 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
• Code  resulting in WSP’s
• …

30. Upgrade.ps1
• Create Fields
• Create Content Types
• Create Lists
• Install ContentFiles packages
• Delete files
• Upgrade WSP packages
• SharePoint Configurations
– Property bag
– Culture
– Features
– Page changes
– …

31. Prerequisites
• Learn PowerShell!
• PowerShell is THE automation language on the
Microsoft platform
• Good books available on PowerShell+SharePoint

32. 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

33. 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

34. 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