Kirk Evans Blog

.NET From a Markup Perspective

Deploying a SharePoint App to Azure As Part of a Build

Deploying a SharePoint App to Azure As Part of a Build

Rate This
  • Comments 3

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.

image

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.   

image

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.

image

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

image

We then authorize the connection.

image

We say accept…

image

and finally choose a repository to deploy from. 

image

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

image

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

image

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.

image

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

image

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

image

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.

image

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

image

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

image

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)

image

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.

image

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

image

Here is an IMPORTANT STEP, do not miss this or your app won’t workWithout 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.

image

Save your changes.

Right-click your app project and choose Publish…

image

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

image

Import the publishing profile that you just downloaded.

image

You can now see the Publish your app wizard. 

image

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.

image

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.

image

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.

image

Once you enter the values, make sure to image 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.

image

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

image

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

image

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. 

image

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

image

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.

image

image

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.

image

You can see that the app is being installed.

image

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

image

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

image

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.

image

The Big Payoff

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

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

image

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

image

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

image

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.

image

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

  • That is a creative way of doing it. Thank's for the post. Keep it up!

  • Nice one Kirk, thanks!

    I showed it in my session about CI/CD at the European SharePoint Conference in Barcelona this week. The folks were baffled how easy it is to set up :)

    Slides can be found at www.matthiaseinig.de/.../sessions-and-slides-from-the-espc14

  • That's awesome, Matthias!  

Page 1 of 1 (3 items)
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives