当然可以手动触发GitHub Actions工作流！而且针对你需要拆分开发/生产环境的需求，我们可以从三个核心层面来落地实现，一步步帮你搞定：

GitHub Actions提供了workflow_dispatch事件，专门用来支持手动触发工作流，完全符合你要的「发布到生产环境」按钮需求。

在你的生产环境工作流文件（比如.github/workflows/prod-deploy.yml）里，把触发条件改成这样：

on:
  workflow_dispatch:
    # 可选：添加自定义输入参数，比如让你选择部署版本或环境
    inputs:
      deploy-version:
        description: '要部署的版本标签（如v1.0.0）'
        required: true
        type: string
      environment:
        description: '目标环境'
        required: true
        default: 'production'
        type: choice
        options:
          - production
          - staging # 可选，如果你需要预发布环境

触发方式也很简单：

1. 打开GitHub仓库的「Actions」页面
2. 在左侧找到你的生产环境工作流（比如「Production Deployment」）
3. 点击「Run workflow」按钮，填写必要的参数后，点击「Run workflow」就可以手动触发部署了。

接下来我们从GitHub Actions、Docker、Kubernetes三个层面做环境隔离，确保两套环境互不干扰：

2.1 GitHub Actions层面：触发逻辑与配置隔离 #

• 开发环境：保持你现有的配置，推送master分支自动触发，构建开发镜像并部署到K8s开发集群
• 生产环境：用上面的workflow_dispatch手动触发，构建生产镜像（建议绑定Git标签，比如v1.0.0）并部署到生产集群
• 配置隔离：把开发和生产的K8s配置文件、镜像仓库密钥等分别存在GitHub Secrets里，比如DEV_KUBE_CONFIG和PROD_KUBE_CONFIG，工作流里根据触发场景选择对应配置。

示例工作流片段：

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 拉取代码
        uses: actions/checkout@v4

      - name: 构建并推送镜像
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          # 开发用latest标签，生产用手动指定的版本标签
          tags: |
            ${{ secrets.DOCKER_REGISTRY }}/my-app:${{ github.event_name == 'push' ? 'latest' : github.event.inputs.deploy-version }}
          # 传递环境参数给Dockerfile
          build-args: |
            ENVIRONMENT=${{ github.event_name == 'push' ? 'development' : 'production' }}

      - name: 部署到Kubernetes
        uses: azure/k8s-deploy@v4
        with:
          # 根据触发场景选择K8s配置
          kubeconfig: ${{ github.event_name == 'push' ? secrets.DEV_KUBE_CONFIG : secrets.PROD_KUBE_CONFIG }}
          # 加载对应环境的K8s部署文件
          manifests: |
            k8s/${{ github.event_name == 'push' ? 'dev' : 'prod' }}/deployment.yaml
          images: |
            ${{ secrets.DOCKER_REGISTRY }}/my-app:${{ github.event_name == 'push' ? 'latest' : github.event.inputs.deploy-version }}

2.2 Docker镜像层面：标签与构建逻辑区分 #

• 标签策略：开发镜像用latest或dev-<提交哈希>，方便追踪最新开发版本；生产镜像用语义化版本号（如v1.2.3）或Git标签，确保生产部署的版本可追溯、可回滚
• 构建参数：在Dockerfile里用ARG区分环境，实现开发和生产的不同构建逻辑（比如开发环境安装调试依赖，生产环境只装生产依赖）：

ARG ENVIRONMENT=development

# 开发环境安装完整依赖，生产环境只装生产依赖
RUN if [ "$ENVIRONMENT" = "development" ]; then npm install; else npm install --only=production; fi

# 开发环境构建调试版本，生产环境构建优化版本
RUN if [ "$ENVIRONMENT" = "production" ]; then npm run build:prod; else npm run build:dev; fi

2.3 Kubernetes部署层面：配置与资源隔离 #

• 目录拆分：在仓库里创建k8s/dev和k8s/prod目录，分别存放对应环境的deployment.yaml、service.yaml等配置文件。比如开发环境设置较少的副本数、较低的资源请求；生产环境设置多副本、合理的资源限制，甚至启用HPA（水平Pod自动扩缩容）
• 配置分离：用ConfigMap和Secret存储环境专属配置（比如数据库地址、API密钥），部署文件里引用对应的资源。比如开发环境用dev-db-config，生产环境用prod-db-config
• 命名空间隔离：把开发和生产部署在Kubernetes的不同命名空间（如dev和prod），方便做权限控制、资源配额管理，避免环境之间的资源冲突。

内容的提问来源于stack exchange，提问作者Antoine C.