Office 365 – developer decisions, tricks and tips

Chris O’Brien - SharePoint MVPwww.sharepointnutsandbolts.com

About me• Independent Consultant• Head of Development, Content and Code

• Blog: www.sharepointnutsandbolts.com• Twitter: @ChrisO_Brien • LinkedIn: http://uk.linkedin.com/in/ chrisobrienmvp

Agenda

Decisions

• Test environments?• Multiple tenancies?

Tips and tricks

• Provisioning Managed Metadata and taxonomy fields• Managed properties/search schema import• Scripted deployments to Office 365• Continuous Integration

• Developer laptops?• Sandbox/sandbox

code?

How we classify SharePoint projects (with dev)

100% on-premises/no cloud aspirations

“Cloud-friendly”

“Cloud-compatible”

Discuss full-trust implications/ roadmap

Sandbox dev, maybe some server-side code

Runs 100% in Office 365

Decision – test environments

Do I need a separate test environment? What are my options?

Use different site collection(s) in production tenant – MAY BE OKUse different O365 tenant(s) - PREFERRED

Cost implicationWhat if you have multiple clients?

Tip: remember, the concept of an O365 “test tenancy” doesn’t really exist (e.g. to Microsoft). Expect puzzled looks

YES!

Decision – test environments

Our decision:We run DEV and TEST tenancies for each client:

Client 1

Dev

Client 2

Dev Test

Tip: decide which O365 plan level/how many users, and then present forecast costs to the business

Decision – test environments

Plan levels - our decision:DEV = SharePoint P2 (SharePoint only)TEST = to match production e.g. Office 365 E3 (Exchange, Lync, SharePoint)

Client 1

Dev (P2)

Client 2

Dev (P2) Test (E3)

Multiple tenancies gotcha

Sync from AD can only work with ONE tenant!This will be the production environment

So, users will have different identities (and usernames/passwords) in different tenancies

Microsoft may improve this later?

Interesting fact!

Number of O365 tenancies as of Sept 27th 2013:

528,728

Decision - dev environment

Do I still need an on-premises SP2013 dev environment?

YES!If doing any development (rather than customisation), sometimes you’ll want to see ULS logs (no access in Office 365)

Our decision:Each developer has fully-featured SP2013 VMEach developer switches between deploying to O365/local VM as they need

Dev site collection structure

Site collection per developer, plus shared

Disposable, flexible

Decision – should you use (server-side) code in the sandbox?

Microsoft: “The sandbox is deprecated!” – November 2012 (MSDN)“SharePoint Sandbox isn't Dead...UserCode is” – August 2013 (Richard DiZerega)

Server-side code could be:Feature receiversEvent receiversWeb part code-behindCustom controls

Decision – should you use code in sandbox?

JavaScript code

(JSOM/REST)

Remote Event

Receivers

PowerShell + CSOM

Our decision:

Alternatives to server-side sandbox code:

NO - AVOID WHERE POSSIBLE(but sandbox WSP with just XML is OK)

Consider – sandbox timeout

Server-side code:

30 seconds..

Not very well documented!

Provisioning taxonomy (and taxonomy fields) in O365

Decision – content type strategy

Pre-requisite to deciding approach to taxonomy fields

What are my options?Use Content Type Hub – MAY BE OKUse “provisioned” content types (with a tweak) – OUR CHOICE

Tip: remember, the CTH trade-offs still apply in O365:• Have to wait for timer job for content types in

new sites• Any local changes (e.g. new field) get

“clobbered”

Taxonomy – provisioning challenges in O365

CHALLENGE: Devs cannot use SP2010 techniques to bind fields (Feature receiver code)CHALLENGE: Each Term Set gets a new ID when created – different in each environment!CHALLENGE: Term Store ID is different in each environment

IMPACT: Taxonomy fields need to be “bound” manually – each field -> on each list/library -> in each site

NOT PRACTICAL!

Taxonomy – our solution for multiple tenancies

TIP: If Term Set is provisioned by API, can control IDs

