能否通过GitHub Actions手动将Azure App测试构建部署至生产环境？

方案1：基于构件（Artifact）+ 手动触发输入参数 #

核心思路是让原测试部署工作流保留构建产物，手动触发时直接复用该产物，而非重新构建：

• 原测试工作流构建完成后，用actions/upload-artifact把ASP.NET Core的发布包上传为GitHub Artifact，命名带上提交哈希（比如app-publish-${{ github.sha }}），精准关联到特定提交的构建产物。
• 新建一个专门的生产部署工作流，用workflow_dispatch触发，添加两个必填输入参数：run_id（原测试工作流的运行ID，从Actions历史页面的运行详情里能找到）和commit_sha（原工作流对应的提交哈希，在运行详情或日志里可查）。
• 在生产部署工作流中，用actions/download-artifact根据run_id和构件名称（含commit_sha）下载之前上传的发布包，直接部署到生产槽，跳过构建步骤。

示例代码 #

原测试部署工作流（.github/workflows/deploy-test.yml）：

name: Deploy to Test Slot
on:
  push:
    branches: [master]

jobs:
  build-deploy-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      
      - name: Build & Publish
        run: dotnet publish YourApp.csproj -c Release -o ./publish
      
      - name: Upload Build Artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-publish-${{ github.sha }}
          path: ./publish
      
      - name: Deploy to Test Slot
        uses: azure/webapps-deploy@v2
        with:
          app-name: YourAppName
          slot-name: test
          package: ./publish
          publish-profile: ${{ secrets.AZURE_TEST_PUBLISH_PROFILE }}

生产部署手动触发工作流（.github/workflows/deploy-prod.yml）：

name: Deploy to Production Slot
on:
  workflow_dispatch:
    inputs:
      run_id:
        description: '运行ID（从测试部署工作流的详情页复制）'
        required: true
      commit_sha:
        description: '对应提交的SHA哈希'
        required: true

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    steps:
      - name: Download Test Build Artifact
        uses: actions/download-artifact@v4
        with:
          name: app-publish-${{ github.event.inputs.commit_sha }}
          run-id: ${{ github.event.inputs.run_id }}
      
      - name: Deploy to Production Slot
        uses: azure/webapps-deploy@v2
        with:
          app-name: YourAppName
          slot-name: production
          package: ./publish
          publish-profile: ${{ secrets.AZURE_PROD_PUBLISH_PROFILE }}

方案2：复用原工作流，通过环境参数切换部署目标 #

如果不想拆分工作流，可以修改原工作流，让它同时支持自动触发（测试槽）和手动触发（生产槽）：

• 给原工作流添加workflow_dispatch触发方式，新增一个输入参数target_slot，可选值为test和prod。
• 当是push触发（master分支提交）时，默认部署到test槽；当手动触发时，选择prod槽，并指定要部署的commit_sha。
• 关键优化：在工作流里判断，如果是手动触发且指定了commit_sha，则直接下载对应提交的构件（前提是原工作流已经上传了带commit_sha命名的构件），跳过构建步骤；如果是自动触发，则正常构建部署。

方案3：用工作流调用（workflow_call）抽离构建逻辑 #

把构建逻辑单独抽成一个可复用的工作流，测试和生产部署工作流都调用它：

• 构建工作流：接受commit_sha作为输入，拉取对应提交的代码，构建后上传构件。
• 测试部署工作流：master分支提交时，调用构建工作流（使用当前提交的SHA），然后部署到测试槽。
• 生产部署工作流：workflow_dispatch触发，接受commit_sha输入，调用构建工作流（复用之前的构建产物，或重新构建对应提交——如果构件已过期的话），然后部署到生产槽。

不管用哪个方案，核心都是保留特定提交的构建产物，并在手动触发时精准定位到该产物，避免重复构建。

内容的提问来源于stack exchange，提问作者Kram