Continuous deployment for Azure Functions

You can use Azure Functions to deploy your code continuously by using source control integration. Source control integration enables a workflow in which a code update triggers build, packaging, and deployment from your project to Azure.

Continuous deployment is a good option for projects where you integrate multiple and frequent contributions. When you use continuous deployment, you maintain a single source of truth for your code, which allows teams to easily collaborate.

Steps in this article show you how to configure continuous code deployments to your function app in Azure by using the Deployment Center in the Azure portal. You can also configure continuous integration using the Azure CLI.

Functions supports these sources for continuous deployment to your app:

Azure Repos

Maintain your project code in Azure Repos, one of the services in Azure DevOps. Supports both Git and Team Foundation Version Control. Used with the Azure Pipelines build provider). For more information, see What is Azure Repos?

GitHub

Maintain your project code in GitHub. Supported by all build providers. For more information, see GitHub docs.

GitHub is the only continuous deployment source supported for apps running on Linux in a Consumption plan, which includes serverless Python apps.

Bitbucket

Maintain your project code in Bitbucket. Requires the App Service build provider.

Local Git

Maintain your project code in a dedicated Git server hosted in the same App Service plan with your function app. Requires the App Service build provider. For more information, see Local Git deployment to Azure App Service.

You can also connect your function app to an external Git repository, but this requires a manual synchronization. For more information about deployment options, see Deployment technologies in Azure Functions.

Note

Continuous deployment options covered in this article are specific to code-only deployments. For containerized function app deployments, see Enable continuous deployment of containers to Azure.

Requirements

For continuous deployment to succeed, your directory structure must be compatible with the basic folder structure that Azure Functions expects.

The code for all the functions in a specific function app is located in a root project folder that contains a host configuration file. The host.json file contains runtime-specific configurations and is in the root folder of the function app. A bin folder contains packages and other library files that the function app requires. Specific folder structures required by the function app depend on language:

• C#
• Java
• JavaScript
• TypeScript
• PowerShell
• Python

All functions in the function app must share the same language stack.

Build providers

Building your code project is part of the deployment process. The specific build process depends on your specific language stack, operating system, and hosting plan. Builds can be done locally or remotely, again depending on your specific hosting. For more information, see Remote build.

Functions supports these build providers:

Azure Pipelines

Azure Pipelines is one of the services in Azure DevOps and the default build provider for Azure Repos projects. You can also use Pipelines to build projects from GitHub. In Pipelines, there's an AzureFunctionApp task designed specifically for deploying to Azure Functions. This task provides you with control over how the project gets built, packaged, and deployed.

GitHub Actions

GitHub Actions is the default build provider for GitHub projects. GitHub Actions provides you with control over how the project gets built, packaged, and deployed.

App Service (Kudu) service

The App Service platform maintains a native deployment service (Project Kudu) to support local Git deployment, some container deployments, and other deployment sources not supported by either Pipelines or GitHub Actions. Remote builds, packaging, and other maintainence tasks are performed in a subdomain of scm.azurewebsites.net dedicated to your app, such as https://myfunctionapp.scm.azurewebsites.net. This build service can only be used when the scm site can be accessed by your deployment. Many publishing tools require basic authentication to connect to the scm endpoint. For more information, see Enable basic authentication for deployments.

This build provider is used when you deploy your code project by using Visual Studio, Visual Studio Code, or Azure Functions Core Tools. If you haven't already deployed by using one of these tools, you might need to Enable basic authentication on the SCM endpoint.

Your options for which of these build providers you can use depend on the specific code deployment source.

Deployment center

The Azure portal provides a Deployment center for your function apps, which makes it easier to configure continuous deployment. The way that you configure continuous deployment depends both on the specific source control in which your code resides and the build provider you choose.

In the Azure portal, browse to your function app page and select Deployment Center under Deployment in the left pane.

Select the Source repository type where your project code is being maintained from one of these supported options:

Azure Repos

Deployments from Azure Repos that use Azure Pipelines are defined in the Azure DevOps portal and not from your function app. For a step-by-step guide for creating a Pipelines-based deployment from Azure Repos, see Continuous delivery with Azure Pipelines.

GitHub

Deployments from GitHub that use Azure Pipelines are defined in the Azure DevOps portal and not from your function app. For a step-by-step guide for creating a Pipelines-based deployment from GitHub, see Continuous delivery with Azure Pipelines.

Bitbucket

You can't deploy from Bitbucket using Azure Pipelines. Instead choose the App Service build provider.

Local Git

You can't deploy from local git using Azure Pipelines. Instead choose the App Service build provider.

Azure Repos

You can't deploy from Azure Repos using GitHub Actions. Choose a different build provider.

GitHub

To add a GitHub Actions workflow to an existing function app:

1. Navigate to your function app in the Azure portal and select Deployment Center.

2. For Source select GitHub. If you don't see the default message Building with GitHub Actions, select Change provider choose GitHub Actions and select OK.

3. If you haven't already authorized GitHub access, select Authorize. Provide your GitHub credentials and select Sign in. To authorize a different GitHub account, select Change Account and sign in with another account.