We use PowerShell + CSOM Reads values from XML file

Static, known IDs = can be used in field definitions

Taxonomy – “ingredients” for provisioning1. Term sets with known IDs 2. Fields with full MM

definition

demo

Provisioning taxonomy (and taxonomy fields) in O365

Demo screenshots (MM fields - 1 of 3)

We create Term Sets from PS/CSOM script + XML file:

Demo screenshots (MM fields - 2 of 3)

Benefit is that Term Sets are created with known GUIDs

Terms themselves can be added through UI – this is fine

Demo screenshots (MM fields - 3 of 3)

Now we can use 100% declarative provisioning for taxonomy fields

NOTE: See http://cob-sp.com/1gvh5Hy for more info on this..

Working with search (and Managed Properties)

Managed Properties - recap

Used by search e.g:Content Search web partSearch queriesRefiners

Example:Title (Managed Prop):

Page title (Column)Job title (Column)Project title (Column)

Managed Properties - creating

CHALLENGE: Devs cannot use SP2010 techniques to provision (on-premises PowerShell)SOLUTION: Use new “import/export search schema XML” capabilitiesCreates:

Crawled PropertiesManaged PropertiesMappingsAliases

No need to wait for a crawl!

Copying search schema between environments

Search schema optionsTenant-level (SPSiteSubscription) – O365 onlySite collection (SPSite)Web (SPWeb)

Has API – can be automated:SearchConfigurationPortability.ExportSearchConfiguration()SearchConfigurationPortability.ImportSearchConfiguration()

demo

Working with search schema

Demo screenshots (search schema - 1 of 3)

Can use SPO tenant admin to import XML:

Managed props etc. can be created in tenant admin UI:

Two UI-based approaches:

OR:

Demo screenshots (search schema - 2 of 3)XML import/export also available in CSOM API – can be automated:

Demo screenshots (search schema - 3 of 3)

Result is that any crawled props/managed props in XML are created:

Automated deployments in Office 365

Automation – why?

Repeatable deployments – less human error

Improved team development

Deployable by client

Possibility of “switch” for O365/on-premises

Gateway to Continuous Integration/automated testing

PowerShell in Office 365

Poweshell cmdlets0

100

200

300

400

500

600

700

800

900PS cmdlets

On-premises SharePoint Online

PowerShell cmdlets:

On-premises SharePoint Online

774 30

New techniques

PowerShell+

CSOM

Are your friends

PowerShell + CSOM

Importing/exporting taxonomy terms

Importing/exporting search schema

Recreating site collections

Sandbox solution deployment – no API for this!

Activating web templates

Create publishing pages

Uploading files

Automated deployments in Office 365

Demo screenshots (automated deploy)

1. Delete existing site collection2. Import taxonomy from XML (to

Term Store)3. Import search schema (for

Managed Properties etc.)4. Create new site collection5. Upload WSPs to sandbox

Solution Gallery6. Activate Features7. Apply WebTemplate to site8. Create site structure/upload

test content

Showed PS/CSOM script - 100% automated deploy to O365:

Continuous Integration for Office 365 dev

PS/CSOM is called by TFS build (nightly build to Office 365):

Continuous Integration for Office 365 dev

Custom VS configuration – ensures WSPs are built for

correct tenancy (for taxonomy fields)

Continuous Integration for Office 365 dev

Ta-da!

Summary

Office 365 is less limiting than you thinkAnd you don’t need to sacrifice engineering practices..Get comfortable with apps and client-side techniques

Key techniques:Provisioning Managed Metadata/fieldsImporting search schemaPS + CSOM deployment scripts

Incl. automated WSP deployment

Miscellaneous tips/links

Codeplex library for sandbox WSP deployment to O365:

http://spohelper.codeplex.com

Azure is the new _layouts directoryhttp://cob-sp.com/11R1Y4K

Luis Mañez blog:http://geeks.ms/blogs/lmanez/

THANK YOU!

Questions?

www.sharepointnutsandbolts.com

@ChrisO_Brien