Deploy your app to Azure App Service

0

Azure App Service maintains the application framework for you (ASP.NET, PHP, Node.js, etc). Some frameworks are enabled by default while others, like Java and Python, may need a simple checkmark configuration to enable it. In addition, you can customize your application framework, such as the PHP version or the bitness of your runtime.

Since you don’t have to worry about the web server or application framework, deploying your app to App Service is a matter of deploying your code, binaries, content files, and their respective directory structure, to the /site/wwwroot directory in Azure (or the /site/wwwroot/App_Data/Jobs/ directory for WebJobs). App Service supports three different deployment processes. All the deployment methods in this article use one of the following processes:

  • FTP or FTPS: Use your favorite FTP or FTPS enabled tool to move your files to Azure, from FileZilla to full-featured IDEs like NetBeans. This is strictly a file upload process. No additional services are provided by App Service, such as version control, file structure management, etc.
  • Kudu (Git/Mercurial or OneDrive/Dropbox): Kudu is the deployment engine in App Service. Push your code to Kudu directly from any repository. Kudu also provides added services whenever code is pushed to it, including version control, package restore, MSBuild, and web hooks for continuous deployment and other automation tasks. The Kudu deployment engine supports 3 different types of deployment sources:
    • Content sync from OneDrive and Dropbox
    • Repository-based continuous deployment with auto-sync from GitHub, Bitbucket, and Visual Studio Team Services
    • Repository-based deployment with manual sync from local Git
  • Web Deploy: Deploy code to App Service directly from your favorite Microsoft tools such as Visual Studio using the same tooling that automates deployment to IIS servers. This tool supports diff-only deployment, database creation, transforms of connection strings, etc. Web Deploy differs from Kudu in that application binaries are built before they are deployed to Azure. Similar to FTP, no additional services are provided by App Service.

Deploy manually by uploading files with FTP

If you are used to manually copying your web content to a web server, you can use an FTP utility to copy files, such as Windows Explorer or FileZilla.

The pros of copying files manually are:

  • Familiarity and minimal complexity for FTP tooling.
  • Knowing exactly where your files are going.
  • Added security with FTPS.

The cons of copying files manually are:

  • Having to know how to deploy files to the correct directories in App Service.
  • No version control for rollback when failures occur.
  • No built-in deployment history for troubleshooting deployment issues.
  • Potential long deployment times because many FTP tools don’t provide diff-only copying and simply copy all the files.

How to upload files with FTP

The Azure Portal gives you all the information you need to connect to your app’s directories using FTP or FTPS.1

Deploy by syncing with a cloud folder

A good alternative to copying files manually is syncing files and folders to App Service from a cloud storage service like OneDrive and Dropbox. Syncing with a cloud folder utilizes the Kudu process for deployment

The pros of syncing with a cloud folder are:+

  • Simplicity of deployment. Services like OneDrive and Dropbox provide desktop sync clients, so your local working directory is also your deployment directory.
  • One-click deployment.
  • All functionality in the Kudu deployment engine is available (e.g. package restore, automation).

The cons of syncing with a cloud folder are:

  • No version control for rollback when failures occur.
  • No automated deployment, manual sync is required.

How to deploy by syncing with a cloud folder

In the Azure Portal, you can designate a folder for content sync in your OneDrive or Dropbox cloud storage, work with your app code and content in that folder, and sync to App Service with the click of a button.

Deploy continuously from a cloud-based source control service

If your development team uses a cloud-based source code management (SCM) service like Visual Studio Team ServicesGitHub, or BitBucket, you can configure App Service to integrate with your repository and deploy continuously.

The pros of deploying from a cloud-based source control service are:

  • Version control to enable rollback.
  • Ability to configure continuous deployment for Git (and Mercurial where applicable) repositories.
  • Branch-specific deployment, can deploy different branches to different slots.
  • All functionality in the Kudu deployment engine is available (e.g. deployment versioning, rollback, package restore, automation).

The con of deploying from a cloud-based source control service is:

  • Some knowledge of the respective SCM service required.

How to deploy continuously from a cloud-based source control service

In the Azure Portal, you can configure continuous deployment from GitHub, Bitbucket, and Visual Studio Team Services.

Deploy from local Git

If your development team uses an on-premises local source code management (SCM) service based on Git, you can configure this as a deployment source to App Service.

Pros of deploying from local Git are:

  • Version control to enable rollback.
  • Branch-specific deployment, can deploy different branches to different slots.
  • All functionality in the Kudu deployment engine is available (e.g. deployment versioning, rollback, package restore, automation).

Cons of deploying from local Git is:

  • Some knowledge of the respective SCM system required.
  • No turn-key solutions for continuous deployment.

Deploy using an IDE

If you are already using Visual Studio with an Azure SDK, or other IDE suites like XcodeEclipse, and IntelliJ IDEA, you can deploy to Azure directly from within your IDE. This option is ideal for an individual developer.+

Visual Studio supports all three deployment processes (FTP, Git, and Web Deploy), depending on your preference, while other IDEs can deploy to App Service if they have FTP or Git integration

The pros of deploying using an IDE are:

  • Potentially minimize the tooling for your end-to-end application life-cycle. Develop, debug, track, and deploy your app to Azure all without moving outside of your IDE.

The cons of deploying using an IDE are:

  • Added complexity in tooling.
  • Still requires a source control system for a team project.

Additional pros of deploying using Visual Studio with Azure SDK are:

  • Azure SDK makes Azure resources first-class citizens in Visual Studio. Create, delete, edit, start, and stop apps, query the backend SQL database, live-debug the Azure app, and much more.
  • Live editing of code files on Azure.
  • Live debugging of apps on Azure.
  • Integrated Azure explorer.
  • Diff-only deployment.

Automate deployment by using command-line tools

If you prefer the command-line terminal as the development environment of choice, you can script deployment tasks for your App Service app using command-line tools.+

Pros of deploying by using command-line tools are:

  • Enables scripted deployment scenarios.
  • Integrate provisioning of Azure resources and code deployment.
  • Integrate Azure deployment into existing continous integration scripts.

Cons of deploying by using command-line tools are:

  • Not for GUI-preferring developers.

You might also like More from author

Leave A Reply

Your email address will not be published.