4. Select your GitHub Organization, Repository, and Branch. To deploy with GitHub Actions, you must have write access to this repository.

5. In Authentication settings, choose whether to have GitHub Actions authenticate with a User-assigned identity or using Basic authentication credentials. For basic authentication, the current credentials are used.

6. Select Preview file to see the workflow file that gets added to your GitHub repository in github/workflows/.

7. Select Save to add the workflow file to your repository.

To learn more about GitHub Action deployments, including other ways to generate the workflow configuration file, see Continuous delivery by using GitHub Actions.

Bitbucket

You can't deploy from Bitbucket using GitHub Actions. Instead choose the App Service build provider.

Local Git

You can't deploy from local git using GitHub Actions. Instead choose the App Service build provider.

Azure Repos

1. Navigate to your function app in the Azure portal and select Deployment Center.

2. For Source select Azure Repos. If App Service build service provider isn't the default, select Change provider choose App Service build service and select OK.

3. Select values for Organization, Project, Repository, and Branch. Only organizations that belong to your Azure account are displayed.

4. Select Save to create the webhook in your repository.

GitHub

1. Navigate to your function app in the Azure portal and select Deployment Center.

2. For Source select GitHub. If App Service build service provider isn't the default, select Change provider choose App Service build service and select OK.

3. If you haven't already authorized GitHub access, select Authorize. Provide your GitHub credentials and select Sign in. If you need to authorize a different GitHub account, select Change Account and sign in with another account.

4. Select values for Organization, Repository, and Branch. The values are based on the location of your code.

5. Review all details and select Save. A webhook is placed in your chosen repository.

When a new commit is pushed to the selected branch, the service pulls your code, builds your application, and deploys it to your function app.

Bitbucket

1. Navigate to your function app in the Azure portal and select Deployment Center.

2. For Source select Bitbucket.

3. If you haven't already authorized Bitbucket access, select Authorize and then Grant access. If requested, provide your Bitbucket credentials and select Sign in. If you need to authorize a different Bitbucket account, select Change Account and sign in with another account.

4. Select values for Organization, Repository, and Branch. The values are based on the location of your code.

5. Review all details and select Save. A webhook is placed in your chosen repository.

When a new commit is pushed to the selected branch, the service pulls your code, builds your application, and deploys it to your function app.

Local Git

1. Navigate to your function app in the Azure portal and select Deployment Center.

2. For Source select Local Git and select Save.

3. A local repository is created in your existing App Service plan, which is accessed from the scm domain. Copy the Git clone URI and use it to create a clone of this new repository on your local computer.

When a new commit is pushed to the local git repository, the service pulls your code, builds your application, and deploys it to your function app.

After deployment completes, all code from the specified source is deployed to your app. At that point, changes in the deployment source trigger a deployment of those changes to your function app in Azure.

Considerations

You should keep these considerations in mind when planning for a continuous deployment strategy:

• GitHub is the only source that currently supports continuous deployment for Linux apps running on a Consumption plan, which is a popular hosting option for Python apps.

• The unit of deployment for functions in Azure is the function app. All functions in a function app are deployed at the same time and in the same package.

• After you enable continuous deployment, access to function code in the Azure portal is configured as read-only because the source of truth is known to reside elsewhere.

• You should always configure continuous deployment for a staging slot and not for the production slot. When you use the production slot, code updates are pushed directly to production without being verified in Azure. Instead, enable continuous deployment to a staging slot, verify updates in the staging slot, and after everything runs correctly you can swap the staging slot code into production.

• The Deployment Center doesn't support enabling continuous deployment for a function app with inbound network restrictions. You need instead configure the build provider workflow directly in GitHub or Azure Pipelines. These workflows also require you to use a virtual machine in the same virtual network as the function app as either a self-hosted agent (Pipelines) or a self-hosted runner (GitHub).

Continuous deployment during app creation

Currently, you can configure continuous deployment from GitHub using GitHub Actions when you create your function app in the Azure portal. You can do this on the Deployment tab in the Create Function App page.

If you want to use a different deployment source or build provider for continuous integration, first create your function app and then return to the portal and set up continuous integration in the Deployment Center.

Enable basic authentication for deployments

By default, your function app is created with basic authentication access to the scm endpoint disabled. This blocks publishing by all methods that can't use managed identities to access the scm endpoint. The publishing impacts of having the scm endpoint disabled are detailed in Deployment without basic authentication.

Important

When you use basic authenication, credentials are sent in clear text. To protect these credentials, you must only access the scm endpoint over an encrypted connection ( HTTPS) when using basic authentication. For more information, see Secure deployment.

To enable basic authentication to the scm endpoint:

Azure portal

1. In the Azure portal, navigate to your function app.

2. In the app's left menu, select Configuration > General settings.

3. Set SCM Basic Auth Publishing Credentials to On, then select Save.

Azure CLI

You can use the Azure CLI to turn on basic authentication by using this az resource update command to update the resource that controls the scm endpoint.

az resource update --resource-group <RESOURCE_GROUP> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<APP_NAME> --set properties.allow=true

In this command, replace the placeholders with your resource group name and app name.

Next steps

Best practices for Azure Functions