The options available for deploying apps depend on your deployment scenario and application type. There are three main application types and each one requires a different deployment scenario. Table 7-1 summarizes these various scenarios.
APP TYPE | APP CODE DEPLOYED TO | APP PACKAGE DEPLOYED TO |
SharePoint-hosted | N/A | App catalog or Marketplace |
Provider-hosted | Azure or other | App catalog or Marketplace |
Autohosted | Azure | App catalog or Marketplace |
SharePoint-hosted apps are a bit simpler than the others given that there isn’t any Web deploy package to have deployed, and because they generally consist of HTML pages and JavaScript only. SharePoint-hosted apps don’t have any other dependencies on a runtime environment for this reason.
Provider-hosted apps are a bit more complex and consist of just an app package without any Web deploy package in it. This is because the provider of the app is already required to be hosting it either in Azure or some other Internet-accessible location. The provider of the app manages running the code for the app and any associated databases or dependent resources.
Autohosted app packages are the only ones that contain Web deploy packages and/or database packages. This is because Autohosted apps are the only app types where SharePoint needs to take both the Web deploy package and database package and deploy them to Azure when the app is installed. Azure is currently the only option for autodeployment in the Autohosted scenario.
SharePoint-hosted apps are the simplest of the three app types to package and deploy because of the lack of a code package and associated deployment steps. All that is required is to package the application using the Publish wizard in Visual Studio and then deploy the app to either the Marketplace or an app catalog. After the app is deployed, users can install the app on their site. When this occurs, SharePoint takes the app package, creates a new app Web for that instance of the application, and provisions the pages and content from the app package into it. Any custom UI actions and App Parts are also deployed to the host Web.
Try your hand at deploying a SharePoint-hosted app in the next exercise to learn how straightforward the process is.
Provider-hosted applications are the most complex of the three app types because hosting and running the application code is up to the developer, rather than allowing SharePoint and Azure do these things for you. However, with the increased complexity comes increased flexibility, because you manage your application’s back end. This means that making fixes or updates to it is straightforward, and the ultimate user for the application might never know or care to know about the changes being made to the application. Only if you make changes to the components of your app that reside within the SharePoint site itself would you need to issue an update to the application package in the app catalog or Marketplace. However, you should consider that you might need to deal with multi-tenancy issues, such as tenant specific–data partitioning, given that an app may be installed on multiple sites.
Deploying a Provider-hosted application happens in two main stages:
The application backend can theoretically be any technology and is not limited to Internet Information Server. The only stipulation is that the SharePoint farm or SharePoint Online must be able to communicate with it over HTTP (port 80) and HTTPS (port 443).
For on-premises applications, Provider-hosted applications are the only choice when back-end code is involved. This requires setting up server-to-server authentication (see Chapter 10).
Now try out deploying a Provider-hosted application in the following exercise using SharePoint Online and Windows Azure.
Autohosted application deployment is almost as straightforward as SharePoint-hosted application deployment. This is because SharePoint Online takes care of all the heavy lifting deploying the code and database packages to Azure for you as well as creating and managing client IDs and secrets.
In the following exercise you will give creating a simple Autohosted app a go and deploy it into SharePoint Online using a private app catalog.