| title | description | ms.assetid | ms.topic | ms.date |
|---|---|---|---|---|
Continuous deployment for Azure Functions |
Use the continuous deployment features of Azure App Service when publishing to Azure Functions. |
361daf37-598c-4703-8d78-c77dbef91643 |
conceptual |
05/01/2024 |
Azure Functions enables you to continuously deploy the changes made in a source control repository to a connected function app. This source control integration enables a workflow in which a code update triggers build, packaging, and deployment from your project to Azure.
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. If you connect to a production slot, make sure that only production-quality code makes it into the integrated code branch.
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. These steps can target either a staging or a production slot.
Functions supports these sources for continuous deployment to your app:
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?
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.
Maintain your project code in Bitbucket. Requires the App Service build provider.
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.
The unit of deployment for functions in Azure is the function app. For continuous deployment to succeed, the directory structure of your project must be compatible with the basic folder structure that Azure Functions expects. When you create your code project using Azure Functions Core Tools, Visual Studio Code, or Visual Studio, the Azure Functions templates are used to create code projects with the correct directory structure. 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.
Note
The Deployment Center doesn't support enabling continuous deployment for a function app with inbound network restrictions. You need to 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).
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.
Important
For increased security, consider using a build provider that supports managed identities, including Azure Pipelines and Gitub Actions. The App Service (Kudu) service requires you to enable basic authenication and work with text-based credentials.
Functions supports these build providers:
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. Supports managed identities.
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. Supports managed identities.
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, which means you can't use managed identities.
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 code to your function app by using one of these tools, you might need to Enable basic authentication for deployments to use the scm site.
Keep the strengths and limitations of these providers in mind when you enable source control integration. You might need to change your repository source type to take advantage of a specific provider.
The Azure portal provides a Deployment center for your function apps, which makes it easier to configure continuous deployment. The specific way you configure continuous deployment depends both on the type of source control repository 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.
:::image type="content" source="media/functions-continuous-deployment/deployment-center-choose-source.png" alt-text="Screenshot of Function app deployment center in the Azure portal where you choose your source repository.":::
Select the Source repository type where your project code is being maintained from one of these supported options:
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.
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.
You can't deploy from Bitbucket using Azure Pipelines. Instead choose the App Service build provider.
You can't deploy from local git using Azure Pipelines. Instead choose the App Service build provider.
You can't deploy from Azure Repos using GitHub Actions. Choose a different build provider.
[!INCLUDE functions-deploy-github-actions]
To learn more about GitHub Action deployments, including other ways to generate the workflow configuration file, see Continuous delivery by using GitHub Actions.
You can't deploy from Bitbucket using GitHub Actions. Instead choose the App Service build provider.
You can't deploy from local git using GitHub Actions. Instead choose the App Service build provider.
-
Navigate to your function app in the Azure portal and select Deployment Center.
-
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.
-
Select values for Organization, Project, Repository, and Branch. Only organizations that belong to your Azure account are displayed.
-
Select Save to create the webhook in your repository.
-
Navigate to your function app in the Azure portal and select Deployment Center.
-
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.
-
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.
-
Select values for Organization, Repository, and Branch. The values are based on the location of your code.
-
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.
-
Navigate to your function app in the Azure portal and select Deployment Center.
-
For Source select Bitbucket.
-
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.
-
Select values for Organization, Repository, and Branch. The values are based on the location of your code.
-
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.
-
Navigate to your function app in the Azure portal and select Deployment Center.
-
For Source select Local Git and select Save.
-
A local repository is created in your existing App Service plan, which is accessed from the
scmdomain. 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.
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.
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:
-
In the Azure portal, navigate to your function app.
-
In the app's left menu, select Configuration > General settings.
-
Set SCM Basic Auth Publishing Credentials to On, then select Save.
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.
[!div class="nextstepaction"] Best practices for Azure Functions