Application Lifecycle Management for SharePoint and Office 365 appsChris O’Brien - MVP

About me

Independent ConsultantHead of Development, Content and Code (UK)

www.sharepointnutsandbolts.com@ChrisO_Brien http://cob-sp.com/COBLinkedIn

What do we mean by ALM?ALM focuses on:

• Efficient team development, with quality outputs• Planning for application upgrades• Predictable deployments

Things like:

• Continuous Integration/Continuous Deployment• Packages not built on dev machines• Code quality checks• Structured deployment process

Remembering – SharePoint, ALM, and painNeeded:On-premises TFS serverOn-premises SharePoint VM to deploy toCustomisation of build processPowerShell remotingLots of custom PS scripts

http://sharepointci.codeplex.com

AAARGH!

Good news!

ALM for ASP.NET apps is MUCH easier

Flavours of app development

Worth considering Azure for ALM in dev phase, even if not real target

TypeOffice 365 appSharePoint Add-In/Office Add-In

HostingAzureOther cloudOn-prem IIS servers

Continuous Deployment with Azure and Visual Studio Online

Developer checks-in

Build runs on hosted build

controller

Output automatically

deployed to Azure Web App

DemoAutomated builds for apps (using Azure)

Summary – CD with Azure and VS OnlineConfigure project for Office 365 integrationApp registered in Azure AD

Add solution to source control Create Azure Web App, select “publish from source control”

DONE!

Managing Azure – old portal vs. newSome features not yet in both

In spring 2015, use:OLD – for Azure Active DirectoryNEW – for Azure Web App Deployment Slots

Managing dev/test/prod for apps in Azure

Using multiple Office 365 tenancies? Apps in Azure have some considerations! ** Specifically Office 365 apps i.e.

- Apps which use the Office 365 APIs- Apps which use Azure AD auth (for

SSO)

The issueOffice 365 apps need to be registered in the “correct” Azure AD (tied to O365 tenancy)

So, app needs to be registered/deployed to EACH Azure subscription behind your tenancies

Dev/test/UAT/prod for apps in Azure – issueBUT: often, “test” Office 365 tenancies do not have: Domain integration (e.g. MyCompany.com, not

onmicrosoft.com) ..and therefore Single Sign-On (SSO) with O365 Full directory of real users AAD Sync Yammer Enterprise Production license type (e.g. E3/E4) Etc.

The answer?

Azure Deployment Slots!

Azure Web Apps - deployment slotsDefine additional “instances” of an Azure Web App (site)

Allow you to test purely in production Office 365 environment, BUT with dev/test/prod separation for apps (Azure sites)

Azure Web Apps - deployment slotsEach site gets:

Different URL – with slot name

Own app settings Own connection strings Own SCM site

http://mysite.azurewebsites.net

http://mysite-dev.azurewebsites.nethttp://mysite-test.azurewebsites.net

In Azure portal:

PowerShell:

“Swapping” deployment slotsSlots can be swapped to deploy updatesActually a DNS update, not copy of content

Process:Publish updates to dev/test slotsSwap test/production when ready

Switch-AzureWebsiteSlot –Name ‘COB website’ -Slot1 'Production' -Slot2 <slotName>

DemoUsing Azure deployment slots for dev/test/production

Summary – using deployment slots for appsCreate additional deployment slotsRegister separate instance of app in Azure AD:

https://msdn.microsoft.com/en-us/office/office365/howto/add-common-consent-manually

Configure “slot-specific” ClientID and PasswordDeploy app to slot

DONE!

Update process using slots1. Continuous build deploys to DEV slot2. When ready, swap DEV and TEST

1. ..once testing is complete (and no rollback needed), then manually publish same build to DEV slot

2. ..now DEV and TEST are the same, but PROD is not

3. When ready, swap TEST and PROD1. ..once testing is complete (and no rollback needed), then swap DEV and TEST, and

manually publish same build to DEV slot2. ..now updates in PROD, and all slots are the same..

More Azure coolness – “Testing in production”Traffic Routing - send some traffic to another slot

Uses:Testing new functionality on small number of usersA/B testing

SharePoint Add-Ins

OK, but what about SharePoint Add-Ins?Very easy to deploy/test against Office 365Very similar to Office 365 apps (especially provider-hosted), but:App registered with AppRegNew.aspxSpecify Office 365 tenant to test against (in build settings):

OK, but what about SharePoint Add-Ins?Trusting the app:Link provided in build report

OR, use web test to “click the link”

DemoContinuous Deployment for SharePoint Add-Ins

Summary – CD for SharePoint Add-InsSame as for O365 app:Create Azure site, link to source control

SharePoint app specific:Use AppRegNew.aspx to register appDownload/edit publish profile – specify ClientID/Client SecretEdit build definition, specify:

Office 365 tenant to deploy toPath to publish profile (for app packaging)Azure site to deploy to

http://blogs.msdn.com/b/kaevans/archive/2014/04/02/deploying-a-sharepoint-app-to-azure-as-part-of-a-build.aspx

Other variants1. Can’t use Visual Studio Online?Several options supportedSelect source in Azure Web App config

Other variants2. Need to use an on-prem TFS build server?Use scripts at http://officesharepointci.codeplex.com

Integrating quality checksTest the applicationRecord Coded UI Tests (requires on-prem build controller)Write unit tests

Check code qualityIntegrate SPCAF (for SharePoint apps or WSPs)http://docs.spcaf.com/v5/SPCAF_OVERVIEW_660_HOWTORUNSPCAFINTEAMBUILD.html

Common errors/pitfallsInvalid credentials in O365 deployment site (build config)

App previously deployed not by build

Some ALM go-to guys

Kirk Evans (Microsoft) http://blogs.msdn.com/b/kaevans

Matthias Einig (SPCAF) http://www.matthiaseinig.de

Jeremy Thake (Microsoft) http://www.jeremythake.com

SummaryNever done automated builds before? Well, NOW is the time!

App development models mean SharePoint complexities are removed

Visual Studio Online can provide build mechanism

Azure can provide the deployment and hosting mechanism

© 2015 Microsoft Corporation. All rights reserved.