Deploying a SharePoint App to Azure As Part of a Build

This post will show how to use continuous integration with a SharePoint provider-hosted app deployed to an Azure web site.

Background

I’ve written on the topic of SharePoint apps and ALM before, but I couldn’t get the whole thing to work with Azure web sites, just my own IIS server.  I decided it was too much work to figure out how to make the available scripts work with Azure web sites.  This weekend, while I was writing the blog post Deploying an Azure Web Site Using Git and Continuous Integration, and I noticed a suspicious little setting in the build definition.

I was thinking, “no way did they fix this.”  Well, they did!

Create a Team Project in Visual Studio Online

A few readers have asked why Visual Studio Online, why not your own TFS?  Honestly, I love Visual Studio Online.  I cannot picture a day where I go through the pain of setting up TFS ever again, I’ll just use the cloud.   

Once you’re done creating the project, click Close.

Create an Azure Web Site

In the previous post, I changed the web site to standard so that we could use staged publishing.  I’m not doing that here for simplicity, let’s just create an Azure web site using the custom create option.  That will give us the little checkbox to publish from source control.

We checked the checkbox, now Azure wants to know where to get the source from.  Visual Studio Online, of course!

We then authorize the connection.

We say accept…

and finally choose a repository to deploy from. 

Once the web site is created, click the Visual Studio icon at the bottom of the screen.

We are then asked if we want to allow the website to open Visual Studio.  Yep, we do.

Create Some Code and Commit

Now that we have a web site and a remote repository, clicking the Visual Studio button above will open Visual Studio.  We are asked to clone the repository to get started.

I clone the repository, providing a path to a folder that does not have a .git subdirectory already.

Once the repository is cloned, I then create a solution using the “New…” link under solutions on the Team Explorer pane.

We will create an App for SharePoint 2013 called MySPAppDemo.  Make sure to leave that checkbox for “Add to source control” checked, we’re going to need that.

We then provide a URL for debugging, and click Finish. 

We make sure it is a provider-hosted app, then accept all defaults, which creates an ASP.NET MVC site using Office 365.

The Client ID and Client Secret

Remember that SharePoint apps require a client ID and client secret when being published to SharePoint Online.  If you didn’t provide those, here is the error that you can expect in your build.

Exception Message: The application identifier is invalid, it must be a valid GUID. (type ServerException)
Exception Stack Trace:    at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
    at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
    at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Ask me how I know.  I lost at least an hour on this one.  I finally realized, “duh… of course, I never told it how to authorize.”

Fixing this is simple, just go to your SharePoint site, appending _layouts/15/appregnew.aspx, to generate the client ID and client secret.

Go to Visual Studio and download the publish profile for the web site.  The file should go to your Downloads folder.

Here is an IMPORTANT STEP, do not miss this or your app won’t work.   Without this step the app package redirects you to an HTTP URL instead of HTTPS, and the app won’t work.

Open the .publishsettings file in your downloads folder that you just saved and edit it.  We need to change the URL to use HTTPS instead of HTTP.

Save your changes.

Right-click your app project and choose Publish…

You are asked for a current profile, but you don’t have one yet.  Create a new one.

Import the publishing profile that you just downloaded.

You can now see the Publish your app wizard. 

Click the “Deploy your web project” button, and your web site will be deployed to Azure after your provide the client ID and client secret for your app.

Next, click the button to “Package the app”.  Remember to change the URL to use SSL, otherwise SharePoint apps won’t work.  Since we edited the publishsettings for the site, this should default to HTTPS now.

This step is still required, now let’s talk about a gap in the process template.

If you read my previous article, ALM for SharePoint Apps – Understanding Provider Hosted App Publishing, you would know that the previous method we used to deploy simply used the publish profile.  However, in this model the publish profile is only used to generate the app package, its settings are not applied to the web.config for our Azure web site.  How do we then handle this? 

One way would be to just enter the settings into web.config and commit to source control.  Another way is to simply go to the Azure web site and apply your ClientId and ClientSecret values in the appSettings, which will override whatever value is in your web.config file.  I greatly prefer this model because it lets me control it later via the Management Portal.

Once you enter the values, make sure to your work!

Make a Commitment

Commit your changes to the local repository by right-clicking the solution node in Solution Explorer and choosing Commit.  Provide a check-in comment.

You can see that I committed with the incredibly useful check-in comment “asdf”.  Don’t judge me.

Once you’ve committed to the local repo, sync your changes to Visual Studio Online.

Once you have synchronized your commits to Visual Studio Online, you can edit the build definition that was created for you.  Click the ellipses in the “SharePoint Deployment Environment” parameter to bring up the dialog to enter information about your environment. 

Once you’ve edited the build definition and saved it, you can test the process by manually queuing a build.  Just right-click the build definition and choose “Queue new build”.

On the next dialog, choose queue, leaving the defaults, and then be patient.  You can monitor details by double-clicking on the running build and then choosing View Details.

Continuous Integration

Here’s the part that got me pretty excited… you don’t have to do anything for continuous integration to work, it’s all there as part of the process template.  Make a change to your code, commit, and then sync to the remote repository.  Now, go look at your Builds tab.  A build is already running because of your last commit.

You can see that the app is being installed.

Once the build completes, you will see the Deployment Summary.

Click the Trust URL and you will be taken to a page to trust the app.

Click Trust It.  Now, click the link to open your app.

BOOYAH!  That’s an app running on an Azure web site, deployed using continuous integration.

The Big Payoff

Not seeing why this is so cool yet?  OK, let me explain.  No, it’s too much, lemme sum up.

Make a change to your source code.  We’ll edit the index.cshtml view.

Commit your changes, and then sync to Visual Studio Online.

Wait for the build to complete.  Next, trust the app again, then open it. 

Take it a step further by configuring your web site for staged publishing and using continuous integration against the staging site, then when you’re ready you simply swap the staging and production sites using the Azure Management Portal.

You can read more about that approach in my post Deploying an Azure Web Site Using Git and Continuous Integration.

For More Information

Publishing apps for Office and SharePoint to Windows Azure Websites

Deploying an Azure Web Site Using Git and Continuous Integration