Merge pull request #274151 from ggailey777/patch-3

[Functions] peer-review updates for functions-continuous-deployment.md

Author: prmerger-automator[bot]

articles/azure-functions/functions-continuous-deployment.md

@@ -3,23 +3,23 @@ title: Continuous deployment for Azure Functions
 description: Use the continuous deployment features of Azure App Service when publishing to Azure Functions.
 ms.assetid: 361daf37-598c-4703-8d78-c77dbef91643
 ms.topic: conceptual
-ms.date: 04/10/2024
+ms.date: 05/01/2024
 #Customer intent: As a developer, I want to learn how to set up a continuous integration environment so that function app updates are deployed automatically when I check in my code changes.
 ---
 
 # Continuous deployment for Azure Functions
 
-You can use Azure Functions to deploy your code continuously by using [source control integration](functions-deployment-technologies.md#source-control). Source control integration enables a workflow in which a code update triggers build, packaging, and deployment from your project to Azure. 
+Azure Functions enables you to continuously deploy the changes made in a source control repository to a connected function app. This [source control integration](functions-deployment-technologies.md#source-control) 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. 
+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](./functions-deployment-slots.md#swap-slots). 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. 
+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](/cli/azure/functionapp/deployment). These steps can target either a staging or a production slot. 
 
 Functions supports these sources for continuous deployment to your app:
 
 ### [Azure Repos](#tab/azure-repos)
 
-Maintain your project code in [Azure Repos](https://azure.microsoft.com/services/devops/repos/), one of the services in Azure DevOps. Supports both Git and Team Foundation Version Control. Used with the [Azure Pipelines build provider](functions-continuous-deployment.md?tabs=azure-repos%2azure-pipelines#build-providers)). For more information, see [What is Azure Repos?](/azure/devops/repos/get-started/what-is-repos)
+Maintain your project code in [Azure Repos](https://azure.microsoft.com/services/devops/repos/), one of the services in Azure DevOps. Supports both Git and Team Foundation Version Control. Used with the [Azure Pipelines build provider](functions-continuous-deployment.md?tabs=azure-repos%2azure-pipelines#build-providers). For more information, see [What is Azure Repos?](/azure/devops/repos/get-started/what-is-repos)
 
 ### [GitHub](#tab/github)
 
@@ -44,37 +44,43 @@ You can also connect your function app to an external Git repository, but this r
 
 ## Requirements
 
-For continuous deployment to succeed, your directory structure must be compatible with the basic folder structure that Azure Functions expects.
+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.
 
-[!INCLUDE [functions-folder-structure](../../includes/functions-folder-structure.md)]
+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.
 
-## Build providers
+>[!NOTE]
+>The Deployment Center doesn't support enabling continuous deployment for a function app with [inbound network restrictions](functions-networking-options.md?#inbound-networking-features). 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)](/azure/devops/pipelines/agents/agents#self-hosted-agents) or a [self-hosted runner (GitHub)](https://docs.github.com/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).
+
+## <a name="build-providers"></a>Select a build provider
 
 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-deployment-technologies.md#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](#enable-basic-authentication-for-deployments) and work with text-based credentials. 
+
 Functions supports these build providers:
 
 ### [Azure Pipelines](#tab/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. 
+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`](/azure/devops/pipelines/tasks/reference/azure-function-app-v2) 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](#tab/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. 
+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. 
 
 ### [App Service (Kudu) service](#tab/app-service)
 
-The App Service platform maintains a native deployment service ([Project Kudu](https://github.com/projectkudu/kudu/wiki)) 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](#enable-basic-authentication-for-deployments). 
+The App Service platform maintains a native deployment service ([Project Kudu](https://github.com/projectkudu/kudu/wiki)) 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 by using one of these tools, you might need to Enable basic authentication on the SCM endpoint.  
+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](#enable-basic-authentication-for-deployments) to use the `scm` site.  
 
 ---
 
-Your options for which of these build providers you can use depend on the specific code deployment source.  
+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.
 
-## <a name="credentials"></a>Deployment center
+## <a name="credentials"></a>Configure continuous deployment
 
-The [Azure portal](https://portal.azure.com) 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](#build-providers) you choose. 
+The [Azure portal](https://portal.azure.com) 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](#build-providers) you choose. 
 
 In the [Azure portal](https://portal.azure.com), browse to your function app page and select **Deployment Center** under **Deployment** in the left pane. 
 
@@ -168,21 +174,7 @@ When a new commit is pushed to the local git repository, the service pulls your
 
 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](./functions-deployment-slots.md#swap-slots).
-
-+ 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)](/azure/devops/pipelines/agents/agents#self-hosted-agents) or a [self-hosted runner (GitHub)](https://docs.github.com/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).
-
-## Continuous deployment during app creation
+## Enable 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.
 
@@ -193,7 +185,7 @@ If you want to use a different deployment source or build provider for continuou
 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](../app-service/configure-basic-auth-disable.md#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](security-concepts.md#secure-deployment).
+> 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](security-concepts.md#secure-deployment).
 
 To enable basic authentication to the `scm` endpoint: