我们解决这个问题的方法是不切断管道
我们通过实现一个单独的WebJob构建/发布管道解决了这个问题。
以下是对我们有效的步骤：
"在蔚蓝之门“

• 在应用服务x1c 0d1x中创建虚拟应用
  在开发运维中
• 在您的建置管缐
  
  **重要注意事项：**加入下列参数：--output $(build.artifactstagingdirectory)到构建步骤。
• 在您的发布管道
  
  中

这会将WebJob部署到正确的目录。$(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop
查看应用服务中的Kudo控制台，WebJob的文件位置为：

Kudu控制台
对我有效的变通办法是直接通过Kudu控制台上传Webjob。
在Azure门户上的应用服务中选择“高级工具”--〉“转到”，打开Kudu控制台。
进入Kudu门户后，打开“调试控制台”--〉“CMD”
转到Web作业的目录：“d：\home\site\wwwroot\应用程序数据\作业\连续{作业名称}”（https://github.com/projectkudu/kudu/wiki/WebJobs）
然后拖放您准备上传Web作业的.zip文件（https://github.com/projectkudu/kudu/wiki/Kudu-console）
作业现在将在Azure门户上列出并启动。

我在虚拟应用程序中使用了以下物理路径，它为我们解决了这个问题
站点\wwwroot\应用程序数据\作业\已触发\作业名称

我们遇到了同样的问题，并注意到有一个旧的部署管道连接到部署中心刀片中的Web作业。断开此连接为我们解决了问题，我们能够手动部署。

我使用Kudu控制台上传了Webjob
您可以转到路径D：\home\site\wwwroot\App_Data\jobs\，然后在此处上传Webjob文件夹，该文件夹也会显示在您的Webjob门户中

不要去为这个问题创建新的CICD管道。在断开部署中心的连接时不要使用chrome/safer。请使用最新的IE或Microsoft Edge。它将允许断开部署中心的连接。我可以在Microsoft Edge中这样做。

我们遇到了同样的问题，在部署中心有我的Web应用程序的默认配置，但我们没有从存储库部署代码，因此我们禁用了该选项。我们正在从visual studio部署Web应用程序。

当前图像显示Web应用程序部署中心中禁用的存储库选项。

可能是因为您为Web应用程序部署设置了CI/CD。
如果您使用Azure Devops管道设置您的部署，并且您正在使用yaml文件方法，那么这可能就是您正在寻找的。
首先你需要设置一个分支，当一个新的提交被推送到它的时候，你想触发这个分支。

trigger:
  branches:
    include:
    - refs/heads/staging

variables:
  BuildConfiguration: 'Release'

pr: none # Disable pull request triggers.

为了使我们的管道更有条理，我们将使用stages，让我们创建Build stage，这里我正在构建一个.Net应用，您可以将构建任务替换为您想要的构建。

stages:
- stage: 'Build'
  jobs:
  - job: 'Build'
    pool:
      vmImage: 'windows-latest'  #The agent that will be used to start this stage

    steps:
    - task: DotNetCoreCLI@2
      displayName: 'dotnet build'
      inputs:
        command: build
        projects: 'MySuperApp/BackgroundService.csproj'
        arguments: '--configuration $(BuildConfiguration)'

然后运行dotnetpublish，将应用程序及其依赖项发布到一个文件夹，以便部署到宿主系统。
这里是重要的部分，当你从Azure Portal创建一个Web作业时，它的文件被存储在特定的文件夹下。
对于连续Web作业，它将存储在\site\wwwroot\app_data\Jobs\Continuous下
对于触发的Web作业，它将位于\site\wwwroot\app_data\Jobs\Triggered下

- task: DotNetCoreCLI@2
      displayName: 'dotnet publish'
      inputs:
        command: 'publish'
        arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
        projects: 'MySuperApp/BackgroundService.csproj'
        publishWebProjects: false
        zipAfterPublish: false
        modifyOutputPath: false

对我来说，我需要部署一个连续的Web作业，正如您在inputs:中看到的那样

--output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'

dotnet发布将把生成的文件放在$(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS下
然后压缩$(Build.ArtifactStagingDirectory)/publish_output/的内容，即App_Data/jobs/continuous/MySuperAppBGS

- task: ArchiveFiles@2
      displayName: 'Zip Published Files'
      inputs:
        rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish_output'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/MySuperAppAPIBackgroundService.zip'
        replaceExistingArchive: true

并将$(Build.ArtifactStagingDirectory)的内容发布到drop工件，其中我们的zip文件存在MySuperAppAPIBackgroundService.zip，以便在下一阶段使用它

- task: PublishBuildArtifacts@1
      displayName: 'Publish Build artifacts'
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
        publishLocation: 'Container'

这是第二个阶段，将我们的zip文件部署到web应用程序服务，然后解压缩，将App_Data/jobs/continuous/MySuperAppBGS/*保留在\site\wwwroot\下

- stage: 'Deploy'
  jobs:
  - deployment: 'Deploy'
    environment: 'MySuperAppAPI_BackGround_Staging_env' #just an env variable, that will be used later if you want, give it whatever name you like
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Deploy MySuperAppAPIBackgroundService.zip to MySuperAppAPI-Staging-BackgroundService'
            inputs:
              azureSubscription: 'Your Azure service connection'
              appType: 'webApp'
              appName: 'MySuperAppAPI-Staging-BackgroundService'
              package: '$(Pipeline.Workspace)/drop/MySuperAppAPIBackgroundService.zip'
              deploymentMethod: 'zipDeploy'

注意：在第二阶段，我没有调用DownloadBuildArtifacts@0任务，因为我在自动注入Download工件任务的- deployment:作业中使用了deploy:，并且要访问前一阶段发布的工件，您需要使用$(Pipeline.Workspace)，后跟您提供的工件名称，在我的示例中是$(Pipeline.Workspace)/drop
希望我说清楚，对于任何澄清不要犹豫，来问我。