GitHub Actions 如何实现多环境自动化部署-linux运维-PHP中文网

github actions 多环境部署核心是环境+触发规则+保护策略协同，而非多workflow硬拆；通过settings创建test/preview/production环境，配置隔离机密、分级保护规则及分支限制，并用on事件分流、jobs.environment动态绑定、concurrency防冲突。

github actions 如何实现多环境自动化部署

GitHub Actions 实现多环境自动化部署，核心在于用 环境（Environment）+ 触发规则 + 保护策略 三者协同控制不同阶段的发布行为，而不是靠多个 workflow 文件硬拆。关键不是“写几个脚本”，而是让同一套流程在不同上下文中自动适配目标环境。

用 environment 区分测试、预发、生产环境

在仓库 Settings → Environments 中创建三个环境：test、preview、production。每个环境可独立配置：

机密（Secrets）：比如 Cloudflare API Token、Azure Blob 连接字符串，按环境隔离
保护规则（Protection rules）：production 环境开启「需要审批」，preview 可设为自动通过，test 完全放开
部署分支限制：例如只允许 preview 环境接受来自 main 分支的部署，production 只响应 workflow_dispatch

用触发条件决定哪个环境被激活

一个 workflow 文件就能覆盖全部场景，靠 on 事件和 if 判断分流：

Git

程序猿必备版本控制工具

下载

feature/* 分支 push → 部署到 test 环境（路径带 feature 名）
PR 合并到 main → 自动部署到 preview 环境（/preview 路径）
手动点击「Run workflow」→ 选择 production 环境触发正式发布

示例片段：

on:
  push:
    branches: ['main']
    # 只有 main 分支 push 才走 preview 流程
  pull_request:
    branches: ['main']
  workflow_dispatch:
    inputs:
      target_env:
        description: 'Target environment'
        required: true
        default: 'production'
        type: choice
        options:
          - 'preview'
          - 'production'

用 jobs.environment 动态绑定目标环境

每个 job 显式指定 environment，GitHub 会自动应用该环境的机密和保护规则：

job 名为 deploy-test 时，写 environment: test，无需额外鉴权逻辑
deploy-preview 写 environment: preview，合并 PR 后自动执行，但若 preview 设了审批，就会卡在「等待审查」状态
deploy-prod 写 environment: production，且只在 workflow_dispatch 触发时运行，天然满足人工确认要求