GitHub Action 对应Azure DevOps Release的功能及多环境部署方法咨询

Great question! I’ve worked with both tools extensively, so let’s break this down clearly and practically.

What’s the GitHub Actions equivalent of Azure DevOps Releases? #

Unlike Azure DevOps which strictly separates Build and Release pipelines, GitHub Actions uses workflows that can handle both build and deployment stages. That said, you can easily replicate the "Release" pattern in a couple of ways:

• Use a single workflow with separate jobs for building and deploying (each deployment target can be its own distinct job)
• Split into two dedicated workflows: one for building and publishing artifacts, and another triggered specifically for deployments (e.g., via a manual workflow dispatch or when a new artifact is created)

The core goal here is the same as Azure DevOps: decouple your build process from deployment, so you can reuse the exact same build artifact across multiple environments.

How to deploy a single build artifact to multiple environments in GitHub Actions #

Here’s a step-by-step approach that matches the flow you described (build → auto-deploy to test → approved deploy to other environments):

• Save your build artifact after the build stage
  First, you need to preserve your build output so it can be reused across all deployment jobs. Use the actions/upload-artifact action to store it in GitHub’s built-in artifact storage.

  Example build job snippet:

  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - name: Checkout code
          uses: actions/checkout@v4
  
        - name: Build application
          run: npm run build  # Replace with your project's build command
  
        - name: Upload build artifact
          uses: actions/upload-artifact@v4
          with:
            name: my-app-build
            path: dist/  # Path to your final build output directory
  

• Set up environment-specific deployment jobs
  Structure your deployment jobs to run under different conditions, with triggers and approvals aligned to your needs:

  • Auto-deploy to test environment after build
    Add a deployment job that runs only when the build job succeeds. This mimics the "build completes → deploy to test" flow:

    deploy-test:
        needs: build
        runs-on: ubuntu-latest
        environment: test  # Optional: Link to a GitHub Environment for better tracking
        steps:
          - name: Download build artifact
            uses: actions/download-artifact@v4
            with:
              name: my-app-build
              path: dist/
    
          - name: Deploy to test environment
            run: |
              # Replace with your actual test deployment command (e.g., Azure CLI, AWS CLI, etc.)
              echo "Deploying to test environment..."
    

  • Deploy to production with manual approval
    For production or other gated environments, use GitHub’s Environments with required approvals. First, create an environment in your repo settings (Settings → Environments) and add designated approvers. Then reference this environment in your deployment job to trigger the approval workflow:

    deploy-prod:
        needs: deploy-test
        runs-on: ubuntu-latest
        environment: production  # Triggers the approval process you configured
        steps:
          - name: Download build artifact
            uses: actions/download-artifact@v4
            with:
              name: my-app-build
              path: dist/
    
          - name: Deploy to production environment
            run: |
              # Replace with your actual production deployment command
              echo "Deploying to production environment..."
    

• Handle environment-specific parameters
  To use different configuration values per environment (like connection strings, API keys), store them as GitHub Secrets or Environment Variables:

  • Secrets: Go to Settings → Secrets and variables → Actions to add environment-specific secrets (you can link secrets directly to specific environments for security)
  • Variables: Use env blocks in your job, or reference environment-specific variables from the GitHub Environment settings

  Example of using environment-specific secrets in a deployment step:

  - name: Deploy to production environment
          env:
            PROD_DB_CONN: ${{ secrets.PROD_DB_CONNECTION_STRING }}
          run: |
            # Use the secret in your deployment command (never hardcode these!)
            echo "Connecting to production DB using secured connection string"
  

Quick Additional Tips #

• GitHub Artifacts are retained for 90 days by default (you can adjust this retention period in your repo settings if needed)
• You can trigger deployment workflows manually via Workflow Dispatch if you want to redeploy an existing artifact without re-running the build
• For more complex scenarios, you can use the actions/download-artifact action to pull artifacts from a specific previous successful build run

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